第10回:プロトタイピング: 思考を形にする
本日の到達目標
- プロトタイプの種類 (Lo-Fi / Hi-Fi)と使い分けを理解する。
- Figma等のツール(または手書き)を用いて、操作可能なプロトタイプを作成する。
- 「作り込みすぎない」ことの重要性を理解する。
1. プロトタイプとは?
プロトタイプとは、完成品ではないが、完成品の「体験」をシミュレーションできる模型のことだ。コードを書く前にプロトタイプを作る理由はただ一つ。「失敗のコストを下げるため」 である。
実装してから「使いにくい」と気づいて修正するには、プロトタイプの100倍のコストがかかる。
プロトタイプの種類
- Low-Fidelity (Lo-Fi) プロトタイプ:
- 特徴: 手書き、ワイヤーフレーム、白黒。
- 目的: 構成や流れ(フロー)の検証。
- メリット: 素早く作れて、捨てるのも惜しくない。今はこれを目指せ。
- High-Fidelity (Hi-Fi) プロトタイプ:
- 特徵:最終的なデザインに近い色、画像、アニメーション付き。
- 目的:ビジュアル、細かなインタラクションの検証。
2. ワイヤーフレームの作成
UIフローに基づき、各画面のレイアウト(ワイヤーフレーム)を作成する。ここでは「美しさ」は不要だ。「配置」と「情報の優先順位」だけを考えろ。
1. 配置すべき要素:
- ナビゲーションバー (戻るボタン、メニュー)
- メインコンテンツ(画像、テキスト)
- Call to Action (CTA) ボタン (「登録する」「次へ」などの重要なボタン)
2. 注意点:
- 実際の文章を入れろ。「Lorem Ipsum」や「テキストテキスト」は禁止だ。文字数によってレイアウトは破綻する。
3. インタラクションの設定 (Figma等の活用)
画面の絵を描くだけでは不十分だ。画面と画面をつなぎ、遷移を設定することで初めて「体験」の検証が可能になる。
- ホットスポット: どこを押したら反応するか。
- トランジション: 画面がどう切り替わるか(スライド、フェード、即時)。
- フィードバック: ボタンを押した時、色は変わるか? 押した感触はあるか?
諸君はエンジニア志望が多いだろうが、今の時代、Figmaのようなデザインツールも「開発環境」の一部だと思え。コードを書くようにデザインをつなげ。
演習: Lo-Fiプロトタイプの作成
- 前回作成したUIフローに基づき、主要な画面(3~5画面程度)のワイヤーフレームを作成する。(手書きをスマホで撮る、またはFigmaを使用)
- 画面間をリンクさせ、実際にスマホ等で操作して画面遷移ができる状態にする。
- 確認:
- ボタンは指で押せる大きさか?
- 文字は読めるか?
- 次に何をすべきか、画面を見て直感的にわかるか?
警告: 色塗りに時間をかけるな。今は「構造」と「遷移」が正しければ、見た目は豆腐(四角)で構わない。
第11回:ユーザビリティテスト:真実との対面
本日の到達目標
- ユーザビリティテストの目的と「5人テスト」の法則を理解する。
- 思考発話法を用いたテストを実施し、改善点を発見する。
- テスト結果を客観的に記録し、修正の優先順位をつける。
1. 我々はユーザーではない
諸君はここまで一生懸命プロトタイプを作ってきた。愛着も湧いているだろう。だからこそ、諸君の目は曇っている。「ここはこう操作するはずだ」という思い込みは、ユーザーの前では無力だ。
ユーザビリティテストは、「自分の作品を自慢する場」ではなく、「自分の仮説が間違っている箇所を見つける場」である。
ニールセンの「5人テスト」の法則
ユーザビリティの権威ヤコブ・ニールセンによれば、「5人のユーザーにテストすれば、ユーザビリティ問題の85%は発見できる」とされる。100人に聞く必要はない。まずは隣のクラスの学生や、ターゲットに近い5人で十分だ。
2. テストの準備と実施方法
- タスクの用意:
- 「自由に使ってみて」は最悪の指示だ。具体的な目的を与えよ。
- 例:「あなたは来期の時間割を組もうとしています。このアプリを使って、月曜1限に『UXデザイン』を登録してください」
- 思考発話法(Think Aloud):
- ユーザーに、頭の中で考えていることを独り言として喋りながら操作してもらう。
- 「えーっと、登録ボタンはどこだろう...」 「このアイコン、何の意味かな?」といった呟きこそが、改善のヒントになる。
- 観察者の役割:
- 絶対に助け船を出すな。ユーザーが詰まっても、黙って観察せよ。
- ユーザーが「これどうやるんですか?」と聞いてきたら、「あなたはどうすればいいと思いますか?」と聞き返せ。
3. 結果の分析と優先順位付け
テストが終わったら、発見された問題をリストアップし、修正の優先順位を決める。全てを直す時間はない。
問題の深刻度評価
- Critical (致命的): タスクが完了できない。ユーザーが迷子になる。→即時修正必須
- Serious (深刻): タスク完了に著しく時間がかかる、または強いストレスを感じる。→修正すべき
- Minor (軽微): 気にはなるが、タスク完了には影響しない。→時間があれば修正
演習:相互ユーザビリティテスト
- 隣のチームとペアを組み、互いのプロトタイプをテストし合う。
- 役割:
- ユーザー役: タスクを実行し、思考発話を行う。
- 進行役: タスクを提示し、ユーザーを観察する。
- 書記: ユーザーの行動、発言、詰まった箇所を記録する。
- テスト終了後、発見された「課題(バグではない、使いにくさ)」を3つ挙げ、深刻度を判定する。
注意: 批判されても怒るな。ユーザーが使いにくいと言ったら、それは設計が悪いのだ。ユーザーは常に正しい。
第12回: 改善とプレゼンテーション: 価値を伝える
本日の到達目標
- テスト結果に基づいてプロトタイプをブラッシュアップする。
- UXデザインのプロセスを論理的に伝えるプレゼンテーション構成を学ぶ。
- 最終成果物としての「提案」をまとめる。
1. イテレーション (反復)
ユーザビリティテストで得られた知見を基に、プロトタイプを修正する。UXデザインは直線的なプロセスではない。作って、試して、直す。このサイクル(イテレーション)を回す回数が多いほど、プロダクトの質は向上する。
- 修正のポイント: 深刻度「Critical」の問題は必ず潰す。機能を追加するのではなく、「削る」や「配置を変える」 ことで解決できないか検討せよ。
2. UXポートフォリオとしてのプレゼンテーション
最終発表は、単にアプリの画面を見せる場ではない。「なぜその解決策に至ったのか」という思考のプロセスこそが評価される。これは就職活動におけるポートフォリオ作成と同じだ。
プレゼンテーションの構成案 (STARフレームワークの応用)
- 課題の背景(Situation/Task):
- 誰の(ペルソナ)、どんな課題 (HMW)に着目したか?
- なぜその課題を解決する価値があるのか? (リサーチからのインサイト)
- アプローチ (Action):
- どのように解決策を導き出したか? (ジャーニーマップ、アイデア発想)
- どのような仮説を持ってプロトタイプを作ったか?
- 検証と改善(Result / Reflection):
- ユーザビリティテストで何が分かり、どう改善したか? (Before/Afterを見せると効果的)
- 最終提案(The Solution):
- 完成したプロトタイプのデモ(または動画)。
- それによってユーザーの生活はどう変わるか? (To-Be ジャーニー)
3. ストーリーテリングの技術
機能一覧を読み上げるな。物語を語れ。
- Before: 「このアプリには、ドラッグ&ドロップ機能と、単位計算機能と、通知機能があります。」(機能ベース)
- After: 「ペルソナの健太君は、もう電卓を叩く必要はありません。このアプリを開けば、指一本で時間割が完成し、自動的に卒業までの道のりが示されます。」(価値ベース)
聞き手(評価者やクライアント)は、機能にお金を払うのではない。機能がもたらす「変化」にお金を払うのだ。
演習: 最終ブラッシュアップと発表準備
- 前回のテスト結果を反映し、プロトタイプを修正する。
- プレゼンテーションの構成案(骨子)を作成する。
- スライド1: タイトルとチーム名
- スライド2: ターゲットと課題(Before)
- スライド3: リサーチからの発見(インサイト)
- スライド4: 解決策のコンセプト
- スライド5: プロトタイプデモ(主要機能)
- スライド6: テストによる改善点
- スライド7: 提供価値(After)
- チーム内でリハーサルを行い、時間配分(例:5分発表)を確認する。
諸君の健闘を祈る。これまでのプロセスが正しければ、結果は自ずとついてくるはずだ。