ニーズステートメント

調査で得た声を機能名だけへ変換すると、別の解決策を検討しにくくなります。
ニーズステートメントは、誰が、どの状況で、何を達成するために何を必要とするかを表す文です。
Nielsen Norman Groupの記述方法も、利用者、必要なこと、その目的を結びつけています。
短い定型文を作ることより、調査結果から設計へ渡す問いを明確にします。

要望と目的を分けて書く

たとえば、工場の担当者が「作業一覧を印刷したい」と要望したとします。
直近の仕事を聞くと、端末を置けない場所でも、次の作業と確認項目を見たいとわかったとします。
「現場で作業する担当者は、端末を参照できない場面でも、次の作業と確認事項を知りたい」と書けます。
印刷は、そのニーズを満たす候補の一つとして別に残します。

ただし、紙で保管することが顧客との契約条件なら、それは消してはいけません。
目的と、守る必要がある制約を分けて記録します。
解決策へ依存しない表現を目指しても、現場の具体的な条件まで抽象化しないようにします。
「情報を把握したい」だけでは、設計の判断へ使えません。

原文の根拠をたどる

記述には、元の発言や観察、対象者の条件を結びつけます。
複数の人の話を統合する場合は、共通する目的と異なる制約を示します。
一人の強い要望を、全顧客のニーズとして一般化しないようにします。
調査者が推測した部分は、確認済みの内容と区別します。

作業一覧の例なら、担当者へその文を示し、どの場面で当てはまるかを聞けます。
賛成を求めるだけでなく、当てはまらない仕事と、別の方法で足りている条件も調べます。
文を自然にしたことは、仮説が正しい証拠にはなりません。

試作の評価へつなげる

ニーズが明確になれば、紙、携帯端末、音声など、異なる手段を比べられます。
試作では、次の作業を正しく選べるか、確認事項を見落とさないかを確かめます。
案の好みだけを聞くより、達成したい結果へ評価を結びつけられます。

優先順位には、問題の頻度、放置した影響、現在の対処、対象者の範囲を加えます。
きれいな文になったニーズから順に開発するわけではありません。
提供費用と事業の方針も含めて選びます。

意味の整理は顧客ニーズ、元の声の管理は顧客の声、提供する便益の設計は価値提案を参照してください。

参考資料