MUI for Figma はデザイナーに最適なソリューションか?[代替案]
MUI(Material-UI)は、Googleのマテリアルデザイン原則に基づいて構築された多くの人に使用されているReact UIフレームワークです。カスタマイズ可能なコンポーネントとスタイルで、ブランド標準に沿った組織運営が実現します。
そこで本記事では、 MUI for Figma の機能と制限について深く掘り下げます。また、MUI を UXPin Mergeと統合するという別のアプローチもご紹介します。あるスタートアップ企業がデザインプロセスで MUIのReactコンポーネントを使って製品をリデザインした実例を交えてお話しします。
主なポイント
- MUI(Material-UI)は、GoogleのマテリアルデザインがベースのReact UIフレームワークであり、ブランドガイドラインに合わせたカスタマイズが可能。
- MUI for Figmaにはデザインキットがあるが、MUIではReactライブラリのインタラクティブ機能がないため、デザインに矛盾が生じる可能性がある。
- サイズが大きく、Token Studioなどのプラグインに依存するため、パフォーマンスの問題につながることもある。
- UXPin Mergeは代替手段を提供。デザイナーがReactコンポーネントを使ってプロトタイプを作成できることで、デザインと開発のギャップを埋めることができる。
- TeamPasswordは、UXPin MergeとMUIを活用したことで製品開発ワークフローを強化し、「Code-to-Design(コードからデザイン)」アプローチによって効率性が向上したことを実証した。
UXPin Mergeにより、使い慣れたデザインツールの中でMUIのReactライブラリを使用したプロトタイプ作成とテストが可能です。詳細とアクセスリクエストはこちらのページをご覧ください。
MUI とは
MUI(Material-UI)は、Google のマテリアルデザインに基づいたコンポーネントとスタイルのセットを提供する人気のReact UIフレームワークであり、組織は、MUIのテーマ機能を使って、製品やブランドの仕様に合わせて UIライブラリをカスタマイズすることができます。
MUI を使う理由
MUIを使うことでゼロからデザインすることなく製品を構築するための包括的なデザインシステムを活用することができます。わずかな調整や修正を行うだけで、カスタムデザインシステムを構築することができるため、研究開発にかかる時間の節約につながるでしょう。
また、MUIの使用は新製品の開発にも便利です。プロダクトチームやスタートアップ企業は、テーマを変更することなくMaterial UIのライブラリを使って、テスト用のMVP(実用最小限の製品)を構築することができます。デザインシステムを活用することで、UX(ユーザーエクスペリエンス)とアクセシビリティのために最適化された包括的なライブラリを使うことができ、製品を速やかにデザインすることができるのです。
MUI for Figma のコスト
無料のコミュニティである MUI for Figmaのライブラリがありますが、提供されているコンポーネントは限られており、サポートもありません。また、UIライブラリ全体が必要な場合は、MUIのWebサイトでMUI for Figmaのライセンスの購入が必要です。ちなみに2023年10月現在、エディター1名分のライセンスは79ドルです。大規模なチームであれば、すぐに料金がかさむ上に、毎年のライセンス更新が必要です。
このような追加料金を回避するためにも、UXPinで完全に機能するMUIのReactコンポーネントを使ってプロトタイプを作成することをおすすめします。MUIはUXPinに組み込まれているデザインライブラリの1つで、UXPin Mergeでのすべてのプランに備えられています。UXPin MergeでのMUIを使ったデザインについては、こちらをご覧ください。
Figmaでマテリアル UIを統合する方法
コミュニティページからファイルを開き、無料のFigma MUIライブラリを使うことができます。新しいプロジェクトでMUIを使い始めるには、Open in Figma ボタンをクリックしてください。
フルライブラリを使用する場合は、以下をご参考ください。
MUI for Figma のインポート法
- Figma の下書きまたは組織に移動する
- Import ボタンをクリックして、MUI ファイルをインポートする
MUI for Figma の使用法
FigmaでMUIライブラリを扱うには、次の2つの方法があります:
1.MUIファイルで直接デザインする:この方法は無料版では問題ありませんが、フルライブラリではファイルサイズが大きくなるため、MUIはこの方法を推奨していません。
2.MUIファイルをライブラリとして使う: FigmaでMUIを使う際の好ましい方法です。これをするには以下を行います:
- Figmaのアセットパネルに移動する
- ライブラリのアイコンをクリックする
- MUIファイルをライブラリとして公開する
FigmaでMUIライブラリをカスタマイズする方法
MUI ライブラリの色をカスタマイズするには、以下の2つの方法があります:
- Token Studioプラグイン: この方法は高速で、合成が可能。つまり、ある色を使って別の色を生成することができる。
- Figmaのネイティブトークン: サードパーティのプラグインを使用したくない場合は、Figma のネイティブ・トークンを使って色の変更が可能。
Token Studioでグローバル設定を変更する方法
Token Studioプラグインを使うと、Border‐radiusやフォントファミリなど、コンポーネントのグローバル設定を全て簡単に変更できます。例えば以下のような感じです:
- グローバルのborder‐radiusを変更するには、プラグインを開き、[Border radius]のグループに移動して値を編集する。
- フォントファミリーを変更するには、プラグインの[Typography]のグループに移動してフォント設定を調整する。
Figma MUIのダークモードを有効にする方法
Token Studioを使って、MUIライブラリ全体のダークモードを有効にするには以下を行います:
- Token Studio のプラグインを開く
- ダークモードなど、有効にしたいグループのボックスにチェック(✓)を入れる
- Figma のカラーモードをダークモードに変更して、変更を確認するというオプションもある
Figma MUIの課題と限界
MUIのFigmaライブラリは、UIデザインや静的プロトタイプには優れていますが、正確なテストを行うためのインタラクティブ性には欠けています。ここでは、デザイナーが FigmaのMUIライブラリを使う際のよくある問題を見ていきましょう。
MUI for Figma は、UIデザインキットであり、インタラクティブなデザインシステムではない
Figma MUIライブラリで、ゼロからデザインする時間が何時間も節約されますが、MUIのインタラクションを提供するものではありません。そのため、デザイナーはプロジェクトごとに Figmaでインタラクションを設定しなければいけません。
また、Figmaのコンポーネントのインタラクティブ性を追加することは、デベロッパーが使うMUIのReactライブラリと一致しません。コンポーネントの見た目は似ていますが、デザイナーは 正しいアクション、ステート、アニメーションを確実に実装すべく、MUI のドキュメントに忠実に従わないといけません。
編集可能なコンポーネント
デザインシステムチームは、メインのライブラリのファイルからMUIコンポーネントを管理し、不正な変更を防ぐことができます。一方で、デザイナーはインスタンスを切り離したり、UI要素を調整したりすることができるため、デザインドリフトや不整合が生じてしまいます。
プラグインへの依存
MUI for Figmaを正しく機能させるには、Token Studioのようなプラグインが必要です。しかし、プラグインは複雑さと潜在的な互換性の問題を別のレイヤーにもたらす可能性がある上で、Token Studioはプレミアム機能であることから月々のコストがかさみます。
チュートリアルの 「Getting Started」で、MUIは、Token StudioプラグインとFigmaのネイティブ・トークンとの同期に問題がある可能性があり、適切に管理されないと不整合が生じる可能性があることを記載しています。
パフォーマンスの問題
MUIではFigmaのファイルサイズが大きいため、デザインチームは、特にライブラリファイル内で直接作業する場合、パフォーマンスに問題が生じる可能性があります。
MUI for Figma の代替案
MUIライブラリを使った最適なデザイン方法として、UXPin Mergeを使って、エディタ内でReactコンポーネントを使用したプロトタイプの作成という方法があります。
UXPinで MUIを使うには以下の2つの方法があります:
- 内蔵されたMUIライブラリの使用
- カスタムMUIライブラリの連携
UXPinでのMUIライブラリの使い方
UXPinには、MUI、Fluent UI、Ant Design、MUI、Material UI、UXPin Boilerplateなど、Mergeではいくつかのビルトインライブラリが用意されています。それらはすべて、GitHubのレポジトリからのインタラクティブコンポーネントを備えたReactライブラリです。
UXPinでMUIライブラリを使用する利点は、スタイリングインタラクティブ機能が各コンポーネントに「組み込まれている」ため、デザイナーがそれを設定する必要がないことです。また、マスターインスタンスからコンポーネントをデタッチして変更することもできないため、レポジトリで定義されたデザインシステムを使わないといけません。
デザインライブラリのサイドバーからUI要素をキャンバスにドラッグし、プロパティパネルで再定義されたReactのプロップを調整するだけです。
このようなビルトインライブラリでは、デザイナーはUI(ユーザーインターフェース)の構築と、スタイリング、変数、ステート、ナビゲーションなどの定義済みの MUIプロパティの調整だけに集中することができます。
また、ブランドカラーやスタイリングでカスタムMUIデザインシステムを使いたい場合は、Mergeで他の統合の使用をおすすめします。
カスタムの MUIライブラリを UXPinに同期する方法
UXPin Mergeは、以下2つの統合機能により、テーマ別の MUI ライブラリなどのあらゆるデザインシステムをインポートすることができます:
- Git 統合(Reactのみ):Reactのライブラリの統合によって、 パターン、バージョン管理、および JSXのプリセットを含むなどすべてのMerge機能にアクセスできる。
- Storybook統合: React、Vue、Angular、Ember、その他のフロントエンド技術など、あらゆるStorybookで動作する。
この2つの統合のセットアップには技術的な入力が必要ですが、一度設定すると、Mergeは自動的にUXPinにアップデートを同期します。デザイナーとエンジニアは常に同じコンポーネントライブラリを使って、組織全体で「信頼できる唯一の情報源(Single source of truth)」を作成することができます。
UXPinでMUIコンポーネントを使用する方法
UXPinのビルトインライブラリを使おうが、カスタムの MUIデザインシステムを使おうが、ワークフローは同じであり、ライブラリは、キャンバスの左側にあるDesign System Libraries(デザインシステム ライブラリ)の下にあります。
Mergeのデザインシステムを選択すると、ライブラリのコンポーネント、カラー、タイポグラフィ、アセットが左サイドバーに表示されます。UI要素をクリックまたはキャンバス上にドラッグして、簡単にUIを構築します。
Mergeが非デザイナーにとってデザインをより身近なものにする
デザインツールは非デザイナーにとっては大変なものです。多くのデベロッパーは学習曲線をマスターするヒマはなく、そうなると彼らは、大体慣れ親しんだもの、つまり「コードを書くこと」に戻ります。
ただ、コードのプロトタイプはテストには最適ですが、時間とコストがかかり、デベロッパーは結局、ユーザビリティの問題やその他の矛盾を抱えた製品や機能をリリースすることになります。
TeamPasswordがMergeとMUIを使って再デザインと高速拡張を実現した方法
パスワード管理ツールを提供するTeamPasswordは、UXPinに切り替える前にこの課題に直面しました。2名構成の開発チームにはデザインスキルがなく、速やかに進めるために最小限のテストしか行わずにアップデートをプッシュしていました。また、時代遅れの技術スタックを使っていましたが、リソースが限られていたため、製品をゼロから作り直すことはできませんでした。
また、TeamPasswordにはUXデザイナーがいないため、エンジニアがデザイン、プロトタイプ作成、テスト、プログラミング、QA、出荷のすべてを自分たちで行わないといけません。
製品の再デザインのために MUIとReactに切り替えることにしました。彼らは、毎回コードを書いたり編集したりすることなく、Reactのコンポーネントを使ってプロトタイプを作成してテストするソリューションを求めており、シンプルなデザインワークフローを提供するツールが必要でした。
そこで、UXPinのMergeテクノロジーが選択肢として挙がり、TeamPasswordのデベロッパーは、製品固有のパターン、テンプレート、UIなどのカスタムのReact MUIライブラリを、Git統合でUXPinに同期し、インタラクティブなプロトタイプを使って新製品をテストできるようにしました。
MergeとMUIを使うことで、TeamPasswordsの製品開発ワークフローに革命がもたらし、2名構成の開発チームは、デザインから最終製品に至るまで非常に効率的かつ効果的になったのです。
MUI を使ったプロトタイプに「Code-to-Design(コードからデザイン)」が適している理由
Figmaのデザインシステムは、UIデザインや基本的なプロトタイプ作成には最適ですが、正確なテストを行うためのインタラクティブなプロトタイプを作成するには、外部ツールやプラグインに頼らないといけません。この時代遅れの「デザインからコード」へのワークフローは、時間もコストもかかるので、非効率的です。
そこでUXPinの「Code-toDesidn(コードからデザイン)」のワークフローだと、MUIのReact コンポーネントをデザインプロセスに取り入れ、プロダクトチームに以下のような多くのメリットをもたらします:
- コードによって定義された「信頼できる唯一の情報源(Single source of truth)」によって、デザインと開発のギャップを埋める。
- より少ない文書と説明によるシームレスなハンドオフ。
- デザインシステムのレポジトリにプロパティを確定することで、ドリフトや不整合がなくなる。
- ゼロからのデザインやプログラミングが不要なため、市場投入までの時間が短縮され、組織の競争力が強まる。
- 一元化されたデザインシステム管理は、少ないリソースで多くの運用負担を軽減し、それによって運用チームがより効果的になる。
Mergeのテクノロジーでインタラクティブプロトタイプさっそく作ってみましょう!詳細およびアクセスリクエスト方法については、こちらのページをぜひご覧ください。