コードの向こうに利用者がいる：問い合わせから改善点を見つける | 仕組み解説

開発中は、画面を機能の集合として見ます。利用者は機能を使いたいのではなく、申込み、検索、提出など自分の目的を達成するために画面を使います。

問い合わせには、コードだけを見ていては分からない利用者の前提が含まれています。

問い合わせを4層で読む

「ボタンが押せない」という報告でも、ボタンの不具合とは限りません。入力条件が伝わらない、処理中だと分からない、エラーが画面外に出ている可能性があります。

利用者が「登録」「保存」「提出」をどう呼ぶかは、画面の文言を見直す材料になります。開発者だけに通じる用語をそのまま表示していると、操作を迷わせます。

ただし、一件の声をそのまま全員の要望と考えてはいけません。次の情報と組み合わせます。

問い合わせ対応後に、次を記録します。

利用者の目的:
つまずいた場所:
画面から読み取れなかった情報:
一時的な案内:
プロダクト側で直せること:

案内文を増やすだけでなく、入力制約を見直す、エラーを近くに表示する、処理状態を見せるなど、問い合わせ自体を減らす改善を考えます。

成果物のREADMEでは、使用技術だけでなく「誰のどんな困りごとを解決するか」「利用者の声から何を直したか」を説明すると、設計判断が伝わります。