Upgrade to Pro — share decks privately, control downloads, hide ads and more …

共創するためのデザイン批評

78f5efc1e98c71e473cc7827de1c5db4?s=47 takanorip
February 26, 2021

 共創するためのデザイン批評

78f5efc1e98c71e473cc7827de1c5db4?s=128

takanorip

February 26, 2021
Tweet

Transcript

  1. 共創するためのデザイン批評 2021.02.26 Takanori Oki @Front-End Study #4 「いま考えるユーザー体験とデザインの世界」

  2. 自己紹介 • UI designer at ClassDo • Organizer of Web

    Platform Study Group • Figma, Web Font, 11ty, etc… • 最近引っ越しました 2
  3. デザイン批評の基本 3

  4. デザイン批評の 基本 • 批判的思考 • デザインがプロダクトの目的を達成するために 適切かどうかを判断する • 批評には適切な方法があり、それを学ぶ必要がある •

    ただ感想を伝えれば良いわけではない! 4
  5. 批評とレビューの違い 5 デザイン批評 デザインが目的を達成できる か判断するための分析手法。 デザインレビュー デザインの承認や合意形成の ために行われるミーティング。

  6. ベスト プラクティス • 質問で始める • 感情のままに話さない • 自分の意見が正しいと思い込まない • 意見を押し付けない

    • 長所について話す • 「誰の視点から考えているか」を考える 6
  7. みんなではじめるデザイン批評 7 チームでどのようにデザイン批評を実践するか 体系的に解説した名著(個人的) みんな読もう

  8. デザイン批評で大切な3つの観点 8

  9. その前に… 9

  10. デザイン批評で一番重要なことは 「見た目」にとらわれないこと 10

  11. 見た目の好き嫌いを表明することは 「批評」ではない 11

  12. 「デザインのセンスがないから…」 というのは一番言ってはいけない言葉 12

  13. 見た目にとらわれない 13 表層にとらわれず、その本質を見極める 見た目の裏側を意識する

  14. デザイン批評で大切な3つの観点 14 デザインの目的 使いやすさ UI Stack

  15. デザインの目的 15

  16. デザインの目的 • なぜこのデザインにしたのか • この「なぜ?」をチーム全員が理解することが重要 • これがレビューの「基準」となる • 見落としてる要件はないか 16

  17. 使いやすさ 17

  18. 使いやすさ • 達成したいことを迷わず達成できるか • 情報の過不足がないか • 行動を邪魔する要素がないか • etc… •

    ダークパターンになってないか • こちらがしてほしいことを強制していないか • ユーザーを騙していないか 18
  19. ダークパターン デザイナーやマーケターが意図せず ダークパターンを生み出す可能性もある ダークパターンはUXを低下させるだけでなく 会社やブランドのイメージ低下につながる デザイン批評でダークパターンを防ぐ 19

  20. UI Stack 20

  21. UI Stack 21 Ideal State Blank State Error State Partial

    State Loading State UIの基本的な5つの状態 https://www.scotthurff.com/posts/ why-your-user-interface-is-awkward- youre-ignoring-the-ui-stack/
  22. デザインレビューで考慮すべきポイント 22

  23. デザインレビューで考慮すべきポイント 23 UIの一貫性 実装難易度 データとUI

  24. UIの一貫性 24

  25. UIの一貫性 • 色やmarginなどスタイルの一貫性 • 各UIコンポーネントの役割の一貫性 • インタラクションの一貫性 25

  26. インタラクション 26 「ユーザーのアクションとそれに対するレスポンスの関係性」

  27. UIの一貫性 一貫性のないデザインを 鵜呑みにしない! 高い確率で負債になる エンジニアは「規則を作り守る」ことに慣れてるので、 エンジニアのほうが気づきやすい 気づいたことは伝えることが大事 27

  28. 実装難易度 28

  29. 実装難易度 • 本来はデザイン始まる前(仕様策定段階)で確認して おくべきこと • 技術面の知識がないデザイナーに対して 「知識を育てる」つもりで、しっかりと説明する • 何が出来て何ができないか、なぜ出来ないか、 代替案はないか、など

    29
  30. 大事な話 • ごまかさない • 「本当はできるけど面倒だから黙っておこう…」 • 相手を侮らない • 「どうせ説明してもわからないだろう…」 •

    本質を探る • 「なぜこのUIを実装する必要があるのか?」 30
  31. データとUI 31

  32. データとUIの 整合性 • データ構造とUIに矛盾がないか • DB • API • マイクロサービス

    • etc... • 既存のデータ構造とUIが一致していない場合、 どちらを修正するべきなのかを話し合う必要がある 32
  33. まとめ 33

  34. まとめ • デザイン批評には適切な方法があるよ • デザイン批評とは、デザインが目的を達成できるか どうかを分析すること • 見た目にとらわれず、必要な観点からデザインを分析 してチーム全体で良いプロダクトを開発しよう! 34

  35. THANK YOU! 35