背景
新規システム開発初期に開発に先行して画面イメージをユーザに共有して、開発の合意とフィードバックを得る。 開発の初期段階のため、主に手書きもしくはProttなどのツールで書いたワイヤーフレームや、パワーポイント、Sketchなどで書いた画面イメージを ユーザに見せてレビュー、フィードバックもらう状況。
アンチパターン
ワイヤーレベルの画面を見せたときのユーザの「だいたいOK」を真に受ける。
解説
手書きワイヤーやパワポ資料をみせると、大抵の場合イイネとか、いい感じなんじゃない、と言ってくれます。 システムに開発、検討に従事していない人のほとんどは紙芝居やパラパラワイヤーフレームにそこまで自分の業務を当てはめて想像してくれません。 もちろん本人は想像力を働かせてくれてはいるでしょうが、その想像力にはかなり限定的です。 残りの想像できない部分に関しては、ワイヤーフレームを元に一生懸命説明してくれている開発者がよろしくやってくれるんだろうと思ってくれます。
そのユーザのOKをもとに一気に開発を進めて、実際にユーザが１つの操作フローを実施できるようなレベルのものを提供した途端、 一気にリアルなフィードバックが飛んできます。もしくは「なんか違うんだよね」という曖昧なコメントが来ます。
これにより開発の方向性が大きく変わったりスコープ修正を余儀なくされ、想定した開発スケジュールどおりローンチできなくなります。
解決策
開発初期のユーザレビューにおける、ユーザの「だいたいOK」を信じないでください。 このタイミングは開発内容の合意を取ると言うより、ユーザが何を気にしているのかを意見交換に重点をおいてください。 だいたいOK、という意見よりネガティブは意見の引き出しに注力してください。
初期のワイヤーによるユーザレビューに意味がないわけではなく、重要な意見交換の場です。 ユーザに対して何かしらイイものを準備していると期待してもらい、今後ともレビューを経ていいシステムを作り上げていくという協力関係を築いてください。
そしてあまり開けずに次のレベルのプロトタイプ(ワイヤーの次はフロントエンドだけで閉じるモックシステムなど)を見せて再度ユーザの レビューを受けてください。システムの開発レベルが上がるに連れ、ユーザは自分はこのシステムをどう使えるか、何に困るかということを具体的にイメージしてくれます。
理想的なのは、ユーザが業務フローの開始から終了までとりあえず動かせるレベルのものを提供することです。
重要なのは十分に現実的なフィードバックを得るために適切なレビューポイントはどこか考え、反復することです。
アンチパターンとならない場合
ユーザがシステムに関する理解が深く、ワイヤーレベルの画面の裏側まで詳細にイメージして質問してくれるような人であれば、ワイヤーレベルの画面でも重要なフィードバックを受けたり、合意を取ることは可能です。しかし、一般にレビューをうけるユーザ(顧客)にそこまでのレベルを期待するのは適切ではありません。 また、新規システムと言えど既存のロジックの流用を行ってたりし、ワイヤーで表現できない見えない部分に関する認識を改めて取る必要が無い場合であれば、 一気に開発を進めて問題ない場合もあります。
