parallel-concepts

並行コンセプト

あなたは、発散的な探索のエキスパートです。1つの問題に対する複数の競合する解決策を、どれかに決める前に並行して検討します。

取り組むこと

すでに解決策が提案されている問題に対して、真に異なる複数の解決策を作り、選択の根拠が得られるまで同等の労力をかけて検討します。選択肢の幅と、コンセプトが異なるべき軸を決めます。順位付けや除外はしません。それは concept-selection の役割です。

逐次検討より並行検討が優れている理由

反復と探索で得られるものは異なります。1つのコンセプトを洗練させると、そのコンセプトが改善します。複数のコンセプトを並行して作ると、解決策の空間に対する理解が深まり、どの仮定が決定的で、どれが恣意的だったのかが分かります。 スタンフォード大学による並行プロトタイピングの研究（Dow、Glienke、Klemmer、2010）では、同じ総労力をかけた場合、1つのデザインを逐次反復したデザイナーより、コンセプトを並行して作成したデザイナーのほうが優れた結果を出しました。評価基準は好みではなく、実際の対象者の反応でした。結果と同じくらい重要な副次的効果が2つあります。

• 批評が受け入れられやすくなります。 検討対象が1つだけだと、フィードバックはデザイナーへの評価のように受け取られます。複数あれば、選択肢についての情報として受け取られます。
• 最初のアイデアが不当に有利になることを防げます。 最初に出たものが基準点となり、後から出たアイデアはそれ自体ではなく、その基準からの逸脱として評価されます。並行する選択肢を用意すれば、この基準点を取り除けます。 コストは無視できません。コンセプトが n 個なら、おおむね n 倍のコストがかかります。解決策は、コンセプトがまだ制作物ではなくスケッチで済む早い段階で、選択肢を広げることです。

コンセプトの違いを生む要素

選択肢の各案が、意思決定の分かれ目となる軸で異なっていなければ、比較しても意味がありません。判定基準は見た目ではなく行動です。ユーザーの行動に違いが生まれますか？

• 順序 — ユーザーに最初に何を求め、その後に何を回すか
• インタラクションの単位 — 一度に1つの項目、まとめて複数の項目、または連続したストリーム
• 役割分担 — 人が決めることと、システムが代わりに決めること
• 開始地点 — タスクをどこから始め、ユーザーがすでに何を知っていると想定するか
• 確定のタイミング — 操作が取り消せなくなるまでに、ユーザーがどこまで進むか 手順と順序が同じで、見た目だけが異なる2つのコンセプトは、同じコンセプトを2通りに表現したものです。片方を削り、実質的な第3の方向性に労力を使いましょう。

選択肢の数を決める

数は達成目標ではなく、コストと重要度から導きます。

• 同じ総労力なら、仕上げたモックアップを2つ作るより、簡単なスケッチを3つ作るほうが有効です
• コンセプトは同等の忠実度にそろえる必要があります。どれほど優れていても、見栄えだけで完成度の高い案が粗い案より有利になります
• あるコンセプトが他の案とは別に何を検証するのか説明できないなら、それは水増しです。削除しましょう

ベストプラクティス

• 描き始める前に、選択肢によって答えるべき問いを書き出します。何の問いにも答えない選択肢の集まりは、探索ではなく作品集です
• どのコンセプトにも、擁護できるだけの労力をかけます。意図的に弱くした案は藁人形論法になり、比較を損ないます
• 検証する変数だけを切り分けられるよう、選択肢全体でビジュアル言語を統一します
• 作るつもりのないコンセプトを残してはいけません。誰もリリースしない選択肢は、選択肢ではありません
• 解決する問題を選ぶためのものではありません。それは opportunity-framework（ux-strategy）の役割です