デザインレビューで見る項目一覧｜好みの話にしない進め方

「レビューで出た指摘が、直すべき欠陥なのか、部長の好みなのか分からない」「なんとなく違う気がする、としか言えなかった」。——画面やバナーの確認を任された担当者からは、この2つがほぼ同じ形で届きます。前者は指摘を受け取る側、後者は指摘を出す側の困り方ですが、原因は同じところにあります。デザインレビューは、出来上がった画面の良し悪しを多数決で決める場ではありません。本当は、先に決めておいた項目に画面が合っているかどうかを、1つずつ照らし合わせる場です。照らす先がない状態で意見を集めれば、返ってくるのは感想だけになり、最後は役職の順に通ります。この記事では、画面を見るときの項目一覧と、好みの言い方を返せる指摘に書き直す型、そして参加者と決定者の決め方までを、公開されているデザインシステムと国際基準にあたって整理します。

「なんかダサい」が出た時点で、その場は止まっている

よくある場面をそのまま追いかけます。会議室の画面に試作が映り、ひととおり説明が終わったところで最初に出るのが「うーん、なんかダサいですね」。続いて「もう少し洗練された感じにできませんか」。この2つが出た時点で、その会で決められることはほぼなくなります。指摘が指している対象が、画面の中に存在しないからです。作った側は直す場所を特定できず、持ち帰って全体を作り直すことになります。

厄介なのは、この形の指摘に反論できないことです。「ダサい」は感想なので、事実として誤っていると示すことができません。返せるのは「そうでしょうか」という別の感想だけで、そこから先はどちらの感想が強いかの勝負になります。役職の高い人の感想が通るという結論に落ち着くのは、誰かが横暴だからではなく、勝ち負けを判定する物差しがその場に用意されていないからです。

この状態が何回か続くと、作る側は次から決裁者の好みを当てにいくようになります。誰に見せるかで作るものが変わり、画面ごとに違う考え方が混ざり、結果として画面全体の一貫性が落ちます。レビューが品質を上げるどころか、下げる方向に働き始めるわけです。最初に決めるべきなのは良し悪しではなく、何を見て良し悪しを言うのかという項目のほうだ、という結論になります。

見ている段階がずれていると、指摘は噛み合わない

国内のクラウドサービス会社が、自社のデザインシステムを一般に公開しています。そこではプロダクトの使用性を確かめるレビューを、情報設計レビューとUIレビューの2段階に分けています。順番も決められていて、新規開発アプリと大規模開発では、情報設計レビューとその修正が終わった後にUIレビューを実施する、と書かれています。中規模の開発では、担当デザイナーの希望する任意のタイミングでよい、とされています。

この順番には理由があります。情報設計の段階で見るのは、ユーザーの業務、概念モデル、オブジェクトモデル、ビューの呼び出し関係、メインナビゲーションといった、画面の外側にある骨格です。ここが固まる前に配色やボタンの形を議論しても、骨格が変われば作り直しになります。逆に、細部を詰める段になってから「そもそもこの画面は要るのか」と言われれば、それまでの作業が消えます。

どちらの事故も、その回のレビューで何を見るのかが宣言されていないために起きています。会の冒頭で「今日は骨格だけを見ます。色と文字の大きさは次回に見ます」と言い切るだけで、噛み合わない指摘のかなりの部分は出なくなります。宣言があれば、範囲外の指摘は却下ではなく持ち越しになります。指摘した側の面目もつぶれません。

レビューで見る項目を、先に一覧にしておく

項目一覧は、ゼロから自作する必要がありません。先ほどのデザインシステムには、UIデザイン使用性チェックリストとして22項目が公開されています。区分は情報設計、デザインパターン、コンポーネント、ライティング、アクセシビリティの5つです。しかもUIレビューで見るのは6番から18番と、21番、22番だ、と番号で指定されています。何を見るかだけでなく、何を見ないかまで決めてあるのがこの一覧の要点です。

公的機関の例もあります。デジタル庁が公開しているデザインシステムのアクセシビリティのページは、特に注意を払って構築している点として7つを挙げています。色の組み合わせとコントラスト比、フォントサイズ、キーボード操作とフォーカスインジケーター、リンクやボタン等のターゲットサイズ、操作に対応したインタラクション表現、動きのあるオブジェクトの扱い、そして大きさの可変や内容量の増減を踏まえた外観構造です。最後の1つは、試作では気づきにくい観点として後で扱います。

段階	この回で見る項目	この回では言わないこと
骨格を見る回	利用者の業務の流れ、画面同士のつながり、主となる案内の作り、そもそも要る画面かどうか	配色、文字の大きさ、部品の形、細かい文言
見た目を見る回	目が動く順、まとまりと余白、部品の一貫性、状態の見せ方、誤操作からの戻り方、文言	画面の追加や削除、業務の流れそのものの変更
数値で測る回	文字と背景の明暗差、押せる部分の大きさ、拡大したときの崩れ、色だけに頼っていないか	好みに属する印象、語調やトーンの調整

自社で作るときは、この2つを並べて、自社の画面で実際に事故が起きた項目を足すのが早道です。項目は多いほどよいわけではありません。1回のレビューで22項目すべてを見ようとすると、どれも浅くなります。段階ごとに見る項目を割り当て、その回で見ない項目には「次回に見る」と書いておくほうが、1つあたりの指摘は深くなります。

項目1：画面の中で、目がどの順に動くか

チェックリストの6番は視線誘導です。原文では、見出しや色を適切に使用して画面全体の情報の流れと強弱を表現できているか、と書かれています。レビューで確かめるなら、この画面で最初に読ませたいものを1つだけ挙げてくださいと作った本人に聞くのが手早い方法です。2つ以上挙がるなら、その画面の中で優先順位がまだ決まっていません。

見方を手順にすると、こうなります。画面を数秒だけ見せて閉じ、参加者に何が記憶に残ったかを言ってもらう。残ったものと、作った側が意図した最初の1つがずれていれば、それは好みの相違ではなく設計と結果の不一致です。この形なら「見出しが目立ちすぎでは」ではなく、「最初に読ませたいのは金額のはずだが、先に見出しが目に入っている」と言えます。指摘の対象が画面の中にあります。

7番の視覚的グルーピングも同じ形で確かめられます。近くに置かれたものは関係がある、離れているものは関係がない、と読み手は勝手に受け取ります。見た目のまとまりと意味のまとまりが一致していないときだけ指摘すると決めておけば、余白の議論が「もう少し空けたほうが上品」という好みの話に落ちません。9番として余白の取り方が独立した項目になっているのも、ここを感覚で扱わないためです。

項目2：内容が増えても、崩れないか

8番はページレイアウト、10番はモバイルレイアウトの基準です。8番には、機能のトップとなるページに適切なリード文が書かれているか、という確認まで含まれています。レイアウトの項目は、見た目の整い方ではなく、置かれるべきものが置かれているかを見る項目だということです。整っているのに何の画面か分からない、という試作はここで止まります。

デジタル庁の7点の最後にあった、大きさの可変や内容量の増減を踏まえた外観構造が効いてくるのもこの項目です。レビューの場では、いちばん長い名前、いちばん件数が多い状態、1件もない状態の3つを見せてもらうと決めておきます。試作はたいてい都合のよいデータで作られているので、この3つを出した瞬間に崩れが出ます。崩れは好みとは無関係な、再現する欠陥です。

言い方にすると差が分かります。「余白が足りない気がします」ではなく、「会社名が30字を超えると2行になり、右のボタンが画面の外に押し出される。取引先の一覧には30字を超える社名が実在する」。後者は、直すかどうかを判断できます。前者は判断できません。同じことに気づいていても、どんなデータのときに何が起きるかまで言えるかどうかで、指摘の価値は変わります。

項目3：同じ機能が、同じ形で出ているか

ユーザビリティの研究者が1990年に作り1994年に公表した10の原則の4番目が、一貫性と標準です。原文は、利用者が、違う言葉や状況や操作が同じ意味なのかどうかを迷わなくて済むようにすべきだ、と述べています。この10原則は、細かい指針ではなく大まかな経験則として位置づけられており、1994年から内容が変わっていません。解説の最終更新は2020年です。

経験則にとどまらず、達成基準としても書かれています。ウェブアクセシビリティの国際基準2.2版には、同じ機能を持つ部品は一連のページの中で一貫して識別できるようにすることという基準があり、等級はAAです。加えて、複数のページで繰り返される案内の仕組みは、毎回同じ相対的な順序で現れること、という基準も等級AAで置かれています。一貫性は好みではなく、外部の基準に書かれている項目だということです。

チェックリストの17番は、既存の部品と類似した独自の部品になっていないか、を見る項目です。似て非なる部品が増えると、利用者は毎回この操作は何だったかを考え直すことになります。指摘の言い方はこうなります。「このボタンは角が丸くないほうがいい」ではなく、「同じ削除操作が、一覧画面では赤い文字リンク、詳細画面では枠付きボタンになっている。どちらかに寄せたい」。前者は感想で、後者は不整合の報告です。

項目4：いま何が起きているかが、画面に出ているか

10原則の1番目が、システム状態の視認性です。原文は、設計は常に利用者に何が起きているかを知らせるべきで、それは適切な時間内の適切なフィードバックによる、と述べています。チェックリストの11番も、利用者への通知とフィードバックの出し方が基準に沿っているか、を独立した項目にしています。状態の見せ方は、画面の飾りではなく機能の一部という扱いです。

レビューで見るのは、処理中、成功、失敗の3つの状態がそろっているかです。試作は成功した後の画面しか作られていないことが多く、通信が遅いときに何も起きていないように見える画面や、失敗したのに元の画面に戻るだけの画面が、そのまま実装まで進みます。成功以外の状態を見せてくださいと言うだけで、この項目の指摘はほぼ出そろいます。

12番は、モードがあるUIの場合にモーダルなUIの基準に沿っているか、という項目です。編集中と閲覧中のように状態が切り替わる画面では、いま自分がどちらにいるのかが画面から読み取れる必要があります。デジタル庁の7点にも、操作に対応したインタラクション表現が挙がっていました。押したのに何も変わらない、という体験は、押せていないのか処理中なのかが区別できないところから生まれます。

項目5：間違えたときに、戻れるか

10原則の3番目は、利用者の主導権と自由です。原文は、利用者はしばしば操作を誤るので、望まない操作から長い手順を踏まずに抜けられる、はっきり示された非常口が必要だ、と述べています。5番目の誤操作の防止では、よいエラーメッセージは重要だが、最良の設計はそもそも問題が起きないようにする、と書かれています。順序として、防止が先で、通知が後です。

チェックリストではこの2つが具体化されています。15番は、エラー状態が検討されており、エラーを回復・解消できるフィードバックの出し方が考慮されているか。16番は、削除を含む危険な操作、やり直しができない操作の前にワンクッションをはさんでいるか。レビューでは、この画面で取り返しがつかなくなる操作を全部挙げてくださいと聞き、挙がった操作それぞれに確認の一手間があるかを見ます。

エラー文そのものも項目です。10原則の9番目は、エラーメッセージは平易な言葉で表現し、問題を正確に示し、建設的に解決策を提案すべきだ、と述べています。チェックリストの21番も、エラーメッセージの基準に沿っているかを独立させています。実務では、画面に出る可能性のあるエラー文を全部書き出し、次に何をすればよいかが書かれていないものに印を付けるだけで、直す対象が具体的に決まります。

項目6：読める大きさ・押せる大きさになっているか

ここは、議論せずに数値で決まる項目です。ウェブアクセシビリティの国際基準2.2版は、文字と文字の画像について、コントラスト比が少なくとも4.5対1であることを等級AAの達成基準としています。文字以外の視覚的な表現、たとえばボタンの枠や状態を示す色については、隣接する色に対して少なくとも3対1という別の基準が同じ等級で置かれています。

大きさと拡大にも基準があります。押したり触れたりする対象の大きさは、少なくとも24かける24の指定画素であること。文字は、支援技術を使わずに200パーセントまで拡大しても内容や機能が失われないこと。行の高さを文字の大きさの1.5倍にしても内容や機能が失われないこと。いずれも等級AAです。加えて等級Aとして、色だけを情報伝達の唯一の視覚的手段にしないこと、という基準があります。

• 数値の項目は、レビューの場で目視で争わない。事前に測って、外れているものだけを一覧にして持ち込む
• 測れる項目は、指摘ではなく修正依頼として扱う。合っているか外れているかしかないので、合意を取る必要がない
• 基準に外れていない範囲での見やすさの調整は、この項目ではなく提案として別枠に置く
• 自社に決まりがある場合は、外部の基準と自社の決まりのどちらを優先するかを先に決めておく

この項目を先に片づけておくと、レビューの時間の使い方が変わります。数値で決まることに時間を使わなくなるので、優先順位や言葉遣いのような、人が決めるしかない項目に議論を寄せられます。逆にここを後回しにすると、公開直前になって色を変える羽目になり、変えた色が他の画面と合わなくなります。

項目7：画面の言葉が、読み手のものになっているか

10原則の2番目は、システムと実世界の一致です。原文は、設計は利用者の言葉で話すべきであり、社内の符丁ではなく利用者になじみのある言葉、言い回し、概念を使うべきだ、と述べています。画面の文言はデザインの一部であって、後から別の担当が差し替えるものではありません。文言だけ後で長いものに置き換えると、ボタンの幅が合わなくなります。

チェックリストのライティングの区分も同じ考え方です。19番は基本的な概念や用語に合わせた命名をしているか、20番は操作の導線やアクション名が基準に沿っているか、という項目になっています。実務での見方は単純で、画面のボタン名と見出しだけを抜き出して一覧にする。同じ操作に登録、追加、作成という3つの呼び名が付いていたら、それは好みの相違ではなく用語の不統一です。

この一覧は、後の工程でも効きます。問い合わせが来たときに、担当者と利用者が同じ言葉で画面を指せるかどうかが変わるからです。画面の中で3通りに呼ばれている操作は、問い合わせの窓口でも3通りに呼ばれます。用語をそろえる作業は、見た目を整える作業に見えて、実際には運用の負荷を先に減らす作業になっています。

好みの指摘を、返せる指摘に書き直す

指摘の出し方そのものにも決まりを置けます。先ほどのデザインシステムのUIレビューには、フィードバックの出し方のルールが2つ書かれています。1つは、チェックリストに紐づいている場合はチェックリストの番号を添えること。もう1つは、コメントだけを見ても指摘の対象や内容がある程度分かるように書くことです。この2つを守るだけで、指摘は好みから離れます。番号を添えられない指摘は、根拠が一覧の外にあるということだからです。

• 「なんかダサい」——対象がない。画面のどこを指しているのかが分からず、直す場所を特定できない
• 「もう少し洗練された感じに」——比較の相手がない。何と比べて足りないのかが書かれていない
• 「ここは青のほうがいい」——理由が省かれている。基準に外れているのか、提案なのかが区別できない
• 「全体的にバランスが悪い」——範囲が広すぎる。全部を作り直す以外に応じようがない
• 「前の案のほうがよかった」——比較の軸がない。どの項目で前の案が上回っていたのかが分からない

よくある言い方	書き直した言い方	根拠にした項目
文字が読みにくい	灰色の補足文と白い背景の明暗差が基準の4.5対1に届いていない。実測で3.1対1	文字のコントラスト比・等級AA
ボタンが押しにくい	一覧の削除アイコンが18の指定画素角で、基準の24を下回っている	押す対象の大きさ・等級AA
統一感がない	同じ削除操作が一覧では文字リンク、詳細では枠付きボタンになっている	同じ機能の部品の一貫した識別・等級AA
情報が多すぎる	この画面で最初に読ませたいものが3つあり、優先順位が決まっていない	視線誘導・チェックリスト6番
エラーが不親切	在庫切れの表示に、次に何をすればよいかが書かれていない	エラーからの回復・チェックリスト21番

書き直しの型は4つです。どこが、何と比べて、どうなっている、だから何が起きる。4つ目まで埋まると、直すかどうかを相手が判断できます。慣れないうちは、指摘を書いたあとに4つが埋まっているかを自分で数えるだけで十分です。埋まらない指摘は、次の項目で扱う「好み」の枠に置きます。

それでも残る好みを、置く場所を決める

項目一覧を作っても、好みは消えません。消す必要もありません。ブランドの印象や語調、写真の選び方には、項目に落としきれない部分が必ず残ります。10原則の8番目も、画面には無関係な情報や滅多に使わない情報を含めるべきではない、という大まかな経験則にとどまっています。問題は好みがあること自体ではなく、好みと欠陥が同じ顔をして一列に並ぶことです。

手当てはひとつで、置き場所を分けることです。コメントの頭に必須、提案、好みの3語のどれかを付けます。必須は項目に反しているもの、提案は項目には反していないが良くなると考える案、好みは個人の感想です。好みと書かれた指摘に、直す義務は発生しないと最初に決めておきます。分類は指摘した本人が付け、後から他の参加者が変えないことにします。

この分け方は、決裁者の一言にも効きます。「私は好みで言っています」と自分で宣言できる形になっていると、周囲が忖度して直してしまう事故が減ります。逆に、必須と書いたなら、どの項目に反しているのかを聞かれることになります。言葉を1つ添えるだけで、発言に責任の重みが付く仕組みです。会の終わりに、必須が何件、提案が何件、好みが何件と数えておくと、次の回の運び方も決めやすくなります。

誰が出して、誰が決めるか

参加者の決め方にも、公開されている実例があります。先ほどのデザインシステムのUIレビューでは、担当デザイナーに対して、レビュアーはプロダクトデザイナー1名とアクセシビリティ1名と決められています。さらに、レビュアーはランダムでアサインされる、と明記されています。仲のよい人や詳しい人に固定しない、という運用です。

固定しないことには効き目があります。同じ人が見続けると、その人の癖が基準になっていきます。ランダムに割り当てれば、指摘は項目一覧に寄らざるを得ません。人数を絞っているのも重要で、参加者が増えるほど1件あたりの指摘は浅くなり、好みの比率が上がります。全員に見せたいなら、レビューではなく共有の場を別に設けるほうが早いという判断です。

ゴールの置き方も参考になります。同じ規定では、レビュアーからの指摘が得られていること、そして指摘に対して一往復のやり取りがされていることが望ましい、とされています。合意に達することをゴールにしていない点が要点です。一往復して、なお意見が分かれた場合に備えて、採否を決める人を1人だけ決めておきます。指摘を出す役と、採否を決める役を同じ人が兼ねると、レビューは指示に変わります。

レビューを回す5工程

ここまでの項目を、実際に回す順番に並べます。1回きりの会ではなく、次の画面にも使える形にするのが狙いです。工程ごとに、誰が何を持って出るかまで決めておくと、参加者が入れ替わっても同じ密度で回ります。

この5工程で飛ばされやすいのは2番目と5番目です。自己点検を飛ばすと、レビューの時間が誤字と数値の指摘で埋まります。書き戻しを飛ばすと、毎回同じ指摘を別の人が出し続けることになり、レビューが学習しません。2番目は依頼する側の仕事、5番目は決める人の仕事と、担当まで決めておくのが確実です。

• 今日の回で見る項目と、見ない項目を先に読み上げたか
• 測れる項目は事前に測り、外れているものだけを一覧にして持ち込んだか
• すべての指摘に、対象と、必須・提案・好みの分類が付いているか
• 直さないと決めた指摘に、理由が1行書かれているか
• 3回以上出た指摘を、自社の項目一覧に足したか

生成AIに渡してよい点検と、渡してはいけない判断

項目のうち、機械的に測れるものは先に潰せます。文字と背景の明暗差の計算、押す対象の大きさの計測、画面内で使われている操作名の抜き出しと突き合わせ、エラー文の書式の統一、決めた部品から外れている箇所の洗い出し。これらは人が目で数えるより速く、しかも見落としません。デザインの画面を渡して、この観点で気づいた点を挙げてくださいと頼む使い方もできます。

• 画面の中の文字と背景の色を抜き出させ、明暗差を計算して基準に届かない組み合わせだけを一覧にする
• ボタンやリンクの名前を全部抜き出させ、同じ操作に別の呼び名が使われている箇所を挙げさせる
• エラー文をすべて集めさせ、次にすべきことが書かれていないものに印を付けさせる
• 長い名前や大量の件数など、極端なデータを入れた文面案を作らせ、崩れる箇所を人が確かめる
• 自社の項目一覧を渡し、この画面はどの番号に触れる可能性があるかだけを列挙させる

ただし、任せられる範囲には外部から示された線があります。ウェブの標準を定める国際団体は、評価ツールの選び方を説明した文書の中で、ツールはアクセシビリティのすべての側面を自動で確認できるわけではなく、人の判断が必要であると書いています。同じ文書には、ウェブアクセシビリティの評価ツールはアクセシビリティを判定することはできず、判定を助けることしかできない、とも明記されています。さらに、評価ツールは誤った、あるいは誤解を招く結果を出すことがある、とも書かれています。

• この画面は良いか悪いかをAIに判定させる——判定の根拠が示せず、人の好みを機械の権威に置き換えるだけになる
• 検査を通ったからアクセシビリティに問題なしとする——ツールは判定できず助けるだけだと標準化団体自身が書いている
• AIが挙げた指摘をそのまま修正依頼にする——誤った結果や誤解を招く結果が混じるため、対象と根拠を人が確かめる必要がある
• 優先順位の決定や、この情報を載せない決定を任せる——業務の事情と法令の判断は画面の外にあり、AIには渡っていない

運用に落とすなら3つです。第一に、AIの出力には必ず根拠にした項目の番号を書かせる。番号が書けない指摘は、根拠が一覧の外にあるので採用しません。第二に、判定させずに候補を出させる。良し悪しではなく、触れる可能性のある項目を挙げさせるところまでにします。第三に、人が必ず見る範囲を先に決めておく。押すと取り返しがつかなくなる操作、金額と個人情報が出る画面、外部に公開する画面の3つは、機械の結果にかかわらず人が見る、と決めておくのが現実的です。

まとめ

デザインレビューが好みの言い合いになるのは、参加者の感性が違うからではありません。指摘が画面の中の対象を指していないからです。「なんかダサい」には対象がなく、比較の相手もなく、だから何が起きるのかも書かれていません。返せるのは別の感想だけになり、最後は役職の順に通ります。照らす先を先に決めておくことが、レビューを判断できる場に変える唯一の手当てです。

見る項目は自作しなくてかまいません。公開されているデザインシステムのチェックリストは22項目で、そのうちUIレビューで見るのは6番から18番と21番、22番だと番号で指定されています。公的機関のデザインシステムも、色の組み合わせとコントラスト比、フォントサイズ、キーボード操作とフォーカスインジケーター、押す対象の大きさ、操作に対応した表現、動くものの扱い、内容量が増減したときの構造の7点を挙げています。この2つを並べ、自社で実際に事故が起きた項目を足せば一覧になります。

数値で決まる項目は、議論の対象から外します。文字のコントラスト比は少なくとも4.5対1、文字以外の視覚的な表現は隣接色に対して少なくとも3対1、押す対象は少なくとも24かける24の指定画素、文字は200パーセントまで拡大しても内容と機能が失われないこと。いずれも国際基準の等級AAです。ここに時間を使わない分だけ、優先順位や言葉遣いのような、人が決めるしかない項目に議論を寄せられます。

進め方は、段階と項目を宣言し、依頼側が自己点検し、対象を特定して指摘を書き、一往復して1人が採否を決め、決まったことを一覧に書き戻す、の5工程です。指摘には必須、提案、好みの3語のいずれかを付け、好みには直す義務を発生させません。AIには測れる点検を渡し、根拠の番号を書かせ、判定はさせない。人が必ず見る範囲を先に決めておく。レビューが返してくれるのは、きれいな画面ではなく、まだ決まっていない項目の一覧です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。