design-engineering

デザインエンジニアリング

ほとんどのソフトウェアが十分に機能する世界では、違いを生むのは使い心地です。 インターフェースがしっくりくるかどうかを左右する要素の多くは、ユーザーが意識して気づくことのない細部です。小さな正しい選択の積み重ねです。その積み重ねを大切にして作りましょう。

モーションの判断フレームワーク

アニメーションを書く前に、次の問いに順番に答えてください。

1. そもそもアニメーションさせるべきですか？

判断の決め手は頻度です。ユーザーが目にする回数が多いほど、動きを抑えるべきです。

ユーザーが目にする頻度	判断
1 日 100 回以上（ショートカット、コマンドパレット）	アニメーションなし。例外もなし
1 日に数十回（ホバー、リストのナビゲーション）	削除するか、大幅に減らす
ときどき（モーダル、ドロワー、トースト）	標準的なアニメーション
まれ、または初回（オンボーディング、お祝い）	遊び心を加える余地あり

キーボード操作で開始されるアクションは、決してアニメーションさせないでください。一日中繰り返される操作なので、アニメーションがあると遅く、キー入力と切り離されているように感じられます。

2. 目的は何ですか？

すべてのアニメーションには、「なぜ動くのか？」への答えが必要です。妥当な理由は、空間的一貫性（同じ端から入って、同じ端へ出る）、状態の変化、フィードバック（押下をインターフェースが受け取ったと知らせる）、または唐突な表示・非表示を防ぐことです。「見た目がかっこいい」は、ユーザーが頻繁に目にするものの目的にはなりません。

3. イージングはどうしますか？

• 表示または退出 -> ease-out（開始が速く、レスポンシブに感じられます）。
• 画面上での移動またはモーフィング -> ease-in-out。
• ホバーまたは色の変化 -> ease。
• 一定の動き（マーキー、進捗表示） -> linear。

UI で ease-in は決して使わないでください。動き始める瞬間、つまりユーザーが見ているまさにそのときの動きを遅らせるため、300ms の ease-in ドロップダウンは、300ms の ease-out より遅く感じられます。組み込みのカーブは弱いため、より強いカスタムカーブを使いましょう。

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);       /* UI interactions */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);   /* on-screen movement */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);    /* iOS-like drawer */

4. どのくらいの速さにしますか？

要素	期間
ボタン押下のフィードバック	100-160ms
ツールチップ、小さなポップオーバー	125-200ms
ドロップダウン、セレクト	150-250ms
モーダル、ドロワー	200-500ms

頻繁に使うインタラクティブ UI は 300ms 未満にしてください。上記のモーダルとドロワーの範囲（最大 500ms）は、たまにしか表示されない初回向けの画面のための意図的な例外です。体感速度は実際に影響します。同じ読み込み時間でも、スピナーを速くすると読み込みが速く感じられます。また、最初のツールチップの後に表示されるツールチップを即座に表示すれば、ツールバー全体が素早く感じられます。

スプリング

スプリングは固定時間ではなく物理法則に従って収束するため、生き生きとした印象になります。また、CSS キーフレームとは異なり、動きを途中で止めても速度を保ちます。ユーザーが動作中に反転できるドラッグやジェスチャーのインタラクション、マウスを追従する装飾的な動きに使いましょう。バウンスは控えめ（0.1〜0.3）にし、通常は使わないでください。ドラッグして閉じる操作や遊び心のある場面に限り、機能的な UI では避けましょう。

コンポーネントの使い心地

• 押下時のフィードバック。 押下可能なすべての要素には、:active 時に transform: scale(0.97) を適用し、ease-out のトランジションを約 160ms に設定します。控えめな変化（0.95〜0.98）でも、インターフェースが操作を受け付けているように感じられます。
• scale(0) からアニメーションさせないでください。 現実のものが無から現れることはありません。scale(0.9) 以上の値と不透明度から開始し、表示時に形を持たせましょう。
• トリガーを起点に拡大縮小します。 ポップオーバーやドロップダウンは中心ではなく、起点から拡大縮小します。モーダルは中央にとどめます。
• prefers-reduced-motion を尊重してください。 必須ではない動きは削除するか、短くしてください。

ビジュアルの基礎

• 余白のスケールと文字サイズのスケールは、それぞれ 1 つに統一します。一貫性は意図を感じさせ、場当たり的な値はノイズになります。
• 色は控えめにします。明確な役割を持つ小さなパレットは、多数のアクセントカラーより効果的です。
• ホバー、アクティブ、フォーカス可視、無効など、インタラクティブな状態をすべて明示します。状態のないコントロールは、反応がないように感じられます。

レビュー形式

UI コードをレビューするときは、問題ごとに1行を使用した単一の Markdown テーブルで出力し、 Before | After | Why の形式にしてください。「Before:」／「After:」の行を個別に分けないでください。

Before	After	Why
transition: all 300ms	transition: transform 200ms ease-out	プロパティを正確に指定し、all は避けます
transform: scale(0)	scale(0.95); opacity: 0	何もないところから現れることはありません
ドロップダウンの ease-in	強い ease-out	ease-in は動きが遅く感じられます
:active 状態がない	:active で scale(0.97)	押したときの反応は機敏に感じられる必要があります