Design Notes

コントラスト比

視覚的なアクセシビリティを向上させるため、テキストと背景のコントラスト比は一定の基準を満たす必要がある。 WCAG(Web Content Accessibility Guidelines)はコントラスト比を以下の基準で定めている。 コントラスト比の計算はAdobe Color CCや、figmaのプラグインである「Contrast Grid」を利用すると簡単にできる。

AAA（より高いアクセシビリティを求める推奨基準）

・通常のテキスト　7:1　以上
・大きいテキスト（18pt以上または、14ptの太字）　4.5:1　以上
・UIコンポーネント（ボタン、リンクなど）　特別な要件はないが、7:1以上を推奨するケースもある。

フォントサイズ

• 見出しなどのインパクトが必要な要素：48~64px
• 本文は16~24px。基本的に長文は16pxの方が読みやすいし、画面幅も取りすぎないから良い。長文で文字がデカいと、一画面あたりの情報量が減るからユーザービリティが落ちる。
• 最小のフォントサイズは12pxとする。それ以上小さいとほぼ読めないので使用しない。12pxも画面の制約上やむを得ない場合の使用にとどめ、基本的には最小は14pxとする。
• 欧文は和文より小さいので、同じ役割のテキストでは、基本的に欧文は和文より大きくする。フォントによって大きさが異なるので、具体的な数値の指定はなく、フォントに合わせて指定する。
• 基本的に4pxまたは8px単位の大きさで指定する。
• 同じ役割のものは同じ大きさに。（例：各セクションの見出しとなるh2なら32pxとか）
• ユーザーによっては、ユーザーエージェントにより、文字サイズを拡大・縮小して使う場合もあるため、特定の文字サイズに依存したデザインにしてはいけない（文字サイズを変更したらデザインが崩れるものはダメってこと）。これに関連して、文字画像は基本ロゴ以外では用いない。

両端揃えを使わない

両端揃えを使うと、不自然な空白が生まれてしまい、単語の区切りが認識しづらくなることで、可読性が低下する。 また、画面幅に応じて、単語のスペースが変わるため、レスポンシブデザインとの相性も悪い。 加えて、低視力・読字障がい（ディスクレシア）の人にとって、単語の間隔が不均一だと読みにくいこともあり、WCAG（Web Content Accessibility Guideliness）でも両端揃えは非推奨となっている。 以上のことから、テキストでは両端揃えを使わずに、左揃えを基本とする。

line-height（行間）

line-heightの値の例

letter-spacing(文字間)

• 小さい文字（12〜14px）：0〜0.02em
• 本文（16〜18px）：0.02〜0.05em
• 見出し（20px以上）：0.05〜0.1em
• ボタン・ナビゲーション：0.05〜0.1em

文字間隔は上記の値が可読性とデザインのバランスが取れる。ただし、書体によって適切な文字間隔は異なるものなので、 杓子定規に上記の基準に当てはめるのではなく、書体ごとに調整すること。

また、WCAG2.1の基準では、文字間隔（letter-spacing）をフォントサイズの0.12倍（0.12em）以上にしても、レイアウトが崩れないように設計することを求めている （よく誤解があるが、これはデフォルトで文字間隔を0.12emにしろという意味ではないことに注意）。参考「達成基準 1.4.12: テキストの間隔を理解する」

paragraph spacing（段落間）

段落の間隔はフォントサイズの2倍以上が推奨されている。

トランケーション（短縮）の活用

画面幅が小さくなった時、フォントサイズや要素の最大幅の調整以外に、トランケーションを使う手もある。 トランケーションとは、短縮の意味で、たとえば、カードのタイトルを「デザインシステムを作る10のメリ・・・」のように、末尾に省略記号を用いて表現したりすること。 基本的に、レスポンシブ時の対応としては、詰める（余白の縮小）→縮める（フォントサイズやアイコンサイズ、要素の最大幅の縮小）→短縮（情報の一部をカット）→折りたたむ の順番で考えると良い。

余白

• 基本8の倍数で余白を取る。8で難しい時は、4の倍数で余白を取る。
• 一貫性：同じ要素の組み合わせには同じ余白を取る。
• 情報構造：関連性のあるものの余白は他より小さく取る。
• 操作性：タップ領域間は最低でも16px離すなど、使いやすさ、読みやすさを確保する。

角丸（border-radius）

• 角が丸いと、親しみやすさや優しさ、モダンな印象を与える
• 基本的には４の倍数で指定し、同じ要素には同じ値を。
• 要素の外側と内側の両方に角丸がある場合は、内側の角丸は外側より小さくすると自然な印象になる。

ボタンの文言

ボタンの文言は、曖昧で誤解を招くようなものではなく、簡潔かつ論理的なものにする。 悪い例だと、カートに移動するボタンの文言が「購入する」「注文する」などになっているパターンなど。 こうゆう場合は、ボタンの文言も「カートに移動する」、次のページで「注文を確定する」といった文言にする。

文字数の制約がなければ、ボタンの文言は基本的に名詞ではなく動詞で表現する。例：「注文」ではなく「注文する」など。 これは、押した後に何が起こるかをユーザーが瞬時に理解しやすくするという目的がある。 また、ボタンの文言が名詞だと、今の状態を表しているのか、次の動作を意味しているのかわかりづらい（フリップフロップ問題）。

「戻る」、「キャンセル」などの否定的なアクションのボタンの文言に関しては、HIGでは「キャンセル」という文言で統一するように提唱されている。

ステートの作成

ボタンを作ったら、必ずhover時、押下時のデザインも作成する。inputやtextareaの場合はfocus時のデザインも作成する。仕様によっては、無効状態（disable）のデザインも作る。 ボタンのデザインは、デフォルトの階調の中から明度・彩度を調整したものを使うことが多い。 一般的なのは、hover時はデフォルトより少し暗く、押下時はさらに暗く、フォーカス時は色をそのままで境界線を入れるデザイン。

ボタンのサイズに関して

ボタンサイズは「高さは固定」「横幅は内容に応じて可変」を基本とする。 横幅はラベルの長さに対して一定の左右余白を与えることで自然に伸縮させ、最低限の最小幅だけを定めておけば、多言語対応や文言変更があってもレイアウトが破綻しない。 通常のアプリUIではこの可変式を標準とする。

一部の例外として、モーダル内で複数ボタンの視覚的な並びを揃えたい場合や、LPのCTAなど見せ方を重視した局面に限り、幅を固定または揃える運用を許容する。 あくまでも例外的な扱いであり、プロダクト全体のUIでは可変式の方が再利用性・保守性ともに優れている。

高さはSmall / Medium / Large のように数種類に統一して定義し、32px・40px・48pxといった一般的なレンジを採用する。 高さはラインハイトではなく“コンポーネントの物理的な高さ”として固定することで、各サイズの一貫性が保てる。

フォントサイズは、ボタンの高さと視認性のバランスで決める。Medium（40px）では14px〜16pxが標準的で、Smallでは12px〜14px、Largeでは16px前後が適切となる。 フォントサイズに合わせて上下余白を都度調整するのではなく、あくまで固定された高さの中で自然に中央に揃うように行間（line-height）を調整し、上下余白は結果として導かれる形にすると整合性が保たれる。

最終的には、「高さは固定」「横幅は可変」「例外時のみ幅固定を許容」という3点を一貫して運用することで、視認性・操作性・再利用性が安定し、デザインシステムとしても破綻しない仕様になる。

ボタンのスタイルに関して

• プライマリーボタン：塗りを目立つ色（プライマリーカラー）、テキストを白塗り。＊下記例を参考に
• セカンダリーボタン：白塗りつぶしで、アウトラインとテキストをプライマリーカラーに
• ターシャリーボタン：塗りもアウトラインもない、テキストボタン（テキストのカラーはプライマリーまたはテキストカラー）に
• 破壊的なアクションボタン：後戻りできない削除の操作などでは、赤系統の目立つ色を用いる。並列する他のアクションボタンとの役割を考え、赤塗りつぶしにするか、アウトラインとテキストだけ赤かを選択する。

セカンダリーボタンもプラリマリーボタンと別の色で塗りつぶしにする事例もあるが、基本的に、塗りつぶしは目立つボタンになるので、 セカンダリーボタンも塗りつぶしにしてしまうと、ユーザーが重要度を誤認したり、迷う恐れがあるので、基本はセカンダリーはアウトライン型にする。

ボタンの使い分けに関して

• 基本的に一つのグループ内にプライマリーボタンは一つまで。セカンダリー、ターシャリーは複数あっても良い
• プライマリーボタンは、ユーザーが最も選択する可能性の高いアクションに対して適用
• セカンダリーボタンは中程度の選択肢で、ユーザーの主なタスクを妨げない重要なアクションに用いる
• ターシャリーボタンはセカンダリーボタンより低い可能性の選択肢、または補足的なアクションに用いる

並列するボタンの配置に関して

ダイアログ内にアクションボタンを 3 つ以上配置することは、HIG・Material Design いずれのガイドラインでも推奨されていない。 アクションボタンの数は 2つまでに絞るのが基本である。配置は横並びを標準とし、縦配置はレイアウト上の制約などでスペースが確保できない場合に限られる。

横に並べる際は、左右の役割が明確に分かれる。
右側：主要アクション（primary action）、ユーザーが最も選択する可能性が高い行動を置く。例：OK / Save / Continue などの肯定的・前向きな操作。
左側：重要度の低いアクション・否定的アクション（secondary）、Cancel / Back など、操作を中断したり戻ったりする行動を配置する。この左右の視覚的序列により、ユーザーはどちらが“進むための操作”なのかを瞬時に判断できる。

縦並びでは、上下の序列がそのまま優先順位になる。 上：主要アクション、 下：副次的・否定的アクション 横配置と同様に、より選択してほしい行動を知覚的な終端（この場合は上）に置くことで、行動の優先度を明確に示すことができる。

詳細に関しては下記記事にまとめている。配置・スタイル・文言から考えるダイアログのボタン設計

hover時のアニメーション

プライマリーボタンをセカンダリーボタンの色に反転させるのはやめた方が良い。 プライマリー、セカンダリーは重要度を決める役割なのだから、ホバー時に反転させるのは適切なアニメーションではない。 基本的には、box-shadowをつけるか、色の濃さを一段階あげたものを使うなどが良い。

ボタン内にアイコンを使う場合

ボタン内にアイコンを使う時、左から右に書く言語の場合は、アイコンはラベルの右側に配置する。

意味が直感的に伝わるか

見ただけでなんの機能か伝わることが最優先。 抽象的すぎるアイコンを使わない。意味が伝わらないアイコンは、テキストラベルを付与して使用する。

一貫したスタイルを保つ

太さ、角の丸み、線の長さを統一する。バラバラだとUI全体がチグハグに見える。 また、Iconセットは一種類に統一する（例：Lucide、Material Icons、Heroiconsなど）。

タップ領域

ボタンと同様に44px＊44px以上を推奨基準とし、アイコン間を16px以上離す。

意味の重複・混乱を避ける

「同じアイコンなのに違う意味で使ってる」とか、「似た機能に違うアイコン」があると混乱のもととなる。 例えば、同じ「＋」アイコンが「新規作成」と「追加」両方の意味で使われているのはNG。 意味に対してアイコンは1対1対応に近づける。

アニメーション・フィードバック

状態変化を動きで補足するのもUXとして効果的。 例えば、「いいね」ボタン → ハートがバウンドするなど、「保存済み」アイコンがトグルで変化するなど。

ドロップダウンメニュー

ドロップダウンメニューは、ボタンやラベルをクリック（またはホバー）した際に複数の選択肢が縦方向に展開されるUIパターン。 ナビゲーション項目の切り替えや操作メニューの表示など、主にユーザー操作や画面遷移を誘導する目的で使われる。 HTMLやCSS、JavaScriptを組み合わせたカスタム実装が一般的で、見た目や動作を自由にデザインできる反面、アクセシビリティ対応には配慮が必要。 フォーム送信は通常できないが、JSやバックエンド処理で可能となる。実務では、デザインの観点から、セレクトボックスをドロップダウンメニューに置き換えるケースも多い。

＊セレクトボックスと見た目や動きが似ているので混同しないように注意。

セレクトボックス

セレクトボックスは、フォーム内であらかじめ用意された複数の選択肢の中から、ユーザーが1つを選択できるUIコンポーネント。 HTMLのselect要素で実装されることが多く、フォームの送信時に選択された値がサーバーに送られることを目的としている。 ブラウザ標準のスタイルが適用され、アクセシビリティや操作性は高い一方で、カスタマイズ性は低い。

デートピッカー

デートピッカーは、日付（場合によっては時刻）を入力・選択させるためのUIコンポーネント。 ユーザーが日付をミスなく簡単に選べるように設計されており、フォームや予約、スケジュール管理など幅広い場面で使われる。 デートピッカーには、カレンダー式とドラムロール式がある。 1ヶ月前後の近い日付の選択やPCブラウザ中心のシステムであればカレンダー式、 生年月日など遠い過去の記録や遠い日付の選択にはドラムロール式が向いている。

カウンター

「カウンター（Counter）」とは、ユーザーが数値を増減させるためのインタラクティブなUI要素のことを指す。 典型的には「+（プラス）」と「−（マイナス）」のボタンで構成され、数値の入力欄や表示とセットで使われる。 キーボードを使わずに直感的に操作でき、入力ミスが少ないため、商品の購入個数や人数など、正確な値指定が求められ、小さい範囲での値の調整に用いるのが有効。

スライダー

スライダーは、ユーザーが連続的または範囲的な値を視覚的に調整できるUIコンポーネント。 バーを左右にドラッグすることで、値を調整することができる。 細かい値が調整しづらい反面、直感的で、認知負荷が少なく、価格帯や音量といった範囲指定に向いている。

トグルボタン

複数の状態を切り替えるボタン形式のUI。 一般的には「押すたびに状態が切り替わるボタン」で、状態に応じて見た目が変わる（色・文言・アイコンなど）。 トグルボタン使用時は、状態が明確にわかるようなラベルの文言や配色を心がける。

似たようなUIコンポーネントにスイッチ（トグルスイッチ）があるが、 基本的には、単純な機能のON/OFFにはスイッチ（トグルスイッチ）を用い、 フィルター（降順or昇順など）や表示切り替え（リストorカードなど）といった、複数の状態の切り替えにはトグルボタンを用いる。 なお、下記の例のような、表示切り替えはセグメントコントロールと言うこともある。

スイッチ（トグルスイッチ）

スイッチ（Switch）は、ある機能の有効・無効（ON/OFF）を切り替えるためのUIコンポーネント。 一般に、横にスライドするような外観（iOSやAndroidの設定画面に見られる）が特徴。 状態変更は即時で、リアルタイムに反映されることが望ましい。 また、スイッチが単体でオンなのかオフなのかわかりやすいように、ラベルの文言やスイッチのUIを工夫すること。

ページャー

ページャー（Pagenation）とは、大量のデータをページ単位で分割し、ユーザーにその一部を段階的に表示させるUIコンポーネントです。 例：« 1 2 3 4 5 » のようなナビゲーション。 主な用途としては、検索結果や、管理画面の一覧ページ、掲示板、レビュー表示など。

ステータスラベル

ステータスラベルは、オブジェクトや項目の「現在の状態」や「処理状況」を短い文字列で視覚的に表現するラベル。 主な用途としては、注文状況の表示（配送中、完了、キャンセル）など。

チップ

チップは、タグ・属性・選択済みの要素などをコンパクトに表現するUIパーツで、しばしば削除や選択解除などの操作も含む。 主な用途としては、フィルターや検索条件の表示、選択した項目の一覧表示、ラベル/分類タグ。

ツールチップ

ツールチップ（Tooltip）とは、ユーザーが要素にカーソルを合わせたときに表示される、補足的な情報を示す小さなポップアップUI。 主にボタンやアイコン、略語などの意味や用途を一時的に説明するために使われる。

モーダルダイアログ

モーダルダイアログ（Modal Dialogue）とは、ユーザーの画面上に最前面で表示され、背景の操作を一時的にブロックするダイアログウィンドウのこと。 主に「確認」「警告」「入力」など、ユーザーの注意を引き、即時の対応を求める用途で使われる。

バッジ

バッジ（Bedge）は、主に小さな円や角丸長方形の中に数字や短いテキストを表示して、 「その要素に関連する情報がある」ことを強調するために使われる。 代表的な用途としては、通知件数や、カート中の商品数、ユーザーのオンライン状態、新着情報など。

メッセージアラート

メッセージアラートは、画面上に固定表示される通知UIで、ユーザーにエラー・警告・成功など重要度の高い情報を明示的に伝えるための視認性の高い帯状の要素。 主に画面上部やフォーム直下のコンテンツ内に表示され、ユーザーが閉じない限り残り続ける。

トースト

トーストは、画面の端（多くは右上または下）に一時的に表示される（数秒で消える）軽量な通知UIで、 保存や送信の完了など、重要度の低い操作のフィードバックを邪魔せず伝える目的で使われる。基本的に、レイアウトには属さず、オーバーレイで表示される。

プログレスステッパー

複数の工程（ステップ）を視覚的に並べて、現在どのステップにいるかを線や番号・アイコンで示すUIコンポーネント。 ステップインジケーターやマルチステップUIとも呼ばれる。 主な用途は、会員登録や購入フロー、アンケートなどのマルチステップフォーム。

＊カウンターの「+」「−」ボタンのことをステッパー（数値ステッパーまたは、カウンター型ステッパー）と呼ぶことがあるので混同しないように注意。

カルーセル

カルーセル（carousel）とは、WebやアプリのUIにおいて、複数のコンテンツ（画像・カード・バナーなど）を横にスライドして切り替えられるUIコンポーネントのこと。 スライダーとも呼ばれる。 主な用途としては、トップページのバナー表示や、商品ギャラリー、カードリストなど、情報をコンパクトに見せる手段として使われる。 しかし、下記で詳細を述べるが、カルーセルは意外と使い勝手が悪いため使用例はかなり限定される。カルーセルの採用には慎重に。

アコーディオン

インプット

重大な警告

重要な内容の削除などの確認モーダルなどは、セマンティックのエラーを使う。意図せずに注視するような、サイトのカラーとは少し異なる違和感を感じるくらいの色にした方が良い。

Focusについて

WCAGのガイドラインでは、Focusについて、次のような基準を設けている。 第1に、Tabキーで全てのインタラクティブ要素にフォーカス可能にする。 第2に、Tabでの移動順序は論理的であること。 第3に、Tabで移動した時に、フォーカスが視認できる（視認性の高いデザインに）こと。

また、マウスクリックで不要なフォーカスが出ないように、:focusではなく、:focus-visibleを用いた方が良い。 加えて、focusのデザインは視認性が高くなるよう、サイトのテーマカラーに違和感のない目立つ色（青系を使うことが多い）を使用し、outlineを用いると良い。

親指ゾーンを考慮したUI設計

親指ゾーン（Thumb Zone）とは、スマホを片手で持った時に親指が届きやすい範囲のこと。 近年、スマホは大きくなってきており、大きくなるにつれて、画面上部に親指が届かないケースが増えている。 こうした背景から、親指ゾーンを考慮した、片手操作のしやすいUI設計が重要となっている。

十分なタップエリアの確保

ボタンやテキストリンク、アイコンなど、UI要素の種類に関係なく、タップエリアは44px×44px以上の確保を目安とする。 これは、誤タップを防ぎ、押しやすさを保つための最低基準であり、スマートフォンのような小さな画面でも快適な操作性を実現する重要な配慮。 特に、テキストリンクはタップエリアが小さくなりがちなので注意。 タップエリアを確保するためには、line-height や padding を使って見た目を崩さずタップ領域を広げるとよい。 ただし、これはあくまでも目安なので、UI審美性の観点から、32px×32px程度のタップエリアにする場合もある。

押下時のデザインについて

box-shadowとtransform: translateY(Xpx);をhover時より小さくして、沈み込むようなデザインにするのが一般的。

エンプティステート

エンプティステートとは、アプリケーションやWebサービスにおいて、まだ表示するデータが存在しない状態を指す。 たとえば、「お気に入りが登録されていない」「検索結果が0件」「投稿がまだない」など、コンテンツが空のタイミングに表示されるUIのこと。 単に「空であること」を伝えるだけでなく、ユーザーに次の行動を促したり、安心感を与えたりする重要な役割を担う。 基本的に、エンプティステートは必ず用意するように。

効果的なエンプティステート

エンプティステートを効果的に設計するためには、いくつかの工夫が必要。 まずは、状態の理由を分かりやすく説明すること。 次に、ユーザーに次の行動を提案すること（例：「＋ボタンで新規作成しましょう」「検索条件を変更して再検索してください」など）。 また、視覚的な要素（イラストやアイコン）を添えることで、空白の印象を和らげ、ブランドのトーンも演出できる。

外部リンク表示のルール

Webサイト内で、外部のWebサイトやサービスへ遷移するリンクには、利用者が「これは外部サイトに移動する」ことを事前に認識できるよう、 リンクテキスト内に外部リンクであることを示すアイコンを表示する。

例

外部リンクを開く（良い例） 外部リンクを開く（悪い例）

テキストリンクのタップエリアについて

テキストリンクは、paddingの調整をしないとタップエリアが狭く押しづらいので、paddingを入れて、クリック（orタップ）可能なエリアを広げる。 目安としては高さ40px以上なので、フォントサイズにもよるが、12pxくらいの余白を入れると良い。 ただし、本文中の中に含まれるテキストリンクに余白を入れると、デザインが乱れるので、下線や色をリンクであることを明示できるようにするのに止める。

良いアニメーションの使い方

1. 重要な要素への視線誘導（動くものに注意が向く習性の利用）:訴求したいポイントや情報などに視線を誘導するためにアニメーション。ただし、動いだり点滅する要素は、ユーザーの注意を引くが、同時に、ユーザーの気を散らす原因にもなるため、視線誘導の手段としてアニメーションを使用するのは慎重にする必要がある。
2. ユーザーに対するフィードバックを与える: ボタンのクリック時に軽微な動きを加えることで、操作が成功したことを視覚的に伝える。 ハンバーガーメニューを押すとバツに変わるとか、アコーディオンのアローボタンの変形とか。
3. スムーズなトランジション:ページやセクション間の移動を自然に見せ、体験を一貫させる。

悪いアニメーションの使い方

1. 目的や意味のないアニメーション：目的がなく、ただサイトを賑やかな感じや華やかな感じににしたいだけのアニメーションは、ユーザーの目が疲れるし、集中力を損い、離脱率の増加を招く。
2. 情報の遅延:アニメーションで情報が表示されるまでの時間が遅れると、ユーザーの苛立ちを誘発する場合がある。これもユーザービリティを損ない、離脱率の増加につながる。
3. 混乱のリスク:動きが多いことで、どこに注目すべきかが分かりにくくなり、情報伝達が妨げられる可能性がある。

transition-timing-function

アニメーションの時間

1. 一般的なhoverエフェクト

2. 大きな動き（スライドなど）

テキストHover時のアニメーションについて

hover時に文字を太くするアニメーションはNG。 理由は、太くすることで要素のサイズが変わり、他の要素や背景との位置関係がズレることで、ガタつきが生じ、視覚的なノイズとなるから。 基本的にテキストのホバー時のアニメーションでは背景色やフォントのカラーを変化させる等で対応する。

ヒックの法則

選択肢が増えるほど、人は意思決定に時間がかかる。

デザインへの応用

• メニューの選択を減らすこと。
• 重要な情報を優先的に表示するなど。

ミラーの法則

人間の短期記憶の容量は「7(±2)」個の情報までしか保持できない。

デザインへの応用

• 情報を7個以下のグループに分ける。
• 長いフォームはステップごとに分ける。
• アイコンやメニューは適切な数に抑える。

ヤコブの法則

ユーザーは他のサイトと同じような動作を期待する

デザインへの応用

• UIの標準ルールに従う（例：ハンバーガーメニュ、検索バーなど）
• 不要な独自デザインを避ける
• アイコンを他の一般的なサイトと別の意味で用いない（地球マークを地図にしたり、歯車を編集ボタンにしたりしないなど）
• リデザインを行う場合は、移行期間を設けたり、気に入らなければ前のバージョンに戻せるなどの用意が必要。リデザインで大きく顧客を失う事例もある（スナップチャットとか）。

シリアルポジション効果

人は最初と最後の情報を覚えやすい

デザインへの応用

• 重要なコンテンツをページの冒頭と末尾に配置
• ナビゲーションメニューでは最も重要な項目を最初と最後に置く

プロスペクト理論

人は利益を得る喜びより、損失を避ける心理の方がはるかに強い

デザインへの応用

• 割引や期間限定キャンペーンを提示
• 「今買わないと損！」と感じさせるUI
• 返品保証やリスク軽減策を強調

ドハティ闘値

0.4秒以内にフィードバックを返すと、ユーザーの操作がスムーズに感じる

デザインへの応用

• ローディンアニメーションを短くする
• 時間のかかる処理を行う場合は、プログレスバーなどで処理が進んでいることを伝えると、体感の待ち時間を減らせる。
• ＊なお、ユーザーの注意をタスクに引きつけることができるのは10秒が限界とされており、それを超える場合は完了までの時間や進行中の表記を加えると良い。

フォールス・コンセンサス効果

デザイナーや開発者は「自分の考えが一般ユーザーにも通じる」と思いがち

デザインへの応用

• ユーザーテストを重視する
• デザインをチーム内だけでなく、実際のユーザーに試してもらう
• ユーザーペルソナを作成し、客観的に分析する

美的ユーザービリティ

見た目が美しいデザインは、使いやすいと認識されやすい

デザインへの応用

• 美しいタイポグラフィ、適切な配色、整ったレイアウト
• 高品質な画像や視覚効果を取り入れる
• 余白を適切に活用し、洗練された印象を与える

ログイン画面の時のバリデーションエラーの内容

メールアドレスとパスワードでログインするタイプのログイン画面において、 メールアドレスかパスワードのいずれかを間違えてログインに失敗した場合、 エラーメッセージには、必ず「メールアドレスかパスワードのいずれかが間違っています」と、どちらが間違っているかわからないような表記にする。 「このメールアドレスは登録されていません」や「パスワードが間違っています」のような、どちらが間違っているかをわかるような表記は避ける。

理由は、ブルートフォース攻撃（総当たり攻撃）を防ぐため。 「このメールアドレスは登録されていません」とあると、攻撃者が「このメールアドレスは存在しない」と判断できる。 また、「パスワードが間違っています」とあると、「このメールアドレスは存在するけどパスワードが違う」と分かる。 以上より、不正ログイン対策のため、、エラーメッセージには、メールアドレスかパスワードどちらが間違っているのか明記しないことが重要となる。

オートレイアウトの利用

基本的には、すべてのフレームでオートレイアウトを利用する。 理由は、①開発時の実装と構造を一致しやすくため、②コンポーネントの再利用性を高めるため、③レスポンシブ対応のしやすさ、 ④デザインの変更容易性の向上、⑤要素の整列、間隔の統一（手動配置だと微妙にズレや見落としが発生する）。

また、オートレイアウトを使用する際は、オートレイアウトの詳細設定から「線」を「レイアウトに含まれる」に変更すると、実装との親和性がとれる（実装でも基本box-sizing:boder-box;を使うから）。

コンテンツを内包とコンテンツに合わせて拡大の利用

SP表示のボタンや2カラムレイアウトなど、画面幅に合わせて幅を変動させたい場合は、オートレイアウトを使用し、 親要素に「コンテンツを内包」と子要素に「コンテンツに合わせて拡大」、最大幅の指定を利用する。 そうすることで、実装でmax-width:固定値; width:100%;を指定したのと同じ表現ができる。

レイヤー構造はHTMLの構造に沿って作る

figma上でのレイヤー構造は、HTMLの構造に沿って作る。 オートレイアウトを使用する場合は、HTMLのように構造化してレイヤーを作らないと、親子関係を保てなかったり、レスポンシブ対応が難しくなる。

絶対位置の利用

オートレイアウトを利用している際、オートレイアウトを無視して、コンテンツの右上にアイコンを置きたい等の場合は、「位置」の右にある（2025/03時点でのUI）「オートレイアウトを無視」と「制約」を利用するとよい。 これによって、オートレイアウトを使用しながら、position: absolute;を使用しているのと同じような表現ができる。

＊制約：top, left, bottom, rightの基準点を指定するもの

コンポーネントプロパティ「テキスト」

コンポーネント内のテキストをプロパティとして管理し、インスタンスごとに簡単に変更できる機能のこと。 これを用いることで、以下の利点がある。 ①インスタンスごとのテキストの変更が容易になる。 ②レイヤーのテキストの命名が統一され、管理が容易になる。 ③フォーマット崩れ、バリアントの肥大化を避けられる。 ④開発者との連携がスムーズになる（変更可能な部分であることの理解、デザインとコードの整合性）。

コンポーネントにネストされたインスタンスを利用している場合は、コンポーネントのプロパティで「ネストされたインスタンス」を選択することで、ネストされたインスタンスのプロパティも使用可能となる。

「スタイル」ではなく「バリアブル」の利用

基本的に、色やサイズ、間隔、数値などはスタイルではなくバリアブルで管理する。 バリアブルの方が、スタイルより多くの種類を統一的に管理でき、CSS変数やデザイントークンに近い形でデザインできる。 また、バリアブルにはモードがあるため、ダークモードなどテーマの切り替えも容易である。 加えて、バリアブルはタイポグラフィーだけでなく、余白やボーダーの角丸なども変数化できるため、コンポーネントやオートレイアウトとも相性が良い。

figma上でのタイポグラフィーの管理

バリアブルとスタイルを併用していくのが現時点ではベターなのではないかと考えられる。 バリアブルでタイポグラフィーを管理すれば、デザインシステムの整理にはメリットがあるが、いくつかの問題もある。 第1に、バリアブルをスタイルに適用すると、行間（line-height）、文字間（letter-spacing）は%ではなくpxで指定されるため、汎用性が低い（フォントのサイズ毎に文字間と行間をpxで指定する必要がある）。 第2に、バリアブルでは、書体、太さ、サイズ、行間、文字間を別々で指定する必要があり、一括管理できない。一方で、スタイルでは、それらを一括管理できる。 以上のことから、現時点では、タイポグラフィーの管理には、バリアブルとスタイルを併用するのがベターだと考える。

また、line-heightはスタイルで%指定しない方が良い。%で指定すると、フォントサイズによっては高さがどうしても4や8の倍数にならず、小数点が発生するから。 したがって、バリアブル内で、各フォントサイズごとに固定値でline-heightを指定して（例：font-sizeが48pxでline-heightが72pxなど）、スタイル内でバリアブルの値を代入するのが良い。

下線を引くアニメーションの実装の際の注意

Hover時にborder-bottomで下線を引くアニメーションをつける場合、デフォルトの状態でborder-bottom:transparent;にしないと、要素がホバー時に動いて不自然な挙動になるので注意。

表示切り替えとアニメーションについて

display: none; から display: block; への切り替えは、CSSアニメーションやトランジションの対象にならない。 display プロパティは「離散値（discrete value）」であり、値が切り替わる瞬間に要素の表示状態が一気に変化するため、中間状態を表現できないため。 そのため、要素の出現や消失にアニメーションを付けたい場合は、opacity や transform など、数値で補間可能なプロパティを利用する。 例えば以下のように、非表示時は opacity: 0; にしておき、表示時に opacity: 1; へ、トランジションさせることで、フェードイン効果を実現できる。

Hover時アニメーションのOpacityについて

ボタンのhover時アニメーションでopacityを下げるのは少しチープに見える。 Opacity下げるアニメーションは基本ロゴが画像とかの時など、最終手段として用いる。 hover時はborderやbox-shadow、色（colorとbackground-color）の濃淡で対応するとチープに見えない。

戻るボタンは極力使わない

近年のUIトレンドとして、単純な「戻るボタン」は減っている。 代わりにバツボタンや、スワイプジェスチャー、パンくずリストやタブ、ページごとに完了や閉じるのアクションなどが使われている。 このようなトレンドの変化の背景には、シンプルでミニマルなUIが好まれ、UIノイズを減らす目的で戻るボタンを置かなくなったことや、 ジャスチャーやUXが進化し、スワイプで戻れる、バツで閉じるなど、行動が洗練されてきたことがある。

黒で#000は極力使わない

黒で#000を使うと、背景色の白やグレーとのコントラストが強すぎて、目が疲れてしまう。 また、紙面上の黒インクは完全な黒ではなく、周囲の光の反射で少しグレーに見える。一方で、デジタルデータの黒（#000）は光を完全に吸収する黒なので、不自然に映る。 したがって、黒を用いる場合は、#1c1c1cなど、少しグレーがかった黒を用いるのがいい。

明朝体・セリフ体でboldは極力使わない

太くしたいなら、weight500（semibold）まで。明朝やセリフ体は、横線が細く、縦線が太いという特性があり、太さのコントラストが美しさの要因となっているから、boldにするとその美しさが損なわれてしまう。

インタラクションコストについて

インタラクションコストとは、ユーザーが目的を達成するために必要な労力を指す概念。 主に、認知的コスト、物理的コスト、時間的コストに分類することができる。 認知的コストとは、ユーザーが考える必要のある負担のこと。例えば、「このボタンを押したらどうなるのかわからない」、「どこをクリックしたらいい？」といったもの。 物理的コストとは、クリックやスクロール、入力などの操作負担のこと。例えば、「ボタンが小さくて押しづらい」、「入力フォームが長すぎる」など。 時間的コストとは、目的達成にかかる時間のこと。例えば、「ページの読み込みが遅い」、「複雑なプロセスを経ないと、目的の情報に辿り着けない」など。 基本的には、これらのインタラクションコストをいかに下げるかが、ユーザー体験を向上させる上では重要となる。

しかし、認知的コストと物理的コストの2つはトレードオフの関係にあることが多い。この際、どちらを優先すればいいのか。 まず、認知的コストを優先して下げるべきケースは、初心者ユーザーが多い、複雑な情報を扱うUI,タスクの正確性が求められる場合である。例えば、ECサイトの購入プロセスや、金融系のフォーム。 次に、物理的コストを優先して下げるべきケースは、アクティブユーザーが多いサイト・アプリ、上級者向けの専門的なツール（フォトショップとか）、効率が求められる作業などである。

情報のグルーピング方法

• 背景色のコントラスト：セクションの区切りなど大きな切り替えに利用
• 余白：繋がりが強いけど区切りたい。例：段落の区切りや、同じグループ内のカードの区切り
• 罫線：大きな区切りではあるけど、余白の時と同じ程度のつながりの区切りでも使える。ただし、乱用するとUIが汚く見えるので使用は限定的に（罫線の中に罫線は使わないなど）。

最大文字数の考慮

基本的にカード内など、限られた領域内にコンテンツを表示させる場合は、最大文字数の考慮して設計する。 Figma上ではトランケート機能で表現できる。

画像の種類について

コーディング関係

• DOM(Document Object Model)：HTMLやXMLをプログラムから操作可能な構造として表したもの。
• メディアクエリ：画面サイズやデバイス条件に応じてCSSを切り替える仕組み。

デザイン関係

• CI(Corporate Identity)：企業の理念や姿勢、存在意義を社会に伝えるための、企業の「アイデンティティ設計」のこと。通常MI, BI, VIで構成。
• MI(Mind Identity)：理念・使命・ビジョン・価値観など
• BI(Behavior Identity)：行動指針・企業文化・マナーなど
• VI(Visual Identity)：ロゴ・色・フォントなどの視覚要素
• アフォーダンス：オブジェクトの形状や見た目から操作方法を直感的に理解させる性質。
• ヒューリスティック評価：経験則や既知の原則に基づいてUIを評価する方法。ユーザーテストの前段階によく使われる。

命名規則に関して

• kebab-case：単語をハイフン（-）で区切る形式。HTMLのクラス名、CSSのカスタムプロパティ名に使われることが多い。
  例）user-profile-image
• snake_case：単語をアンダースコア（_）で区切る形式。データベースのカラム名、Pythonの変数名などに使われることが多い。
  例）user_profile_image
• PascalCase：単語の先頭をすべて大文字にする形式。OOPのクラス名、コンポーネント名（Reactなど）に使われることが多い。
  例）UserProfileImage
• camelCase：先頭単語は小文字、2単語目以降は先頭を大文字にする形式。JavaScriptの変数名や関数名に使われることが多い。
  例）userProfileImage