プランナー（プロダクトオーナーやサービス企画の担当者）が実務でぶつかる大きな壁は、抽象的で曖昧な要望を、開発チームとデザインチームがすぐに実装できる明確な仕様へと磨き上げていく過程です。
検証できる受入基準を書く
ステークホルダーから「トップ画面の表示をもっと速くしてほしい」という依頼を受けたとします。このままでは、開発チームは何を作ればよいか判断できず、QA も合否を判定できません。そこで、測定とテストができる形の受入基準（Acceptance Criteria）に落とし込みます。クエストでは、Given-When-Then 形式で書く練習をします。
Given ログイン済みのユーザーが、モバイル回線でアクセスしている When トップ画面を開く Then 主要なコンテンツが、チームで合意した目標時間以内に表示される
「速く」という言葉を、誰が、どの条件で、何をもって達成とみなすかに分解できれば、開発と QA が同じ基準で話せるようになります。
情報設計（IA）と到達経路
複雑に入り組んだメニュー構成を、直感的にたどれる形に並べ直します。階層をできるだけ浅くし、主要な情報に少ないクリック数でたどり着けるように情報構造を整理します。目安としてよく使われるのは「3クリック以内」ですが、大切なのは回数そのものより、各段階で次に何を押せばよいか迷わないことです。
エラー時のUXライティング
通信に失敗したとき、「403」のようなシステムのコードだけを表示されても、利用者は何をすればよいかわかりません。何が起きたのか、次に何をすればよいのかが直感的に伝わる、明確で配慮のある案内文の書き方を学びます。
会員登録フォームの例
架空のシナリオです。会員登録フォームの企画段階で、パスワードが一致しないときに、どのタイミングで、どこに、どのような文言でエラーを表示するかを決め、仕様書の例外ケースとして明文化するクエストをプレイします。
プランナー研修のチェック
- 要望を、客観的に測定・検証できる仕様に落とし込めているか
- 情報構造がシンプルで、直感的にたどれるか
- 例外が起きたとき、利用者にわかりやすい文言が用意されているか
実務シナリオをクエストで体験してみませんか
開発、PMO、マークアップ、企画、デザインの職種別オンボーディングクエストは、First Run のデモで実際にプレイできます。