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

by takanorip

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 • UI designer at ClassDo • Organizer of Web Platform Study Group • Figma, Web Font, 11ty, etc… • 最近引っ越しました 2

Slide 3

Slide 3 text

デザイン批評の基本 3

Slide 4

Slide 4 text

デザイン批評の基本 • 批判的思考 • デザインがプロダクトの目的を達成するために適切かどうかを判断する • 批評には適切な方法があり、それを学ぶ必要がある • ただ感想を伝えれば良いわけではない！ 4

Slide 5

Slide 5 text

批評とレビューの違い 5 デザイン批評デザインが目的を達成できるか判断するための分析手法。デザインレビューデザインの承認や合意形成のために行われるミーティング。

Slide 6

Slide 6 text

ベストプラクティス • 質問で始める • 感情のままに話さない • 自分の意見が正しいと思い込まない • 意見を押し付けない • 長所について話す • 「誰の視点から考えているか」を考える 6

Slide 7

Slide 7 text

みんなではじめるデザイン批評 7 チームでどのようにデザイン批評を実践するか体系的に解説した名著（個人的）みんな読もう

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

その前に… 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

デザインの目的 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

使いやすさ 17

Slide 18

Slide 18 text

使いやすさ • 達成したいことを迷わず達成できるか • 情報の過不足がないか • 行動を邪魔する要素がないか • etc… • ダークパターンになってないか • こちらがしてほしいことを強制していないか • ユーザーを騙していないか 18

Slide 19

Slide 19 text

ダークパターンデザイナーやマーケターが意図せずダークパターンを生み出す可能性もあるダークパターンはUXを低下させるだけでなく会社やブランドのイメージ低下につながるデザイン批評でダークパターンを防ぐ 19

Slide 20

Slide 20 text

UI Stack 20

Slide 21

Slide 21 text

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/

Slide 22

Slide 22 text

デザインレビューで考慮すべきポイント 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

UIの一貫性 24

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

実装難易度 28

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

大事な話 • ごまかさない • 「本当はできるけど面倒だから黙っておこう…」 • 相手を侮らない • 「どうせ説明してもわからないだろう…」 • 本質を探る • 「なぜこのUIを実装する必要があるのか？」 30

Slide 31

Slide 31 text

データとUI 31

Slide 32

Slide 32 text

データとUIの整合性 • データ構造とUIに矛盾がないか • DB • API • マイクロサービス • etc... • 既存のデータ構造とUIが一致していない場合、どちらを修正するべきなのかを話し合う必要がある 32

Slide 33

Slide 33 text

まとめ 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

THANK YOU! 35