flutter-ui-design

Flutter UI デザイン

フレームワークのデフォルトを組み合わせたような印象ではなく、製品のために作り込まれたと感じられる、一貫性のあるプラットフォーム対応の Flutter インターフェースを作成します。

対象範囲

アートディレクション、ビジュアルの意欲、階層、構成、セマンティックトークン、タイポグラフィ、色、サーフェス、形状、状態の見せ方、レンダリング後のビジュアルレビューを担当します。

実装構造、再利用可能なウィジェット API、フォーム、UI 状態の管理は flutter-ui-patterns に委ねます。制約の仕組みは flutter-responsive-layout、モーションの実装は flutter-animation、高度なぼかし、屈折、シェーダー、カスタムの光学的レンダリングは flutter-visual-effects、アクセシビリティへの準拠は flutter-accessibility、ナビゲーションの動作は flutter-navigation に委ねます。

事前確認

デザイン変更を提案する前に、次の手順を行います。

1. pubspec.yaml、対応プラットフォーム、周辺の画面、アセット、フォント、提供された参考資料を確認します。
2. 既存の ThemeData、ColorScheme、TextTheme、コンポーネントテーマ、ThemeExtension、デザインシステムのウィジェットを探します。
3. 明示的にデザイン変更を許可されていない限り、確立されたブランドとコンポーネントの語彙を維持します。
4. プロジェクトを実行できる場合は、代表的なビューポートで現在の画面を確認します。ソースだけでは、現在のビジュアルの基準を判断する根拠として不十分です。
5. 見慣れているという理由だけで、UI パッケージ、フォント、アイコンセット、競合するテーマを追加しないでください。

デザインのワークフロー

1. 画面の主なユーザータスクと、観察可能な表現でビジュアル上の問題を述べます。
2. 課題を、維持、改良、明確な変革、参考資料との一致のいずれかに分類します。求められる意欲の度合いに合わせます。目に見えるデザイン変更の依頼に対し、ほとんど変化のない無難なデフォルトで答えてはいけません。
3. 背景、サーフェスの扱い、文字の印象、アクセントの使い方、形状の特徴、モーション、コンテンツの語り口を含む、簡潔なデザインシグネチャを定義します。各要素は同じ製品コンセプトを支えるものでなければなりません。
4. 個々のウィジェットをスタイリングする前に、セマンティックトークンを確立するか拡張します。プロジェクトの既存トークンと共有コンポーネントを信頼できる情報源として扱います。現在のシステムの名前を変えたり重複させたりするのではなく、製品に安定したセマンティック概念が不足している場合に限り、トークンを拡張します。
5. ラップや切り詰めを試せる長いコンテンツのフィクスチャを少なくとも1つ含め、現実的なコピーとデータを使って、実際の内容が入った代表的な画面を構成します。そのうえで、該当する空、読み込み、失敗、オフライン、古いデータ、無効、インタラクションの各状態を網羅します。操作可能な状態ごとに、復帰または進行のための主要なアクションを1つ選びます。具体的な状態マトリックスで「再試行または閉じる」などの選択肢を未解決のまま残してはいけません。スクリーンショットを魅力的に見せるためだけに、本番データを追加してはいけません。
6. 既存のテーマとコンポーネントシステムを使って実装します。新しい依存関係を追加しなくても方向性を表現できる場合は、Flutter の標準プリミティブを優先します。要件または確認したプロジェクトの根拠が必要としない限り、別のテーマシステム、フォント、アイコンパック、UI 依存関係を追加しないでください。
7. 同じフィクスチャを変更前と変更後にレンダリングします。階層、個性、密度、デフォルトウィジェットの残り、状態の品質、参考資料との差を批評し、重要な問題があれば、さらに実装を進めます。

デザインルール

• 装飾を加える前に、タイポグラフィ、余白、配置、グルーピングを活用します。
• 各サーフェスの主要なアクションは、明確に1つにします。副次的なアクションは、目立ちすぎないようにします。
• すべてのコンテンツグループをカードにしないでください。立体感に意味がない場合は、余白や区切り線を使います。
• 個性的であることは、過剰に装飾することではありません。グラデーション、半透明、ぼかし、発光、表情豊かな形状、奥行きは、選択したデザインの特徴を構成する場合に使い、コンテンツより目立たないようにします。
• フレームワークのデフォルトの名残がないか、仕上がりを確認します。標準ウィジェットは動作の基礎として有効ですが、明確なビジュアルアイデンティティが求められる画面で、手を加えていない標準の見た目が支配的になってはいけません。
• 色、書体、余白、形状、アイコン、立体感は、小規模なセマンティックシステムにまとめます。
• 現実的なコンテンツを使います。プレースホルダーテキストでは、階層やはみ出しの問題が隠れてしまうことがよくあります。
• 意味が曖昧なアイコンには、ラベルなどの補足情報を添えます。
• ブランドアイデンティティを保ちながら、対象プラットフォームに合わせてコントロール、ジェスチャー、情報密度、ナビゲーションの慣習を調整します。
• 洗練された参考資料や同じ製品のネイティブアプリが提示されている場合は、プラットフォームの操作性に合わせる前に、そのビジュアルの方向性と製品としての関係性を反映します。模倣を避けるためだけに、表現力豊かな参考資料を汎用的なMaterialデザインに置き換えてはいけません。

参考資料を必要に応じて読む

• 依頼が自由形式の場合、目に見える変化を求めている場合、UIがありきたりに感じられると指摘されている場合、または洗練された参考資料が提示されている場合は、アートディレクションを読みます。
• デザイントークン、タイポグラフィ、色、形状、アイコン、立体感を選択または拡張する場合は、ビジュアルの基礎を読みます。
• 階層を確立する場合や画面全体を再設計する場合は、画面構成を読みます。
• インターフェースでデータの読み込み、入力の受け付け、エラーへの対応を行う場合や、インタラクションを洗練させる必要がある場合は、状態とフィードバックを読みます。
• 複数のプラットフォームを対象にする場合、またはiOS、Android、Web、デスクトップの参考資料を変換する場合は、プラットフォームへの適応を読みます。
• 再設計の完了を宣言する前に、ビジュアルの検証を読みます。

検証

代表的な状態とフォームファクターについて、安定したスクリーンショットまたはゴールデンフィクスチャを取得します。画面を目に見える形で再設計した場合は、コンテンツが入った主要な状態を少なくとも1つと、最も重要なエッジケースの状態を含めます。ライトテーマとダークテーマ、標準と拡大のテキストサイズ、カスタムの前景色と背景色の組み合わせに対する実際のコントラストチェック、代表的なコンパクトおよびワイドのフォームファクターを明記した、明示的な検証マトリックスを定義します。必要に応じて、ローカライズ、ポインターまたはキーボードのフォーカス、プラットフォーム固有のコントロールも追加します。フレームワークのデフォルトに従えば、カスタムの組み合わせもアクセシブルになるとは限りません。動作と外観は別々にテストします。

実行可能なプロジェクトや必要なアセットが提供されていない場合は、代表的な最小限のフィクスチャマトリックスを定義し、後で何をレンダリングする必要があるかを明記します。デザイン案やソーステキストだけを根拠に、ビジュアル検証済みと主張してはいけません。

最初のレンダリングが成功した時点で終わらせないでください。ベースラインや提示された参考資料と比較し、目立つ視覚的な差異を修正して、承認された結果を取得します。画面が単に「美しい」と主張するのではなく、製品アイデンティティの強化、アクションの優先順位の明確化、標準ウィジェットの名残の低減、意図的な情報密度、状態の網羅といった、目に見える改善点を報告します。

参考資料

• Flutter向けMaterial Design
• テーマを使って色とフォントスタイルを共有する
• プラットフォームへの適応
• アダプティブデザインとレスポンシブデザイン
• タイポグラフィ