frontend-design について
ユーザーインターフェースを設計・実装する人向けのガイダンススキルです。ユーザーの目的に沿った画面構成、視覚的な階層、各種状態の設計、レスポンシブレイアウトの確認を重視します。
主な機能
- 01ユーザーの主要タスクを軸に画面を構成
- 02一貫した視覚ルールと階層の設定
- 03明確で一貫性のある UI 文言
- 04読み込み・エラー・完了状態の設計
- 05レスポンシブ表示とアクセシビリティの確認
活用シーン
- 01製品画面の主要な操作経路の設計
- 02フォームや非同期処理の状態補完
- 03SaaS ランディングページの内容と根拠の改善
- 04モバイル画面の分かりやすさの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ junaid-pk/ frontend-design-skill --skill frontend-designインストール後、Claude Code で/frontend-designを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
フロントエンドデザイン
画面にたどり着いてから有用な結果を得るまでの、最短で明快な道筋を設計します。ビジュアルの洗練は、後から装飾を加えるのではなく、優れたインターフェースの判断から生まれるものとして捉えます。落ち着きと有能さ、意図が感じられるプロダクトにします。
ユーザーの目的から始める
カードや色、ナビゲーションを選ぶ前に、次の点を明らかにします。
- この画面を使うのは誰ですか?
- 何を達成するためにこの画面にたどり着きましたか?
- 最も重要なアクション、または情報は何ですか?
- 自信を持って行動するために、何を知る必要がありますか?
- 目的を妨げずに取り除けるものは何ですか?
各画面が答える主な問いは一つにします。実際に副次的な目的がある場合に限って補助機能を追加し、空間を埋めるために追加してはいけません。作り手はプロダクトを熟知していることを前提にし、新しいユーザーには、必要だと思う以上に明確な案内を用意します。
要件が不完全な場合は、プロダクトの文脈から妥当な主な目的を推測し、その前提を簡潔に示します。参考スクリーンショットや確立されたデザインシステムがある場合は、それらを確認して従い、無関係なビジュアルの方向性を新たに考案しないでください。
画面を構成する前にルールを定める
コンパクトなシステムを定義し、すべての画面で再利用します。
- 控えめなニュートラルカラーを基調とし、メインのアクセントカラーを一つ使います。
- ステータス、チャート、警告、破壊的な操作には、意味に応じた色を使います。
- 一つの書体、または意図的かつ最小限の組み合わせを使い、階層は小さく保ちます。
- 一貫したスペーシングの尺度、コントロールの高さ、アイコンのサイズ、境界線の太さ、角丸の尺度を定めます。
- アクションとオブジェクトの用語を統一します。
- 主要、二次、三次、破壊的なアクションの見た目を明確にします。
ほぼ白に近い色や落ち着いたニュートラルな面、細い境界線、控えめな区切りを優先します。影は、奥行きやフォーカス、重要な開始地点を示す場合にのみ使います。ブランドや要件で特に必要とされない限り、発光効果、調和しないグラデーション、場当たり的なグラスモーフィズム、競合する複数のアクセントカラーは避けます。
Lucide、Phosphor、またはプロジェクト既存のセットなど、一貫性のあるアイコンファミリーを一つ使います。絵文字がプロダクトのコンテンツやブランド表現の一部でない限り、インターフェースのアイコンや装飾に絵文字を使わないでください。見慣れないアイコンのみのコントロールには、ラベルまたはツールチップを添えます。
コントロールの形状に一貫性を持たせます。フレームワークの既定値をそのまま受け入れるのではなく、テキストの中央揃え、アイコンの配置、パディング、角丸、ベースラインの揃い方を確認します。
情報量ではなく階層を作る
各画面を、主語が一つある文のように捉えます。サイズ、太さ、コントラスト、配置、余白によって最も重要な要素を明らかにし、その周囲の要素は控えめにします。
強い色は、意味やアクションを示すために使います。色はプロダクトのデータ、ステータス、主要なアクションに持たせ、ナビゲーションやクロームは控えめにします。チップ、ボタン、KPI、カテゴリのすべてに異なる色を割り当てないでください。
情報とタスクに応じてコンポーネントを選びます。
- 比較可能な情報が多いレコードには、テーブルやコンパクトなリストを使います。
- 意味のあるグループ化ができる場合にカードを使い、すべてを収めるための既定のコンテナにしないでください。
- 頻度の低い行アクションは、分かりやすいオーバーフローメニューに移します。
- 重要な数値やフィールドを優先し、メタデータは目立たなくします。
- 短く集中できるフォームには、空のサイドパネルではなく中央揃えのモーダルを使います。
- 同じカードグリッドを繰り返すのではなく、コンテンツの重要度に応じて余白を変えます。
- ユーザーが操作を制御し、終わりを把握できる場合は、明示的なページネーションまたは「さらに読み込む」を優先します。
各要素を「これはユーザーの理解、判断、目的の達成に役立つか?」という一つの問いで見直します。画面を埋めるだけの要素は取り除きます。
インターフェースの文言で操作を案内する
ユーザーの視点に立ち、平易で具体的、結果が分かる言葉を使います。操作の結果が伝わるように、「変更を保存」「メールを送信」「プロジェクトを削除」のようにコントロールに名前を付けます。より具体的な動詞が使える場合は、「送信」や「続行」のような曖昧なラベルを避けます。
同じ操作には、プロダクト全体を通じて同じ言葉を使います。ボタンが「公開」であれば、完了メッセージは「公開しました」とします。1つの操作に「削除」「取り除く」「ゴミ箱に移動」を混在させないでください。
ラベル、補助テキスト、メッセージは、それぞれ1つの役割に絞ります。エラーには解決方法を示します。空の状態では、意味のある最初の操作へユーザーを導きます。マーケティング文言は、実装や機能の一覧ではなく、購入者が望む結果を中心にします。
状態モデル全体を設計する
理想的なスクリーンショットだけを設計してはいけません。長い名前、値の欠落、検索結果がゼロの場合、多数の行、狭い画面、リクエストの遅延、リクエストの失敗、権限の制限など、現実的で厳しい条件のコンテンツでテストします。折り返し、省略、はみ出し、レスポンシブ動作は、恣意的な文字数制限を一律に使わず、コンテンツに応じて定義します。
すべての非同期処理や重要な操作のフローに、該当する状態を含めます。
- 初期状態と空の状態;
- 読み込み中または進行中;
- 部分的な状態または無効な状態;
- 解決方法を示すエラー;
- 成功または完了;
- 実用的な場合は元に戻す。
処理が進行中であることが、すぐに分かるようにします。コンテンツの読み込みにはスケルトン表示を使い、短い待ち時間には一般的な進行状況インジケーターを使い、時間のかかる処理には進捗状況や安心できるステータステキストを明示します。説明のない空白の画面をユーザーに見せたままにしないでください。
破壊的、高額、または取り消せない操作には、適切な慎重さを加えます。結果を明示し、リスクに応じた確認を求め、本当に重大な操作に限って文字入力による確認を使い、明確な完了状態を表示します。可能な場合は、取り消し可能な破壊的操作に「元に戻す」機能を用意します。
段階的にオンボーディングを案内する
ユーザーが有用な操作を始める前に閉じなければならない、強制的なツアーは避けます。最初の価値ある操作がすぐに分かるようにし、完了後に次のステップを提示します。セットアップに複数のステップがある場合は、短い進捗ステップを表示します。
意味のある進捗は、控えめなフィードバックで称えます。紙吹雪や遊び心のある動きは、初めての成功や大きな節目には適している場合がありますが、日常的な操作には向きません。B2B プロダクトでは、データが実際に裏付けている場合に、節約できた時間、完了した作業、売上への貢献など、信頼できる成果指標を提示します。
動きを使うなら意味を持たせる
状態、連続性、進捗、階層、因果関係を伝えるために動きを使います。正確で簡潔な動きにします。スクロールジャッキング、装飾的な登場アニメーション、常に動き続ける演出、ユーザーに何も伝えないパララックスは避けます。視差効果を減らす設定を尊重します。
次のように問いかけます。「この動きはユーザーに何を伝えるか?」何も伝えないのであれば、削除します。
SaaS のランディングページは実証を中心に設計する
ヒーロー部分では、プロダクト、対象ユーザーまたは解決する課題、約束する成果、主な次のステップを、解釈を必要とせずに伝えます。ページ内で同じリンク先には、同じラベルを付けます。
一般的なストック画像より、実際のプロダクトを示す証拠を優先します。セクションの主張を裏付ける、焦点を絞った切り抜きや短いプロダクトデモを見せます。関連する詳細を見つけるために、訪問者がダッシュボード全体のスクリーンショットを確認しなければならない構成にしないでください。同じテキストと画像が交互に並ぶセクションや、同じ4枚カードの行をページ内で繰り返すのは避けます。重要な証拠には十分なスペースを割き、ページに余白を持たせます。
次の問いに答えるために必要なセクションだけを使います。これは何か?どのように役立つか?どのように機能するか?信頼できるか?費用はいくらか?次に何をすればよいか?ロゴ、推薦コメント、バッジ、メガメニュー、イラスト、アニメーションは、実際のコンテンツとプロダクトの充実度に見合う場合にのみ追加します。
構築、確認、シンプル化
実装の前に、画面の主な役割、階層、カラーパレット、文字サイズ、余白、角丸、アクションの階層、アイコンの種類、用語を網羅した簡潔なデザイン契約を作成します。既存のトークンやコンポーネントで解決できる場合は、プロジェクトのものを再利用します。
次に、以下を行います。
- 主要な操作経路とレスポンシブな構成を構築します。
- 現実的なコンテンツとすべての状態を追加します。
- デスクトップとモバイルのサイズで、レンダリングされた UI を確認します。
- 配置、情報密度、コントラスト、フォーカス、キーボード操作、モーションの軽減を確認します。
- 要素を増やす前に、視覚的な要素を取り除きます。
- 新規ユーザーが主なアクションと現在のシステム状態をすぐに把握できることを確認します。
大規模な見本よりも、小規模で一貫性のあるインターフェースを優先します。独自性は、製品本来のコンテンツ、ブランド、コピー、または根拠のある特徴的な要素によって表現できますが、明確さ、信頼、タスクの完了を損なってはなりません。
最終確認
引き渡しの前に、以下のすべてを確認します。
- すべての画面で、主な目的と視覚的な主題が明確になっている。
- 主要、二次、破壊的なアクションを一目で区別できる。
- 色がインターフェースの装飾ではなく、意味を伝えている。
- タイポグラフィ、余白、角丸、アイコン、アクションの動詞に一貫性がある。
- 繰り返し使うコンポーネントが整理され、ひと目で確認できる。
- 空、読み込み中、エラー、成功、破壊的な状態に対応している。
- 現実的なデータや幅の狭いレイアウトでもデザインが崩れない。
- モーションが何かを伝え、モーションの軽減にも対応している。
- ランディングページの主張が、的を絞った製品の証拠によって裏付けられている。
- 残されたすべての要素が、ユーザーの理解、判断、完了に役立っている。