モーションの品位 (Motion Quality)

ボタンを押すたびに画面全体がぐるりと回転する。モーダルが開くのに1秒かかる。スクロールするたびに要素がふわふわと飛び込んでくる——これらはすべて「動きがある」UIですが、ユーザーにとっては苦痛です。

モーションの問題は2つの方向から起きます。 過剰な動き は視線を奪い、タスクへの集中を妨げます。 遅すぎる動きはシステムが止まっているように見え、ユーザーを不安にさせます。どちらも「動きのためのデザイン」であり、「ユーザーのためのデザイン」ではありません。

よくある失敗は「おしゃれに見せたい」という動機でアニメーションを追加することです。結果として、毎回同じ演出を見せられるユーザーは「早く終わってくれ」と感じ、操作のテンポが崩れます。

1. 原則の定義

UIにおけるモーションは、ユーザーの理解を助け・操作を促進し・状態変化を伝えるための「機能」として設計する。

本質は「モーションに意味を持たせること」です。「なぜここで動くのか」に答えられないアニメーションは削除すべきです。逆に、適切なモーションはユーザーに「何が起きたか」「次にどこへ行けばいいか」を言葉なしに伝え、認知負荷を下げます。

2. いつ使うか（適用場面）

特に重要になるケース

• 状態変化の伝達: ボタンのローディング状態、フォームの送信完了、トグルのON/OFF切り替えなど、システムの状態が変わる瞬間。モーションがないと「本当に押せたのか？」という不安が生まれる。
• 空間的な文脈の提供: モーダルやドロワーの開閉、画面遷移など、「どこから来てどこへ行くのか」を示す場面。スライドインの方向が「右から来た＝前に進んだ」という空間モデルを作る。
• 注意の誘導: エラーメッセージの出現、バッジの更新など、ユーザーに気づいてほしい変化がある場面。

トレードオフが起きる場面

• パフォーマンス vs 演出: 複雑なアニメーションはCPU/GPUを消費し、低スペック端末では逆にカクつく。視覚的な豊かさとパフォーマンスのバランスが必要。
• 前庭障害（Vestibular Disorder）への配慮: 一部のユーザーは、大きなスケールや回転のアニメーションで乗り物酔いに似た症状を起こす。prefers-reduced-motion メディアクエリへの対応が必要。

3. なぜ重要か（設計判断の核）

モーションは「装飾」ではなく、「状態変化の翻訳」である。

設計判断の基準

• 「このアニメーションを削除したら、ユーザーは何かを理解できなくなるか？」→ Noなら削除候補。Yesなら機能的なモーション。
• 「このアニメーションの時間は、ユーザーが待つ価値があるか？」→ 操作のたびに見せるものは100〜300ms以内が原則。

優先順位の考え方

• 1. 機能的モーション（最優先）: ローディング、エラー表示、状態変化の伝達。これがないとUIが壊れる。
• 2. 空間的モーション: 画面遷移、モーダル開閉。文脈の理解を助ける。
• 3. 表現的モーション（最後）: ブランドの個性を表すアニメーション。機能が完璧になってから検討する。

例外条件

• ローディング画面など「待ち時間が長いことが確定している」場面では、演出的なアニメーションがストレス軽減に機能する。ただし、ループアニメーションは単調にならないよう工夫が必要。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーはシステムの状態を把握できません。

インタラクティブ要素の状態変化にモーションがあるか: ボタンのホバー・クリック・ローディング・ディセーブル状態が、色変化やアニメーションで視覚的に区別されているか？
アニメーション時間が適切か: 繰り返し見るUI要素（ボタン、トグル、ドロップダウン）のアニメーションは100〜300ms以内に収まっているか？（500ms超は「遅い」と感じられる）
に対応しているか: OSの「視差効果を減らす」設定を有効にしているユーザーに対して、大きな動きのアニメーションを無効化または代替表現に切り替えているか？

理想ライン（Better - できると強い/プロの品質）

モーションが「品位」として機能している状態です。

イージング（Easing）が自然か: アニメーションが一定速度（linear）ではなく、物理法則に沿ったイージング（ease-out：素早く始まり緩やかに終わる など）を使っているか？
方向性の一貫性があるか: 「右スワイプ＝前進」「左スワイプ＝後退」「下からポップアップ＝モーダル」など、モーションの方向とUIの空間モデルが一致しているか？
モーションの統一性があるか: 同じ種類の状態変化（例：全てのモーダルの開閉）が、プロダクト全体で同じアニメーションを使っているか？

5. UI例

「ボタンを押した後」の状態変化を、モーションなし・過剰なモーション・適切なモーションで比較します。

改善プロセス

1. モーションの棚卸し: 現在のUIで使われているアニメーションをすべてリストアップし、「このモーションがなければ何がわからなくなるか？」を問う。答えられないものは削除候補。
2. 時間の最適化: 各アニメーションの時間を計測し、繰り返し見るものは200ms前後に調整する。
3. イージングの統一: ease-out（素早く始まり緩やかに終わる）を基本とし、プロダクト全体で統一する。

6. 関連リンク

• 関連リファレンス（理論）: 認知負荷
• 用語集（定義）: アニメーション
• 関連するUI原則（横）: フィードバック (Feedback), コンポーネントの視覚一貫性 (Component Consistency)

7. まとめ

今日から直せる一手 プロダクト内で最も頻繁に操作するボタン（送信・保存など）を1つ選び、「押した後に何かが変化しているか（色・アイコン・テキスト）」を確認してください。何も変わっていなければ、今日中にローディング状態を追加しましょう。

チームに共有するなら一言 「アニメーションは感情ではなく、情報だ。『なぜここで動くのか』に答えられないなら、それは削除すべき雑音である。」