「触ればわかる」のためのUIモーション

より良いUIを作るために、UIモーションを活用することについての提案と、その際の問題とその解決策を考えます。

この資料はSvelte Japan Offline Meetup #9での登壇資料です。

Transcript

1. 「触ればわかる」 のためのUIモーション HIBIKI CUBE @hibiki_cube
2. 良いUIって、 どんなもの…？
3. 説明されなくても 分かる・使える
4. 説明されなくても 分かる・使える → 触れば分かるUI
5. 触れば分かるUIってどんなもの…？ • デザインに一貫性がある（一度学べばその知識が活きる） • すでに受け入れられているデザイン（もう学んでいる知識が活きる） • 操作に対して適切なFBがある（UIの意図を学びやすくなる） • 不可逆 / 破壊的な操作を安易にさせない（失敗 = 学習しやすくなる）
6. 例えば…
9. 触れば分かるUIってどんなもの…？ • デザインに一貫性がある（一度学べばその知識が活きる） • すでに受け入れられているデザイン（もう学んでいる知識が活きる） • 操作に対して適切なFBがある（UIの意図を学びやすくなる） • 不可逆 / 破壊的な操作を安易にさせない（失敗 = 学習しやすくなる）
10. 触れば分かるUIってどんなもの…？ • デザインに一貫性がある（一度学べばその知識が活きる） • すでに受け入れられているデザイン（もう学んでいる知識が活きる） • 操作に対して適切なFBがある（UIの意図を学びやすくなる） • 不可逆 / 破壊的な操作を安易にさせない（失敗 = 学習しやすくなる）
11. WebのUIで出来るFBの表現 • :hoverなどの擬似クラスを使った表現 • JSによるクラスのつけ外しによる表現 • JSでtransformなどを直接変化させることによる表現 • SvelteのTransitionやMotion（旧Framer Motion）などによる表現
12. モーションは 誰の担当……？
13. モーションは誰の担当……？ • 企画・要件定義（ディレクターやPM） • 仕様作成（ディレクターやPM？デザイナーも？エンジニアも？） • デザイン・モック作成（デザイナー？） • 設計（エンジニア？） • 実装（エンジニア？）
14. 私自身のモヤモヤの経験 • 機能要件は定まっているが、動きまでは決まっていない • デザイナーが決めるのはあくまでも各画面・各状態の静的な見た目 • かといって、エンジニアが実装時に勝手に付け加えるのも憚られる • Svelteのtransitionがある既存の画面にデザイナーさんが CSSでアニメーションを追加してしまいイマイチな感じに…
15. 私自身のモヤモヤの経験 • 機能要件は定まっているが、動きまでは決まっていない • デザイナーが決めるのはあくまでも各画面・各状態の静的な見た目 • かといって、エンジニアが実装時に勝手に付け加えるのも憚られる • Svelteのtransitionがある既存の画面にデザイナーさんが CSSでアニメーションを追加してしまいイマイチな感じに… → モーションは軽視されがち
16. 「誰がやってもいい」 だから起こる問題
17. 「誰がやってもいい」だから起こる問題色々 • デザイナーがモーションを作る場合 ◦ ロジックで持っている「状態」を十分に考慮できない ◦ 条件によるモーションの出し分けが難しい（in/outで違う動き等） • エンジニアがモーションを作る場合 ◦ デザイナーと別途擦り合わせが必要になる ◦ CSSで出来るはずのものをイベント駆動で作ってしまう
20. Svelteのtransitionのいいところ • Svelteの状態管理とシームレスに連携できる • Svelteに元から入っている（技術選定をしなくていい） • 双方向の動きを簡単に作れる • in:とout:を簡単に管理できる • アクセシビリティ的にも丁寧な対応がしやすい（prefers-reduced-motionなど）
21. transitionを武器に”もっと”良いUIを作るために • まずはチームでUIにおける「モーション」の大切さを知ってもらう ◦ ただ動けばいい、ではなく「意味を伝える動き」であるべき • モーションの意思決定を誰がするのか、仮にでも決めてみる ◦ 良いUIはユーザーが自分で学べる→より使ってもらえる→KPI • 兎にも角にも、まずは使ってみるのいちばん！
22. 「触ればわかる」 のためのUIモーション HIBIKI CUBE @hibiki_cube