5秒で「使い手」が伝わるUIを作る——ユーザー属性を可視化してデザイン判断を言語化する実践手順

デザインレビューで「これは誰向けのUIですか？」と聞かれ、言葉に詰まった経験はないか。この記事では、ユーザー属性を4項目で定義し、それをUIの設計根拠として言語化し、5秒テストで検証するまでの一連の手順を具体的に解説する。レビューや合意形成の場で「なぜこのデザインか」を説明できるデザイナーになるための実践ガイドだ。

なぜデザインレビューで「誰向け？」に答えられないのか——属性定義が後回しになる構造的な理由

デザインレビューの場でこんな場面を見たことはないか。デザイナーが丁寧に作り込んだ画面を見せると、レビュアーから「これって誰向けのUIですか？」という質問が飛ぶ。デザイナーは「一般的なユーザーを想定していて……」と口を濁す。するとレビュアーは「ITに詳しくない人でも使えますか？」「高齢者はどうなんですか？」と畳みかける。デザイナーは返す言葉を失う。

この場面の根本にあるのは、「誰が使うか」の定義がデザイン作業の後回しになりやすい構造的な問題だ。

プロジェクトが始まると、チームはまず画面設計に取り掛かる。ワイヤーフレームを起こし、コンポーネントを組み、視覚的な完成度を上げていく。ユーザー属性の定義は「後でペルソナを作れば整理できる」と先送りにされ、気づけばモックが完成したタイミングで誰も定義していない、という状態になる。

もうひとつの構造的な問題は、「なんとなくわかっている」という錯覚だ。チームの中に「うちのユーザーは30代のビジネスパーソンだよね」という共通認識があると、それを明文化する必要性を感じにくい。しかし「30代のビジネスパーソン」は何も言っていないに等しい。スマートフォンで使うのか、業務用PCで使うのか。SaaS慣れしているのか、Excelしか使ったことがないのか。この差でUIの設計判断は根本から変わる。

ペルソナは「言語化しにくいユーザー像を可視化するツール」とされており（Nielsen Norman Groupの定義による）、UIデザインにおける意思決定の共通言語として機能する。問題は、ペルソナが形式的なドキュメントとして作られ、設計判断に接続されていないことにある。「作ったが使っていない」では、ないのと同じだ。

この記事が提案するのは、ペルソナを丁寧に作ることではない。4項目の属性定義をUIの判断基準に変換し、5秒テストで属性別に検証するまでの、実務で回せる最小の手順だ。

ユーザー属性を4項目で定義する——職種・年齢・デバイス・ITリテラシーの整理手順

属性を定義するとき、「詳しいほど良い」という思い込みが作業を止める。50項目あるペルソナシートは埋めるのに1週間かかるが、設計判断に使えるのはそのうち数項目だ。ここでは実務で機能する4項目に絞る。

項目1：職種（または役割）

ユーザーが何の仕事をしているか、あるいはこのツールをどんな立場で使うか。重要なのは職種名ではなく「そのユーザーが日常的にどんな画面と接しているか」だ。

たとえば「経理担当」と「フロントエンジニア」では、数値入力フォームへの慣れが全く異なる。経理担当はExcelのセル操作に慣れており、Tabキーでフィールドを移動することを期待する。エンジニアは新しいUIパターンへの抵抗が低く、キーボードショートカットを好む傾向がある。同じフォームUIでも、設計判断が変わる。

項目2：年齢層（幅で定義する）

特定の数値ではなく「20代前半〜30代前半」のように幅で持つ。年齢が重要なのは、視覚的な可読性（文字サイズ・コントラスト）と、デジタルサービスへの慣れの双方に影響するからだ。40代後半以降のユーザーが主対象なら、12pxのラベルテキストは設計上のリスクになる。

ただし年齢はあくまで「仮説のヒント」だ。最終的な設計根拠は「この年齢層は〜する傾向がある」という事実ではなく、後述するテストの結果が担う。

項目3：主要デバイス

スマートフォン、タブレット、デスクトップPCのいずれかを「主要」として決める。「両方使う」は答えではなく、設計の優先順位を決めていない状態だ。

NN/Gの調査によれば、ペルソナにはユーザーが製品とどのように相互作用するかのコンテキスト——使用頻度、主要デバイス、選択的使用か必須使用か——を含めることが推奨されている。主要デバイスが変わると、タップ領域のサイズ、ナビゲーション構造、スクロールの想定量がすべて変わる。

項目4：ITリテラシー（3段階で定義する）

「低・中・高」の3段階で明示する。「低」はデジタルサービスをほとんど使ったことがない、「中」はスマートフォンアプリの操作に慣れている、「高」はSaaSや開発ツールを日常的に使うレベルだ。

リテラシーが設計に最も影響するのは、エラー処理とオンボーディングの設計だ。リテラシーが低いユーザーは、エラーメッセージの「400 Bad Request」を理解できない。「入力内容に問題があります。電話番号の欄をご確認ください」という日本語で書かれた誘導が必要になる。一方、リテラシーが高いユーザーに対して過剰な説明テキストを表示すると、ノイズとして認識される。

この4項目をA4用紙1枚に書いたものが「属性定義シート」だ。仰々しいペルソナドキュメントではなく、チーム全員がスプリント中にいつでも参照できる付箋サイズの合意事項として運用する。

属性定義をUIの判断基準に変換する——「この属性だからこの設計」を言語化する方法

属性を定義しても、それをUIの設計判断に接続しなければ意味がない。ここが最もスキップされやすいステップだ。

変換の基本は「もし〜なら〜にする」という形式で言語化することだ。属性ごとに設計上の選択を紐づける。

たとえば、こう書く。

• 「主要デバイスがスマートフォン、ITリテラシーが中程度であるため、タップ領域は最小44px×44pxを確保し、アイコンには必ずテキストラベルを添付する」
• 「ユーザーは40代後半の現場担当者であるため、主要な操作ボタンは画面下部に配置し、フォントサイズの最小値を14pxとする」
• 「職種はカスタマーサポートであり、1日に数十回この画面を操作するため、よく使うアクションへのショートカットをホーム画面に露出させる」

この形式で言語化することの利点は、レビューの場で「なぜそうしたのか」を即座に答えられることだ。「なんとなく見やすそうだから」ではなく「主要ユーザーのデバイスと操作頻度を根拠にしている」と言える。これが設計根拠の言語化だ。

もう一つの実践的な手法は「属性変換マトリクス」だ。4つの属性（職種・年齢・デバイス・リテラシー）を横軸に取り、設計の主要判断（ナビゲーション構造・フォントサイズ・エラー表現・オンボーディング有無・ショートカット露出）を縦軸に取る。各セルに「〇:推奨」「△:条件次第」「×:避ける」を記入すると、属性と設計判断の対応が一覧で確認できる。

たとえばマトリクスはこのような構造になる。

このマトリクスを一度作ると、新しい画面を設計するたびに参照できる。毎回ゼロから考え直す手間が省け、チーム内でも「このマトリクスのどこに該当するか」という共通言語で会話できるようになる。

要件定義の文脈では、モックは「認識差分の検出装置」として機能すると言われる。同様に、属性変換マトリクスは「設計判断の認識差分を防ぐ事前装置」として機能する。チームメンバー間で「ITリテラシーが中程度のユーザー向けならアイコンだけでいいよね」という誤った合意が生まれるのを、マトリクスが防ぐ。

5秒テストをユーザー属性別に実施する——評価者を変えると見えてくるもの

5秒テストとは、デザインを5秒間だけ見せた後に「何が印象に残りましたか？」「このUIは何をするためのものだと思いましたか？」と質問する評価手法だ。ユーザビリティ調査の分野で広く用いられており、デザインが「最初の5秒」で何を伝えられているかを測定する。参加者は5〜10名が一般的な目安とされ、主要なパターンや問題を特定するには十分だとされている（Lyssna社のガイドラインによる）。

ここで提案したいのは「属性別に評価者を変えて同じデザインをテストする」ことだ。

通常の5秒テストは「想定ユーザーに見せる」で終わる。しかし属性定義が手元にあれば、意図的に属性を変えたテストができる。

たとえば、社内の業務管理ツールをリデザインしているとしよう。定義した主要ユーザーは「40代、現場担当者、スマートフォン主体、ITリテラシー中」だ。

このとき、同じ画面を以下の2グループで5秒テストする。

• グループA：定義した属性に合致する社内の現場スタッフ3名
• グループB：定義した属性とは異なる、デジタル慣れした30代の社内メンバー3名

両グループに同じ画面を5秒見せ、「このUIで何ができると思いましたか？」「最初に目が行ったのはどこですか？」と聞く。

ここで面白いことが起きる。グループBのメンバーは「あ、左上の検索ボタンで絞り込みできますね」と即座に答える。ところがグループAのメンバーは「右下に何か書いてあったけどよく読めなかった」「一番大事なボタンがどこかわからなかった」と答えることがある。

この差分こそが設計の問題を示している。デジタル慣れしたメンバーには「見えている」情報が、実際のユーザーには「5秒では届かない」のだ。

属性変換マトリクスで「ITリテラシーが中程度のユーザーには主要アクションボタンを目立たせる」と設計判断していたにもかかわらず、テストで「ボタンの場所がわからなかった」という回答が出るなら、その設計判断が実装に反映されていないことを意味する。

この「属性定義→設計判断の言語化→属性別5秒テスト」という流れを1サイクル回すことで、設計根拠と実際の評価結果が接続される。デザインレビューの場では、この結果をそのまま根拠として使える。「ITリテラシーが中程度のユーザーを対象にした5秒テストで、主要ボタンの視認率が低かったため、このリビジョンではボタンを画面中央に移動し、ラベルテキストを拡大しました」という説明ができる。

属性定義からモック評価まで——1スプリントで回す最小プロセス

「理屈はわかった、でも実務では時間がない」。この声に応えるため、1スプリント（2週間を想定）で回せる最小プロセスを具体的に示す。

スプリント開始時（1〜2時間）：属性定義シートの作成

チームで30分のワークショップを実施する。ホワイトボードか付箋を使い、前述の4項目（職種・年齢・デバイス・ITリテラシー）をチームで議論しながら埋める。「多数決で決める必要はない。今スプリントで検証する仮説として合意する」という認識で進める。

完成した属性定義シートはFigmaのコメント欄かNotionのページに貼り付け、全員がアクセスできる状態にする。

設計フェーズ（スプリント中）：属性変換マトリクスの参照

新しい画面を設計するたびに、属性変換マトリクスを参照して「この設計判断は属性と整合しているか」を確認する。このチェックは1画面あたり5分程度でできる。「アイコンだけのボタンにしようとしていたが、ITリテラシー中のユーザーには向かないのでテキストラベルを追加した」という判断の記録をFigmaのコメントとして残す。

この記録がレビューの根拠になる。

スプリント終盤（2〜3時間）：属性別5秒テスト

主要な画面（2〜3画面）について、属性に合致する評価者3〜5名で5秒テストを実施する。社内にユーザー属性に近いメンバーがいれば活用し、いなければリモートテストツール（Maze、Lyssna等）を使ってターゲット属性を指定したテストパネルを活用する。

テスト後は回答を一覧表にまとめ、「属性定義との差分があった点」を整理する。この整理は30分程度でできる。

スプリントレビュー：根拠としての提示

スプリントレビューの場では、属性定義シート・設計判断の記録・5秒テスト結果の3点セットを提示する。「誰向け？」という問いに対して「4項目で定義した属性、その属性に合致した評価者へのテスト結果、それに基づく修正」という流れで答えられる。

このプロセスの核心は、要件定義における「モックを認識差分の検出装置として使う」という考え方と同じだ。文字だけの属性定義では、チームメンバーごとに解釈がズレる。5秒テストという具体的な評価結果があることで、抽象的な議論が具体的な改善に落ちる。

1スプリントでの作業量の目安は以下の通りだ。

初回スプリントは属性変換マトリクスの作成に時間がかかるが、2回目以降はマトリクスを参照するだけになる。累積すると、1スプリントあたりの追加工数は設計工程全体の10〜15%程度に収まるはずだ。

まとめ：属性定義はデザインの「制約」ではなく「選択の根拠」

「誰向けか」を定義することを、デザイナーは「自由を制約される」と感じることがある。特定のユーザーに絞ると、その他のユーザーに使われなくなるのではないか、という不安だ。

しかしこれは逆だ。属性定義は選択の根拠を作ることだ。

「ITリテラシーが低いユーザー向けに詳しいオンボーディングを設計した」という判断には、明確な根拠がある。その結果として「リテラシーが高いユーザーにはオンボーディングをスキップさせるオプションを用意する」という次の判断が生まれる。属性定義があるからこそ、例外への対応も設計できる。

属性定義がない状態の「誰にでも使えるUI」は、往々にして「誰にとっても最適でないUI」になる。ダッシュボードの設計で言うところの「全員のニーズを一画面で満たそうとすること」と同じ失敗構造だ。役割が違えばUIは別にする、というのと同じ思想で、属性が違えば設計判断は変わる。

この記事で提案した手順を一度通してみると、デザインレビューでの会話が変わる。「なぜこのボタンをここに置いたんですか？」という問いに、「定義したユーザーの主要デバイスがスマートフォンで、ITリテラシーが中程度のため、主要アクションは親指の届きやすい画面下部に配置しました。5秒テストでもこの位置で視認率が上がったことを確認しています」と即答できる。

それは「レビューで詰められない」ことではなく、「設計に根拠がある」ということだ。デザインの判断を言語化できるデザイナーは、チームの信頼を得やすく、合意形成のスピードも上がる。属性定義はデザインの制約ではなく、チームが同じ方向を向くための地図だ。

参考文献

1. Nielsen Norman Group, “Personas Make Users Memorable for Members of the Design Team”, https://www.nngroup.com/articles/persona/
2. Nielsen Norman Group, “3 Persona Types: Lightweight, Qualitative, and Statistical”, https://www.nngroup.com/articles/persona-types/
3. Lyssna, “Five second testing guide: Definition & key considerations”, https://www.lyssna.com/guides/five-second-testing/
4. Maze, “Five-Second Testing: Step-by-Step Guide + Example”, https://maze.co/collections/user-research/five-second-test/
5. Smashing Magazine, “Five-Second Testing: Taking A Closer Look At First Impressions (Case Study)”, https://www.smashingmagazine.com/2023/12/five-second-testing-case-study/
6. DSCL Blog, “UI設計におけるペルソナ活用法”, https://dscl.jp/blog/persona-UI/