第8回:アイディエーション: 課題を解決策へ変換する
本日の到達目標
- 定義された課題 (HMW)に対し、質より量を重視してアイデアを出す手法を学ぶ。
- 拡散したアイデアを収束させ、有望なコンセプトを選定する。
- アイデアを他者に伝えるためのストーリーボードを作成できる。
1. How Might We (どうすれば〜できるか?)
第2章で作成したペルソナとジャーニーマップから、解決すべき「課題 (Pain Points)」は見えているはずだ。しかし、「課題: 待ち時間が長い」だけでは、脳は解決策を出しにくい。これを「どうすれば(How Might We = HMW) ~できるか?」 という疑問文に変換することで、脳を解決モードに切り替える。
- 悪い例: 「待ち時間をなくす」
- 良い例 (HMW):
- 「どうすれば、待ち時間を『楽しい時間』に変えられるか?」
- 「どうすれば、物理的に並ばずに順番を待てるか?」
- 「どうすれば、待ち時間が実際より短く感じられるか?」
問いの立て方によって、出てくるアイデアの方向性が変わることを理解せよ。
2. アイデアの拡散: クレイジー8 (Crazy 8s)
良いアイデアは、大量の悪いアイデアの死骸の上に成り立つ。最初から「正解」を出そうとするのは愚かだ。まずは量だ。
クレイジー8の手順
- A4用紙を3回折り、8つのマスを作る。
- 1マスにつき1分、合計8分間で、HMWに対する解決アイデアを8つスケッチする。
- ルール:
- 絵心は不要。棒人間で十分だ。
- 文字で補足しても良い。
- 現実離れしていても構わない(制約を取り払え)。
- 手が止まったら、前のアイデアのバリエーションを描く。
この演習は、諸君の脳内にある「常識」というリミッターを強制的に解除するために行う。
3. アイデアの収束と選択
拡散した後は、現実的な解に落とし込む必要がある。チーム全員のクレイジー8を壁に貼り出し、以下の基準で「推しアイデア」に投票(ドット投票)を行う。
- Desirability(有用性): ユーザーにとって魅力的か? 課題を解決するか?
- Feasibility(実現可能性): 技術的に実現可能か? (今の岩崎学園のリソースで作れるか?)
- Viability(持続可能性): ビジネスとして成り立つか? 運用し続けられるか?
最も票を集めたアイデア、あるいは「最もワクワクする」アイデアを一つ選定し、それをメインコンセプトとする。
4. ストーリーボード: 利用シーンの可視化
選ばれたアイデアが実際に使われる場面を、4コマ漫画のような形式(ストーリーボード)で描く。機能の説明ではなく、「ユーザーがどのような状況で使い始め、どうハッピーになるか」 という文脈を描くこと。
構成要素
- 起(Situation): ペルソナが課題に直面している状況。
- 承(Trigger): 解決策 (アプリやサービス)に出会う、または使い始めるきっかけ。
- 転(Action): 実際にその機能を使っている様子。
- 結(Outcome): 課題が解決され、ペルソナが満足している状態。
演習: HMWとクレイジー8
- 前回のジャーニーマップから、最も重要な「機会」を選び、HMW(どうすれば〜できるか?)の形式に変換する。
- 個人ワーク: HMWに対する解決策を「クレイジー8」で8案出す。
- グループワーク: 全員の案を共有し、ドット投票で「ベストアイデア」を決定する。
- ベストアイデアを基に、簡単なストーリーボード (4コマ)を作成する。
第9回:情報設計とUIフロー
本日の到達目標
- 情報アーキテクチャ (IA)の基本概念を理解する。
- ユーザーが迷わないための画面遷移 (UIフロー)を設計できる。
- 必要な画面と機能を洗い出し、ワイヤーフレームの前段階を作成する。
1. 情報アーキテクチャ (IA): 骨格を作る
家を建てる時に、いきなり壁紙を選び始める大工はいない。まず設計図が必要だ。アプリやWebサイトも同様で、UIデザイン(色や形)の前に、「情報の構造」を定義しなければならない。これを情報アーキテクチャ (IA)と呼ぶ。
IAの基本要素
- ラベリング: わかりやすい名前をつける。「マイページ」なのか「アカウント」なのか。「投稿」なのか「作成」なのか。岩崎学園の学生に伝わる言葉を選べ。
- ナビゲーション: ユーザーが今どこにいて、どこへ行けるかを示す。
- 階層構造: 情報をどのようなカテゴリで分類するか。
2. UIフロー(ユーザーフロー図)
ストーリーボードで描いた「体験」を、具体的な「画面のつながり」に変換する。ユーザーがゴールに到達するまでに通るステップを可視化したものがUIフローだ。
作成のポイント
- ハッピーパスを優先: エラー系や例外処理はいったん無視し、ユーザーが最短でゴールできるルート(ハッピーパス)をまず設計する。
- 画面とアクション: 「画面(四角)」と「ユーザーの操作(矢印)」でつなぐ。
- 例: [ログイン画面] → (ログインボタン押下) → [ホーム画面] → (検索アイコン押下) → [検索画面]
- 条件分岐:「ログイン済みか?」「検索結果があるか?」などの分岐をひし形で表現する。
この図があれば、エンジニアは何を実装すべきか理解でき、デザイナーは何枚の画面を作ればいいか把握できる。
3. オブジェクト指向UI (OOUI)の考え方
近年主流のUI設計思想だ。タスク(やること)から考えるのではなく、オブジェクト(目当てのもの)から考える。
- タスク指向(古いUI): 「履修登録をする」というメニューがあり、そこに入ってから科目を選ぶ。
- オブジェクト指向 (現代のUI): 画面に「科目(オブジェクト)」が並んでおり、それを選んでから「登録する」ボタンを押す。
ユーザーは「登録がしたい」のではなく「科目が見たい」のだ。名詞(オブジェクト)を先に提示し、動詞(アクション)を後にする設計を心がけよ。
演習: UIフローの作成
- 前回決定した「ベストアイデア」を実現するために必要な 「画面」 をリストアップする。(例:一覧画面、詳細画面、完了画面など)
- ペルソナがアプリを開いてから、目的を達成して閉じるまでの流れを、UIフロー図として描く。
- チェックポイント:
- 画面の行き来はスムーズか?
- 「戻る」手段はあるか?
- 行き止まりの画面はないか?