デザイン批評という存在を認識した

2/26に開催されたFront-End Study #4【いま考えるユーザー体験とデザインの世界】に参加して学んだことをまとめ…ようと思って数ヶ月経ってしまったけど、GW到来につき満を持したのでまとめてみようと思います。

（どのトークもありがたい人によるありがたいお話で感動が止まりませんでしたし、エンジニア目線での話を聞くことで新しい発見や自分が実装するときに意識するべきことも新しくたくさん学べていい会でした！！！！）

登壇者の皆さん全員分のお話内容をまとめたい気持ちは山々ですが、一人ずつということでまずはtakanorip（@takanoripe）さんによるデザイン批評についてのお話を自分の勉強メモ程度にまとめます。

※　私なりに学んだことを私がやりたいようにまとめていますので、表現や構造など色々異なるところがあります。

概要

- デザイン批評には適切な方法がある
- デザイン批評とは、そのデザイン（UI）でユーザーが目的を
   達成できるかどうか分析すること
- 見た目ではなく、必要な観点からデザイン（UI）を分析し、
   チーム全体で良いプロダクト開発を目指す

デザイン批評の基本

批判的思考をもって、そのデザイン（UI）が目的を達成するために適切なものなのかどうかを判断すること

→　【批評】なので、適切な方法がある
→　ただ感想を伝えればよいわけではない

また、【　デザイン批評　】と【　デザインレビュー　】は別ものである

「誰の視点から考えているか」を考える
→　その意見は誰目線なのか？（ユーザ？実装者？）ということを意識する

デザイン批評で一番大切なこと

【見た目】にとらわれないこと
→　見た目の好き嫌いについては批評ではない

表層（見た目）にとらわれず、そのデザイン（UI）・設計の本質や意図を考えることが大切

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

1. デザインが目的を達成できているか
2. 使いやすさ
3. UI Stack

1. デザインが目的を達成できているか

そのデザイン（UI）によって何を達成したいのか？
その達成のためになぜそのデザイン（UI）にしたのか？

上記をきちんとデザイナーがチームメンバーに説明する義務もあるし、チーム全員がその目的を理解し、デザインによってその目的を達成できるか否かという批評の基準をしっかり定めることが大切

2. 使いやすさはどうか

詳しく学ぶにはユーザビリティの本をたくさん読む！

着目点は２つ↓

達成したいことを迷わずにユーザーが達成（操作）できるか
- 情報の過不足がないか
- 行動を邪魔する要素がないか

情報は多すぎても煩雑になり求めている情報にたどり着けないし、オンボーディングで申し込みまで完了してほしいけど途中で別ページに離脱する要素がある、などなど

ダークパターンになっていないか
- こちらがしてほしいことをユーザーに強制していないか
- ユーザーを騙していないか

CVや数字を意識するあまり意図せず生み出してしまうケースもあるので、それをデザイン批評で防ぐことも大切

なぜダークパターンが良くないのか？
- UXが低下する
- 会社やブランドイメージの低下につながる

あの会社のサービスはいつもユーザーを騙して商品を買わせるよね、あの会社はいつも紛らわしい広告でこちらが求めていないページに誘導してくるよね、などなど

3. UI Stack

UIの基本的な５つの状態
- Blank State
- Loading State
- Partial State
- Error State
- Ideal State

出典：https://www.scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack/

上記の5要素が実装的にもユーザビリティ的にも満たされている必要がある

デザイン批評で考慮すべきポイント

1. UIの一貫性
2. 実装難易度
3. データとUIの関係性

1. UIの一貫性

- スタイルの一貫性
　色やmarginなど
- コンポーネントの役割の一貫性
　ハテナアイコン押してこっちはツールチップだけどこっちは
　モーダル出てくる…みたいになっていないか
- インタラクションの一貫性
　インタラクションの意味が個々でばらけていないかどうか

なぜ一貫性が大切なのか？
高い確率で負債になるから
新しいデザイナーやエンジニアが入ったときに、この差はなに・・・？が多発するも、きちんと決めないのでどれが正しいのか不明
→　どれが正しいかをまた考えたり話すという無限ループになる

2. 実装難易度について

本来はデザインが始める前（仕様策定段階）で確認しておくべきこと

何ができて何ができないか、なぜできないのか、代替案の検討案などをデザイナーとエンジニア間でしっかりとすり合わせる

★実装することが目的ではなく、あくまでも【ある目的】を達成するためのUIとその実装であるという認識を忘れないようにすることが大切

3. データとUIの整合性

データ構造とUIに矛盾がないかどうか
- DB
- API
- マイクロサービス
などなど

既存のデータ構造とUIが一致していない場合、どちらを修正すべきなのか話し合う必要がある（裏で取得していないデータをUIの表示項目に盛り込んでいる、など）

★実装が始まってから、Fixしたデザイン（UI）を見て「そのデータ取得してないんだよね」、「その実装は工数爆上がりするよ…」という事態になるのは避けるべき

まとめ・感想

デザインやUI設計の意図を考えることは大切と分かっている（知っている）ものの、じゃあ実際に何に気をつけてどのポイントをチェックして、というのは結構宙ぶらりんだったりするので、仕事で早速実践していきたい！！！という胸熱な内容でした。

デザイナー側としても、レビューや批評をお願いするときに、「確認お願いしまーす」で丸投げするのではなくて、きちんと目的や意図を相手に理解してもらえるまで説明して、その上で「上記のような観点についてこのデザインはどうですか？」という聞かれる側が答えやすい聞き方を心がけていくことも大切だなと思った。

このトピックについて
間違いを指摘したい！！！
このトピックについて語り合いたい！！！
単純にデザイナー仲間ほしい！！！
自分はデザイナーじゃないけどデザイナーの知り合いほしい！！！

などなど、お気軽にコメント・Twitterなどでコンタクト取って頂けますと幸いです＼(^o^)／（@yr_tms）

お待ちしております〜〜〜

↓　forkwellさんのYoutubeチャンネルで公開されていますのでおすすめです