1. この記事の背景と課題意識
デザインレビューでは、よくこんな言葉が出る。
「なんかここ、気持ち悪いんですよね」
言われた側も「たしかに」と直す。直すと実際に良くなる。しかし次の週に別の画面を作ると、また同じ場所で手が止まる。著者がやりたかったのは、一方的に正解を教える講義ではなく、その気持ち悪さを次の画面でも使える言葉に分解する練習だった。
デザイン原則（余白・コントラスト・タイポグラフィの階層）は共通言語として大切だが、教科書の整った作例で理解するのと、現場の泥臭い画面で使いこなすことには距離がある。違和感が先に来て、言葉があとから追いつく——その言葉を引き出せないと「なんか気持ち悪い」という感想で終わってしまう。そのため教材には、綺麗なサンプルではなく自社プロダクトの「賛否が分かれそうな、ちょっと惜しい画面」を選んだ。
2. 会の進め方：指摘する人と掘る人を分けた
ふつうのレビュー（デザイナーが指摘→エンジニアが修正）と逆の役割分担にした。
- エンジニアが、気になる違和感を出す（この時点では根拠がなくてよい）
- その根拠を、デザイナーが一緒に掘り下げる
なぜ役割を分けたのか。違和感を持った瞬間には、まだ誰も根拠を持っていないから。自分の違和感を自分で掘らせると「ちゃんと理由を言えないなら言っちゃいけないのかな」とブレーキがかかり、すでに言語化できる無難なことしか言わなくなる。現場で一番拾いたいのは、その手前の「なんか引っかかる」という生の感覚だ。
相手がエンジニアなのにも意味がある。デザイナー同士だと共通の文脈や専門用語が多すぎて説明をスキップしがち。「それって具体的にどういうことですか？」と純粋に聞き返してくれる相手がいるからこそ、自分がどこを暗黙知で飛ばしていたかが見える。
3. 問いの設計：「良し悪し」を聞かない
掘り下げの問いとして用意したのは「良い／悪い」ではなく、「その画面は何を伝えようとしているか」という意図のみ。良し悪しは好みのぶつけ合いになるが、意図から入ると画面の外にある仕様や前提の話に進める。具体の問いは4つ。
① 最初に目が行くのはどこか
「タイトルが一番目立ってますね」はただの観察で根拠ではない。一歩踏み込んで「その要素に、なぜ一番の優先度が置かれているのか？」を問う。画面に来た人が最初に知りたいことと、一番強く飛び込んでくる要素がズレていないか。ズレの原因（過去の仕様変更の名残、後からの要望で足したボタン等）はたいてい画面の外の歴史にある。
② 余白の差は何を伝えているか
余白は距離の近さで「情報のグループ」を伝える仕組み。聞くべきは狭い/広いではなく「このまとまりは、グループとして本当に正しいか？」。離れているのに無関係なもの・近いのに無関係なもののズレを見つけたとき、違和感の正体は「余白」ではなく「情報の分け方」だと分かる。見た目の指摘が構造の指摘に化ける瞬間。
③ なぜこのパーツが選ばれているか
テーブルは横並び比較、カードは独立した1単位、モーダルは作業を中断してでも集中させたいとき——UIパーツにはそれぞれ前提された「読まれ方」がある。中身の情報の性質と読まれ方が食い違うと「なんか読みにくい」と感じる。
④ 状態まで考えられているか
エラー・0件・ローディングまで想像するかどうか。理想的なダミーデータが入った綺麗な1枚だけだと判断が甘くなる。文字数が異様に長いとき・検索結果が0件のとき・通信が遅いとき、そこまで想像して初めてレイアウト判断の正しさが見える。
4. 根拠には「段」がある（本記事の核心）
掘り下げて出てくる「理由」の強さには明確な差があり、並列のチェックリストではなく下から積み上がる5段の階段になっていた。
- ① 好み「自分は好きじゃない」→ この画面のこの瞬間にしか効かない
- ② 原則の名前「近接の原則が効いていない」→ 名前によって会話の共有ができる
- ③ 画面内の優先順位「一番大事なのは残数なのに3番目に見える」→ 画面の中で議論が成立する
- ④ 他画面との一貫性「一覧画面では同じ情報を右上に置いている」→ プロダクト全体に効く
- ⑤ ユーザーの行動への影響「ここで迷うと前の画面に戻ってやり直す」→ 画面を離れても効き続ける
根拠の強さの正体は、論理的な正しさではなく「どこまで持ち越せるか（射程の長さ）」。⑤まで言えている根拠は、次の画面でも、別機能の設計でも使える。よって言語化の目的は説得ではなく「再現」。説得のための根拠は言いくるめた時点で役目を終えるが、再現のための根拠はチームの共通道具として残る。
なお好みは決して悪い段ではなく「根拠の未完成形」。一番厄介なのは、好みをデザイン原則の名前で言い換えて掘り終えた気になること。
5. 掘るときに引っかかる4つの罠
- 原則の名前を言って満足する — 「近接の原則ですね」で止まる。名前はラベルで根拠ではない。→ すかさず「その原則を守ると画面は何を伝えようとしているのか？」と重ねて聞く。
- デザイナーが待ちきれずに正解を言ってしまう — 一番起きやすく、その場の空気も一番良くなる罠。だが相手が自分の頭で仮説を立てるのをやめてしまう。納得感と学習は別物。
- 「ユーザーが迷います」という想像の捏造 — 5段目は最強ゆえに最も悪用しやすい。「ユーザー」と言い出したら出どころを必ず確認する（問い合わせ？ユーザーテスト？自分の感覚？）。推測でも良いが、「ユーザー」という盾の後ろに隠れないこと。
- 一貫性を理由に揃っている使いにくさを守る — 「他の画面も全部そうだから」は揃っている理由であって使いやすい理由ではない。「どの画面も等しく使いにくい」状態は普通に起こる。元のルール自体が合っているか疑う。
6. 守るルールは3つだけ
- 「正解」を先に言わない — それぞれの仮説を出し切ってからズレを確認する
- 「なぜ」を最低2回重ねる — 1回目の答えはだいたい原則の名前（2段目）で止まる。2回目の「なぜ」を越えられるかが3段目・5段目に届く境目
- 詰まったら自社の実例に戻る — 抽象論だけで終わらせない
7. 根拠が強くても、直さないことがある
根拠の強さと実際に直すかは別の話。強い根拠を出したうえで、コストやスケジュールを考えて「今回は直さない」と決めるのは妥協ではなく立派な意思決定。
「なんとなく変だけど、まあいいか」で流した違和感は、ただ闇に消えていく。でも「優先順位が合っていないが今回のリリースでは見送る」と言葉にして残せたものは、次に同じ画面を改修するときに必ず戻ってこられる。
直すために言葉にするというより、「見送ったこと」を正確に覚えておくために言葉にする。この練習の一番の実利はここにある、というのが著者の結論。
8. まとめ（記事の要点）
- 見た目の指摘は「なんとなく」で渡されがちで、直せても次の画面に持ち越せない
- 指摘する人と掘る人を分ける。違和感を持った瞬間には、まだ誰も根拠を持っていないから
- 問いは「良し悪し」ではなく「何を伝えようとしているか」という意図から入る
- 根拠はチェックリストではなく「段」：好み → 原則の名前 → 画面内の優先順位 → 他画面との一貫性 → ユーザーの行動
- 根拠の強さの正体は、正しさではなく「どこまで持ち越せるか（射程の長さ）」
- 言語化の目的は説得ではなく再現。「今回は直さない」と決めたことも言葉にして資産にする
「なんか気持ち悪い」という直感はだいたい合っている。合っているのに言葉にできないと、その場限りで消えてしまう。その直感を消さずに、次も使える道具に変えていく——それがこの練習会の目的である。