#513
テスト・評価
#513でざいんひひょう
デザイン批評
別名・表記:Design Critiqueデザインクリティーククリティーク
UIXHERO Definition
UIXHEROでは、デザイン批評を「デザインの目的に照らして、その案が目的を果たせているかを合議で検証する場」と定義する。
概要
デザイン批評が機能するには、開始時点で3つが共有されている必要がある。
- 目的: この画面・機能で、誰が何をできるようになるべきか
- 制約: 技術、期日、ブランド、法的要件など動かせない条件
- 今日聞きたいこと: 全体を見てほしいのか、特定の判断だけなのか
これが揃っていない批評は、参加者が自分の関心事を語る場になりやすい。
UXでの活用
- 早期の欠陥発見: 実装前に前提のズレを見つけられる。ユーザビリティテストより安価に回せる。
- 判断の言語化: デザイナーが「なぜこうしたか」を説明することで、暗黙の判断がチームの資産になる。
- 合意形成: 決定プロセスに関わった人は、その後の実装で判断を差し戻しにくくなる。
誤用・混乱
- 批評とレビューの混同: 承認レビューは可否を決める場、批評は案を良くする場。同じ会議で両方をやろうとすると、率直な指摘が出なくなる。
- ユーザーテストの代わりにはならない: 批評で得られるのは専門家の推測であり、実際のユーザー行動ではない。「批評で問題なかったから大丈夫」とは言えない。
- 人ではなく案を対象にする: 指摘が個人の能力評価に聞こえる場では、次回から案が出てこなくなる。
💡 使いどころ
案が複数ある、あるいは方向性に迷いがある段階。承認をもらう場ではなく、判断材料を増やしたい時に開く。
⚠️ 注意点・誤用
批評は「好き嫌いを述べる場」でも「上長が決裁する場」でもない。目的と制約が共有されていない状態で開くと、単なる感想の応酬になり、デザイナーの心理的負荷だけが増える。
具体例
- 「このボタンは目立たない」ではなく「初回訪問者が次の行動を見つけられるか、という目的に対して弱い」と述べる
- 案A/Bのどちらが良いかではなく、それぞれが目的のどこを満たし、どこを外しているかを整理する
- 決定はその場で下さず、検証すべき点を洗い出して持ち帰る
出典・参考文献:
- Discussing Design (Adam Connor, Aaron Irizarry)
- Articulating Design Decisions (Tom Greever)