テスト結果を「直す材料」に変える

改善の第一歩は、テストで起きたことを「直す材料」の形に整理することです。テスト記録には、迷った・つまずいた・手が止まったという場面がいくつも出てきます。それを一つずつ、直すべき課題として書き出します。

ここで大事なのは、全部を一度に直そうとしないことです。時間もかぎられていますし、あれもこれもと手を入れると、かえって画面全体がちぐはぐになります。そこで、書き出した課題を重要度で並べ、影響の大きいものから直していきます。下の表は、リフトのテストで見つかった課題を重要度で並べた例です。

重要度は、困りごとの大きさ（価値や目的にどれだけ響くか）と、起きた頻度（何人に起きたか）の掛け合わせで見ます。予約を最後まで完了できないような課題は、真っ先に直す対象です。逆に、操作には支障が出にくい細かな点は、後回しにしてかまいません。

表面の不満でなく原因を直す

課題が並んだら、次は改善案を考えます。ここでよくあるのが、表面の不満をそのまま直そうとすることです。「ボタンが分かりにくい」と言われたからボタンを赤くする、では、なぜ分かりにくかったのかが置き去りになり、色を変えても迷いが消えないことがあります。

改善案は、課題 → 原因 → 改善案の順で考えます。まず、なぜその課題が起きたのか、原因を見立てます。原因に手を当てれば、同じ理由で起きていた別の問題もまとめて解けることがあります。下の表は、リフトの課題を原因までさかのぼって改善案にした例です。

原因は、テストで被験者が言った言葉やつまずいた場所から見立てます。「これで予約が終わるのか分からない」という声なら、原因はボタンのラベルと見た目にあります。第3章で学んだアフォーダンス（押せると感じさせる見た目）やコントラスト（文字と背景の明るさの差）は、こうした原因を言葉にするときの手がかりになります。

改善をUIに反映する（前と後を見比べる）

原因と改善案が決まったら、UIに反映して改善版を作ります。このとき、改善前と改善後を見比べられる形で残すと、何をどう変えたのかが自分にもコーチにも伝わります。ここでは、テストで迷った2つの画面を例に、改善前（✗）と改善後（◯）を並べます。

変えたのは、ボタンのラベルと色、そして選択中の見せ方だけです。使った深緑 #2F5D50は、第3章のスタイルガイドで決めた予約ボタンの色なので、新しく色を増やしたわけではありません。テストで迷った原因に、ピンポイントで手を当てています。支給ロゴやブランドカラー、スタイルガイドのルールは、改善のときも変えずに守ります。

なぜ直したかを言葉にする（意図シート）

改善版UIができても、それだけでは「なんとなく良くした」ように見えてしまいます。実務で本当に問われるのは、なぜそう直したのかです。その判断の根拠を言葉にしたものが意図シートです。改善版UIとセットで作ります。

意図シートには、課題・原因・どう直したか・根拠の4つを書きます。とくに根拠が大事で、テストで分かった事実、第2章で定義した価値と要件、第3章で学んだUIの原則（アフォーダンス・コントラスト・一貫性など）に結びつけます。下の表は、確定ボタンの改善を意図シートに書いた例です。

根拠まで書けると、コーチやクライアントに「ここは好みで変えたのではなく、こういう理由で直しました」と説明できます。この説明する力は、修了制作のプレゼン（第5章）でそのまま使います。設計判断の根拠を自分の言葉で語れることは、修了評価でも見られるポイントです。

演習：改善版UIと意図シートを仕上げる

ここからは実践です。前回（4-2）のテスト記録を材料に、リフトの予約UIを直して改善版を作り、なぜ直したかを意図シートにまとめます。4つのステップで進めます。

なお、今回のテストはコーチ1名に協力してもらったものですが、実際のプロジェクトでは、可能なら複数人にテストしてもらいます。複数の人に共通して起きたつまずきほど優先度が高い、という見方で、改善の優先順位をつけていきます。

改善版UIと意図シートは、修了評価の「改善」の観点に直結する成果物です。凝った直しを増やすより、テストで分かった課題に的をしぼって直し、その根拠をきちんと言葉にすることを優先してください。ここで身につけた「直して、なぜ直したかを説明する」流れは、リリース後の改善提案（第5章）でもそのまま使います。