はじめに
ワイヤーフレームで画面の構成が決まった。だが、それは「状態」を示しただけだ。実際のユーザー体験は、状態が変化していく「流れ」として成り立っている。
インタラクションは、その「変化」を設計する。プロトタイプは、その設計を「動く形」で表現し、検証する材料となる。この記事では、ワイヤーフレームを前提に、インタラクションの設計とプロトタイプの作り方を解説する。
2. インタラクションとプロトタイプとは
インタラクションは、ユーザーが画面を操作したときに起きる状態の変化を設計するものだ。ボタンを押したらモーダルが開く、入力が終わったら次の項目が表示される、といった具合である。
プロトタイプは、そのインタラクションを実際に動かして表現したものだ。静止画では伝わらない「動き」を、実際に体験できる形にする。
ワイヤーフレームとの違い
ワイヤーフレームはある時点での「状態」を示す。だが、実際のユーザー体験は連続的だ。ボタンを押す前と後で、画面は変化する。
インタラクションは、その変化の設計を担う。ワイヤーで決めた「タスク確認画面（例：通勤中のタローが確認する画面）」が、ボタンを押した後どう遷移するか、どうフィードバックを返すかを設計する。
インタラクション・プロトタイプが設計に役立つ理由
インタラクションがあると、時間的な流れが見える。画面Aから画面Bへの遷移は瞬間的だが、その間にユーザーの認知処理がある。変化が速すぎたり、予期せぬ動きだったりすると、ユーザーは戸惑う。
プロトタイプがあると、その流れを実際に体験できる。紙や静止画では見えにくい「遷移の違和感」や「操作の齟齬」が、動かしてみることで見えてくる。
崩れやすいポイント
インタラクション・プロトタイプは実務でよく崩れる。理由は「派手な動き」と「設計判断の材料」の混同が起きやすいことだ。
初心者が陥りやすいのは、ワイヤーの意図を無視して「動き」を先に作ってしまうことだ。開発側の都合や流行の動きを先に実装し、ユーザーの課題解決から逸脱しがちだ。
また、プロトタイプを「完成品」として捉えて検証を怠ることもある。作ることが目的になり、それがユーザーの文脈に即しているかの検証がおろそかになる。プロトタイプで検証すべきは、遷移の自然さや操作のフィードバック、エラー時の動きなど、実際の使用時に起きる具体的な体験だ。
インタラクションは「ユーザーの文脈に即した状態変化」であり、プロトタイプは「検証の材料」である。ワイヤーで決めた意図から逸脱していないか、常に確認しながら進める。
3. プロトタイプの種類と使い分け
プロトタイプは、目的や精度によって種類が分かれる。作る労力と得られる検証の深さのトレードオフを理解し、適切なものを選ぶ。
紙プロトタイプ
紙や付箋を使った簡易的なプロトタイプ。画面を切り出し、手で動かしながら遷移を確認する。
作る労力は少なく、早い段階で遷移の流れを検証できる。細部のインタラクションは省略し、画面間の流れが自然かを見るのに適している。ワイヤーフレームの直後、最初の遷移検証に使うことが多い。
デジタルプロトタイプ（低・中忠実度）
PowerPointやKeynote、Figmaなどで作るプロトタイプ。画面をつなぎ、ボタンを押したら遷移する、といった基本的な動きを再現できる。
紙より忠実度が高く、実際のデバイスで操作感を検証できる。インタラクションのタイミングや遷移の違和感が見えやすい。画面構成が固まった後、実際のデバイスで操作感を確認する段階で使う。
デジタルプロトタイプ（高忠実度）
実際の開発に近い形で作るプロトタイプ。アニメーションの細部や、データの動きまで再現する。
作る労力は大きいが、ユーザーテストで実際の使用感に近いフィードバックが得られる。細部のインタラクションがユーザーの体験にどう影響するかを検証できる。最終的なユーザーテストやステークホルダーへの説明直前など、細部まで確認が必要な段階で使う。
使い分けの基準
どのプロトタイプを使うかは、検証したい内容による。画面間の流れが自然かを見たいなら紙で十分。操作感や遷移の違和感を見たいならデジタル低・中忠実度。細部のインタラクションが体験に与える影響を見たいなら高忠実度。
ただし、高忠実度にすると作る労力が増え、修正コストも高くなる。必要以上の忠実度で作ると、検証のサイクルが遅くなる。検証したい内容に応じて、適切な粒度を選ぶ。
4. インタラクション・プロトタイプと前工程の関係
インタラクション・プロトタイプは、これまでの設計工程の成果を「動く形」でつなぐ役割を持つ。前工程で何を決めたかを確認し、それを引き継ぐ形で作る。
ペルソナ・ユーザーストーリーとの接続
ペルソナは「誰のため」かを示し、ユーザーストーリーは「何のために」かを示す。インタラクションは、その文脈の中で「どう動くか」を設計する。
例えば、ペルソナが「時間に追われている通勤者」なら、操作は最小ステップで完了するべきだ。ユーザーストーリーが「タスクを完了したい」なら、完了後のフィードバックは明確に示すべきだ。この文脈を無視した派手な動きは、むしろ体験を損なう。
カスタマージャーニーとの接続
カスタマージャーニーは、ユーザーの時間的な流れと感情の変化を示す。インタラクションは、その流れの中で画面がどう遷移するかを設計する。
認知負荷が高いタイミングでは、画面遷移を減らす。迷いやすい場面では、操作のフィードバックを強化する。ジャーニーで見つけた「困っているポイント」は、インタラクションで解消する候補となる。
ワイヤーフレームとの接続
ワイヤーフレームは「状態」を示す。インタラクションは、その状態間の「遷移」を設計する。
ワイヤーに書かれた要素の役割を確認する。ボタンはどこに遷移するのか、モーダルは何を表示するのか。ワイヤーの意図を整理してから、インタラクションを設計する。
5. インタラクション・プロトタイプの作り方
ここからは実際の作り方に入る。ワイヤーフレームを前提に、インタラクションを設計し、プロトタイプで検証する流れを解説する。
5-1 ワイヤーフレームの意図の整理
インタラクションを設計する前に、ワイヤーフレームが何を意図しているかを整理する。これを飛ばすと、後で軌道修正が必要になる。
要素の役割を確認する
ワイヤーに書かれた各要素が、何のために存在するかを確認する。ボタンは「押すと何が起きる」のか、入力欄は「何を入力して何が変わる」のか。見た目だけでなく、機能と目的を整理する。
例えば、タスク確認画面の「完了」ボタン。これは単にタスクを完了させるだけか、それとも完了後のフィードバックも含むか。ワイヤーに書かれていない遷移先や状態変化を、意図として補完する必要がある。
遷移の起点と終点を整理する
どの画面からどの画面へ遷移するか、起点と終点をリストアップする。ワイヤーは静止画なので、遷移の線が明示されていないことも多い。ユーザーの操作フローを追いながら、必要な遷移を抽出する。
通勤中のタローがタスクを確認して完了する流れを考える。タスク一覧→タスク詳細→完了確認→完了後のフィードバック、といった遷移が必要だ。これを漏れなく整理しておく。
文脈を引き継ぐ
ペルソナとユーザーストーリーで決めた文脈を、インタラクション設計に引き継ぐ。タローは電車の中で片手で操作する。画面遷移は最小限にし、操作ステップを減らす方向で設計する。
この整理を書き留めておくと、後の設計判断で迷いが減る。なぜこの遷移にしたのか、なぜこのフィードバックなのか、根拠を持って説明できる。
5-2 インタラクションの設計
ワイヤーの意図が整理できたら、具体的なインタラクションを設計する。ここでは「動き」ではなく、「状態変化」を設計する。
状態変化を分解する
一つの操作が起きたとき、画面はどう変化するかを分解する。ボタンを押す→ローディング表示→遷移→新しい画面、といった具合だ。
各ステップで何が起きるか、ユーザーの認知にどう影響するかを考える。ローディングが長いと不安になる。遷移が突然だと戸惑う。変化の速度と順序を調整する。
フィードバックの設計
操作に対して、システムは何を返すか。ボタンを押したら押したことがわかる表示を。処理が終わったら完了を示す。エラーが起きたら何が悪いか伝える。
タローの場合、電車の揺れで誤タップする可能性がある。ボタンの押下フィードバックは明確にし、取り消しの手段も考慮に入れる。
エラー時の動きを考える
正常系だけでなく、エラー時のインタラクションも設計する。ネットワークが不安定な電車内で、通信エラーが起きたらどうするか。リトライするか、後で処理するか、オフライン対応にするか。
エラー時の動きを後付けにすると、ユーザーを困らせがち。最初から設計に含めておく。
実務で崩れやすい点
ここで陥りやすいのは、インタラクションを「派手な動き」として捉えることだ。アニメーションの種類を先に決めて、それに合わせて設計を無理やりこじつける。これは本末転倒だ。
また、全ての画面に同じ動きを適用しがちだ。統一感があるように見えて、実は文脈に合っていない。タスク完了の確認と、設定変更の確認が同じ動きでは、ユーザーの認知負荷が違う。
インタラクションは、ユーザーの文脈に即した状態変化を設計すること。動きはその結果として選ぶ。
インタラクション仕様サンプル
「何を書き出すか」を具体的に理解するために、タローのタスク完了フローを例に、インタラクションの要点をまとめた一例を示す。
| 操作 | トリガー | 状態変化 | フィードバック |
|---|---|---|---|
| タスク完了ボタン | タップ | 一覧→完了確認モーダル表示 | ボタン押下エフェクト＋モーダルスライドイン |
| 完了確認OK | モーダル内OKタップ | モーダル閉じ→一覧（完了タスク除外） | トースト「完了しました」（2秒表示） |
| キャンセル | モーダル内キャンセルタップ | モーダル閉じ→一覧に戻る | モーダルスライドアウト |
| 通信エラー | 完了送信失敗 | 一覧のまま（状態変化なし） | エラートースト「再試行してください」 |
この表の価値は、正常系だけでなくエラー時と取り消し操作を最初から書き出していることだ。電車内での誤タップや通信の不安定さはタローの文脈から来ており、設計の最初から仕様に含まれている。
5-3 プロトタイプの作成
設計したインタラクションを、プロトタイプで表現する。作るのは「完成品」ではなく「検証の材料」だ。
必要な粒度を選ぶ
5-1で整理した検証内容に応じて、プロトタイプの粒度を選ぶ。画面間の流れが自然かを見たいなら紙や簡易デジタルで十分。操作感や遷移の違和感を見たいなら中忠実度。細部のインタラクションが体験に与える影響を見たいなら高忠実度。
タローのケースでは、まず紙やFigmaの簡易プロトタイプで遷移の流れを確認し、問題なければ中忠実度で操作感を検証する。電車内での片手操作がしやすいか、遷移のタイミングが自然かを見る。
作りながら設計を見直す
プロトタイプを作る過程で、設計の穴が見えることがある。遷移をつなげてみると、ステップが多すぎることに気づく。フィードバックを実装しようとして、何を示すべきか迷う。
これは設計が不十分だったサインだ。プロトタイプ作りを続ける前に、5-2の設計に戻り、意図を再確認する。作り直しは避けられないが、作り終わってからの修正よりは早い。
実務で崩れやすい点
ここで陥りやすいのは、プロトタイプを「見せるもの」として作りすぎることだ。ステークホルダーに見せることを意識して、見た目を整えすぎる。すると、実際の検証がおろそかになる。
また、作ることが目的になり、検証を怠ることもある。プロトタイプができたら、それを使って実際のユーザーフローを追ってみる。自分で操作して違和感を探す。可能なら、実際のユーザーに見てもらう。
プロトタイプの価値は、作り終わったときではなく、検証を通じて初めて生まれる。
5-4 検証と反復
プロトタイプを使って検証し、問題があれば設計を修正する。このサイクルを繰り返す。
検証の観点
何を検証するかを明確にする。主な観点は以下の通りだ。
- 遷移の自然さ：画面が次々に変わるとき、違和感がないか
- 操作のしやすさ：ボタンは押しやすいか、誤操作は起きにくいか
- フィードバックの明確さ：操作した結果がわかるか
- エラー時の動き：エラーが起きたとき、ユーザーはどうなるか
- 文脈との整合性：ペルソナの状況で使えるか
タローの場合、電車内での片手操作、ネットワークの不安定さ、時間に追われる状況、これらを検証の文脈として持つ。
問題の切り分け
検証で問題が見つかったら、それがインタラクションの問題なのか、それともワイヤーフレームや前工程の問題なのかを切り分ける。
遷移が多くて煩雑なら、インタラクションの設計を見直す。画面の構成自体が複雑なら、ワイヤーフレームに戻る。タスクの粒度がおかしいなら、ユーザーストーリーの見直しが必要かもしれない。
問題の根本原因を探り、適切な工程にフィードバックする。
反復のサイクル
検証→修正→再検証を繰り返す。一発で完璧にすることは稀だ。小さな単位で回すほど、修正コストは低く済む。
紙プロトタイプで遷移の流れを確認し、問題なければデジタルで操作感を検証し、それも問題なければ高忠実度で細部を詰める。段階的に精度を上げながら、各段階で検証を挟む。
実務で崩れやすい点
ここで陥りやすいのは、検証を「最後のステップ」として捉えることだ。プロトタイプが完成してから検証を始める。そうすると、問題が大きくなってから気づき、修正に時間がかかる。
また、検証で見つかった問題を無視して先に進むこともある。スケジュールの都合や、作り直しの手間を避けようとして、本来直すべき問題を残す。
検証は最後の関門ではなく、設計の一部として繰り返す。見つかった問題は、優先順位をつけて対処する。小さな問題は後回しにしても、体験を損なう大きな問題は必ず直す。
6. この知識がUI設計で効く場面
インタラクション・プロトタイプは、設計の仮説を動く形で検証する工程だ。以下の判断を下すとき、プロトタイプが直接の根拠になる。
- 遷移数を減らすべき場面を見極めるとき: ジャーニーで感情が落ちていたステップの原因が「遷移の多さ」か「操作の重さ」かを、プロトタイプで初めて切り分けられる。ワイヤーだけでは見えなかった問題が動かすと見える。
- フィードバックを強く出すべき操作を決めるとき: ペルソナの文脈（例: 電車の揺れの中での操作）から、どのアクションに明確なフィードバックが必要かが決まる。「押した感触が伝わるか」は動かして初めて確認できる。
- エラー時の戻し方を設計するとき: 正常系だけでなくエラー時のフローを検証できる。「ネットワークが切れたとき」「誤タップしたとき」のリカバリがスムーズかどうかは、プロトタイプで試して初めてわかる。
- 文脈依存の操作体験を確かめるとき: タローのような「時間に追われた移動中のユーザー」が実際に使えるかは、静止画では確認できない。文脈ごとの操作感をプロトタイプで体験して判断する。
設計フェーズに入ったとき、ジャーニーマップとワイヤーを手元に置いておくと、この4つの問いを立てやすくなる。
7. まとめ
インタラクション・プロトタイプは、ワイヤーフレームで決めた構造を「動く体験」に変換し、設計の仮説を検証するツールだ。状態変化の意図を整理し、文脈に即したフィードバックとエラー処理を設計し、プロトタイプで検証を回す。この流れを通して、抽象的な課題が操作レベルの設計判断に落ちていく。
実務で崩れやすいのは、「作ること」が目的になることだ。プロトタイプは完成品ではなく検証の材料であり、動かして問題を見つけることに価値がある。見た目より動きの自然さ、表現より文脈との整合性を先に確かめる。
ここで検証したプロトタイプは、次のStep 7「ユーザーテストとフィードバック」での検証素材になる。実際のユーザーに使ってもらうことで、自分では気づかなかった「どこで詰まるか」が見えてくる。プロトタイプという仮説を持って、次の検証ステップへ進もう。
関連知識
この記事に登場した概念の定義は、以下の用語集で確認できる。
- プロトタイプ：設計の仮説を動く形で表現し、検証するための作成物
- インタラクションコスト：ユーザーが目的を達成するまでに要する操作の総負荷
- フィードバック：操作に対してシステムが返す反応・応答
- ユーザビリティ：ユーザーが目的を達成できる効率・効果・満足度
- カスタマージャーニー：インタラクション設計のインプットとなる、時間軸での体験の流れ
- ペルソナ：インタラクションの文脈（誰が・どんな状況で操作するか）を定めるユーザー像