予約画面の改善を求められたチームは、まずカレンダーの配置を見直すところから始めるかもしれません。しかし、デザイン思考を取り入れているチームなら、「そもそもなぜ予約が難しくなっているのか」という背景まで掘り下げます。問題は別のところにあるかもしれません。自分に必要な予約枠がどれかわからなかったり、利用資格を満たしているか判断できなかったり、あるいは日時を決めた後の移動手段の手配に困っていたりする可能性があるのです。

デザイン思考は、提案された解決策を変更するのに多大なコストがかかるようになる前に、こうした一段広い問いを立てる余白をつくります。リサーチ、問題の枠組み設定（フレーミング）、アイデアの発想、プロトタイピング、テストを組み合わせ、理解が深まるにつれてこれらのプロセスを行き来します。

問題を捉え直すと、デザインすべきものが変わる

英国デザイン協議会（Design Council）が提唱するダブルダイヤモンドは、課題の探求から定義へ、そして解決策の開発から提供へと至るプロセスを描いたものです。これは「問題について学ぶこと」と「どう対処するかを決めること」を明確に区別するのに役立ちます。ワークショップを一度開いたからといって、そのどちらかが自然と完了するわけではありません。

最初のリサーチが、探求に確かな裏付けをもたらします。ユーザーインタビューを行えば予約前後の状況が見えてきますし、観察調査を行えばスタッフが介入している箇所やユーザーが途中で離脱しているポイントが浮き彫りになります。チームがリサーチ結果を課題定義に落とし込む際は、常にそうした事実との結びつきを保つ必要があります。「もっとシンプルなカレンダーが必要だ」という定義は、すでに解決策を決めつけています。「日時を選ぶ前に、適切な予約枠を特定できない」と表現することで、より多くの可能性が開かれます。

この違いは、先ほどの予約の例でも極めて重要です。カレンダーのUIを改善しても、かえって「間違った予約」を取りやすくしてしまうだけかもしれません。サービス内容をより分かりやすく説明したり、簡単な利用資格チェックを設けたり、担当者に相談できる窓口を用意したりする方が、本質的な課題に直接アプローチできる可能性があります。

代替案を具体的な形にする

問題を十分に理解できたら、チームは複数の解決策を出し合い、検証できる形へと落とし込んでいきます。スケッチを描くだけでユーザー体験（ジャーニー）の違いが浮き彫りになることもあれば、適切なサービスを選択して予約できるかを確認するために、クリック可能なプロトタイプが必要になることもあります。適切なプロトタイプの忠実度（フィデリティ）は、検証したい問いによって決まります。

テストは、アイデアが失敗する余地を残して行うべきです。参加者には、コンセプトの良さを説明するプレゼンを聞かせるのではなく、リアルな状況設定と実際に操作できる環境を用意する必要があります。提案された解決策がインターフェースである場合、Ballparkのプロトタイプテストがその検証を後押しします。

ワークショップだけでは補えないもの

活発なワークショップは、多様な可能性を生み出し、チーム内の相互理解を深めるのに役立ちます。しかし、実際のユーザーとの対話の代わりにはなりませんし、デリバリーの責任者が誰も考慮していなかった運用の制約を解消してくれるわけでもありません。

ワークショップのアウトプットは、根拠の強さにばらつきがある「提案」として扱いましょう。選んだ方向性を裏付ける観察事実は何か、まだ仮説にとどまっている部分はどこか、そして次の検証で何を明らかにすべきかを記録しておくことが大切です。デザイン思考が真価を発揮するのは、そうしたその後の意思決定を通じてこそであり、ときには「すでに解決したと思っていた問題に立ち戻る」という、勇気のいる決断を下すことにもつながります。