「要件を決めた時に想像していた仕様と違う」
開発チームのほとんどが、プロジェクトの中でも最悪のタイミングで、このような発言を聞くはめになります。大抵、このようなことが起きると、開発者は自分を正当化しようと怒り出します。正確に要件を定義していなかったとステークホルダーを叱責するのです。
これはもっともな怒りではあります。しかし、同時にこの状況の責任は私たち開発側にもあることも事実です。
私たちは認識のズレを埋めるため、要件に必要なことをステークホルダーに伝えてきれていません。この記事では、開発の現場で起きがちなことについて話していきます。
要件をまとめることの背景にある厳しい事実
要件が決められるのは、大抵ステークホルダーとのミーティングのときです。ステークホルダーは自分たちが欲しいものについて話し、デザインとエンジニアのチームがそれらの項目を把握します。ミーティングでは、実際のユーザーリサーチを引用するのではなく、個人的な意見や集団圧力、競合の機能に対するワンパターンなリアクションなどが中心になってしまうことがあります。私にとってこれは、1,200万人の見知らぬ誰かからファストフードの注文を受けるのと同じようなものです。
このような事態を防ぐ、唯一の方法があります。とても単純な方法なので、多くの企業で採用されていないことに驚きを隠せません。それは、できる限り早く単純なプロトタイプを作成し、ステークホルダーと繰り返し要件をまとることです。
今では、デザインプラットフォームによって、誰でも１時間か２時間あれば、簡単に忠実度の低いプロトタイプを作成して、フィードバックを得ることができるようになりました。さらに、それらすべてをHTMLに書き出すのは、数回のクリックによってもっと簡単にできます。HTMLに書き出せば、ステークホルダーも、プロトタイプを完成品のようにクリックして操作できるようになります。
私はこれまで、１～２週間以上もかかるスプリントをやめて、ステークホルダーを交えて、反復とディスカッションを同時に行う２時間のレビューセッションに移行した事例を何度も見てきました。
１つ注釈をつけると、プロトタイプとは、ここでは正確には忠実度の低いものを指します。以下に説明する条件に必ず従ってください。さもないと、必要以上に時間を取られてしまうでしょう。そして、何をするものかではなく、どのように見えるかに集中するために、全員を招待するようにしてください。
改善の道
スタートアップにとって、最初の製品のプロトタイピングや反復は、早くて、コストが安く、正確なものである必要があります。スタートアップは厳しい制約の中にいるので、迅速に完成形にする必要があり、始めてすぐにターゲットから離れすぎる余裕はありません。
これはどんな企業組織でも適用されるものです。必要なのは、以下の条件に従うことだけです。
色を制限する
色は制限しましょう。テキストのハイパーリンクを知らせるのには、青を使いましょう。ほかの部分はすべて白黒の配色かシンプルなカラーで統一して、ビジュアルの階層をわかりやすくしましょう。
グラフィカルな要素を排除する
画像やグラフィックデータを表示してはいけません。どちらかを取り入れた瞬間、チェックする人は画像やグラフィックばかりに注目してしまい、スクリーンのレイアウトやコンテンツの構成、操作性、インタラクション、ワークフローなどへの批判的な視点が失われます。
フォントは普遍的な物を使う
Arial以外のフォントは使ってはいけません。色と同じで、フォントを変えると余計な分析と推論の的になってしまいます。
インタラクティブなものは気づけるようにする
すべてのインタラクティブな要素には実際のラベルを付けましょう。正しいものや完成版である必要はありませんが、ナビゲーションメニューのアイテムやアコーディオンメニューのコンテンツ、データテーブル、ボタン、フォームフィールドなどに関しては、必ずフィードバックをもらってください。フィードバックを得る唯一の方法は、考えるきっかけを提示してあげることです。
ダミーテキストは使わない
できる限り実際のテキストコンテンツを用いましょう。コンテンツは、コンテキストを形作る上で長期間使われます。そしてコンテキストは、ユーザー体験の鍵となるものです。コンテンツの周辺をデザインしましょう。「Lorem ipsum」のようなダミーテキストよりは、コンテンツの大雑把な草案のほうがはるかに建設的です。
インタラクションはシンプルに
インタラクションはシンプルにしましょう。デモンストレーションのために、大量の実物のコーディングが必要になるものはすべて、このあと忠実度の高いプロトタイプを作る際に抽出して、再考する必要があります。
注釈をつける
要件を提案し、ドキュメント化し始めるために注釈をつけましょう。インタラクションについて決断したすべてのことの論理的根拠を伝えるのはエンジニアの責任です。プロトタイプに注釈をつけることで、誤解を減らすだけでなく、「単なる議事録」よりもコンテキストに沿ったドキュメントを作成することができます。過去の記事で私が提案したユーザーストーリーのフォーマットを試してください。完璧なフォーマットです。
・・・
ここで提唱した忠実度のレベルがどの程度のものか理解してもらうため、実際に企業向けドキュメント管理プラットフォームのプロトタイプを作成してみました。そのプロトタイプが以下の画像のものです。
UXPinによるプロトタイプ
UXPinによるプロトタイプ
