アプリ | 構造設計プロセス

構造設計とは？

ユーザーがわかりやすい / 使いやすいと感じ、思いのままに目的を達成できるUIをデザインするためには、「要件定義」や「構造設計」のプロセスが必要

ふだん目にしているデジタルプロダクトのUIの背後には、サービス全体をカタチづくる情報の構造が存在している

この情報構造は、デジタルプロダクトの骨格であり、大事な基礎となる

構造設計を端的に表現すると、アプリのわかりやすさを設計すること、といえる

レイアウトや装飾、画面の流れなど、ユーザーの目的に合わせて、どのような構成にするのかを検討する

また、構造設計は、アプリのデータ構造の整理にも機能する

適切な構造設計によって、アプリ全体がシンプルな構成となり、エンジニアリングにおいても優れた拡張性を提供する

構造設計のフェーズでできたプロダクトの骨格をもとに、UIデザインのフェーズでコンポーネントや視覚的要素、ナビゲーションについて検討していく

アプリの目的 / アプリの中でユーザーが強く関心を持って操作する要素 / 各画面の構成 / 各画面のつながり を明確にし

ユーザーが思い通りに操作できるようにUIをデザインしていく

構造設計は、つくるものの要件と、UIデザインをつなぐ架け橋となる

視覚的要素は「単語」、要素を組み合わせた画面は「文」、複数の画面で構成されるアプリ全体は「物語」のようなもの

しっかりとした骨格、土台があれば、さまざまな物語 / パターンに展開しても、重要な体験のブレを避けられる

見た目から独立した情報の構造を丁寧に設計することで、デザイナーはユーザーの創造性を刺激できる、よりたくさんの表現を試せるようになる

※ UIデザインの一手法として、コンセプトを具現化（プロトタイプを制作）し、議論して深めるプロセスを繰り返し、開発メンバーやステークホルダーとともに、つくるものの解像度を高めていくアプローチがある

しかし、実際に目に見えるカタチに落としたものの印象はとても強く、その見た目を変えることは心理的に難しい

具現化したUIによって、柔軟な考え方ができなくなってしまう可能性があるので、注意が必要

構造設計によって、ユーザーはアプリやサービスの本質的価値を捉え、迷うことなく操作できるようになる

適切に構造設計されたアプリは、ユーザーが自由に工夫して、楽しく目的を達成できるという、優れた体験を提供する

優れた体験は、ユーザーに思い通りに操作できている、という実感を与え、自身がレベルアップした感覚を生む

こうした体験が、ユーザーにとってのわかりやすさ / 使いやすさにつながる

構造設計の流れと成果物

以下のような情報ともとに、アプリの構造設計をすすめていく

サービスコンセプト

アプリの要件

機能仕様

ペルソナ

以下に、代表的な構造設計のステップを示す

これらは、1.から4.に向かって一方向的に進むものではなく、各ステップを何度も行き来し

抽象と具体の行き来を繰り返しながら、成果物をアウトプットしていく

code:構造設計のステップ

1.行動 / 操作シナリオの作成

ユーザーが目的達成するまでの理想的な状態の仮説を立てる

アウトプット：ユーザーシナリオ

ペルソナと、ペルソナが目的を達成した状態までをつなぐ、価値/シーン/行動/操作を具体的にしたもの

2.コンテンツ分類軸の設計

シナリオからユーザーの性質を理解し、それに合わせたコンテンツの分類をおこなう

アウトプット：コンテンツ分類軸

ユーザーがどのようなコンテンツを探すのか、というユーザー視点の分類と

コンテンツがどのような属性を持っていて、どのようにカテゴライズすれば探しやすくなるか、というコンテンツ自身の属性による分類

3.UIモデルの設計

コンテンツの見え方ごとにユーザーが何を見て、どうするのかを整理して、フロー図を作成する

アウトプット：UIフロー図

情報のまとまり単位で、ユーザーが何を見て、どうするかを整理して、線でつないで図示化したもの

4.レイアウト / インタラクションの設計

ペーパープロトタイプでレイアウトとインタラクションを設計する

アウトプット：ペーパープロトタイプ

開発前の段階で、アプリがどのように見え、動作し、機能するのかをシミュレーションしたもの

ちなみに、アウトプットするものは、プロダクトの規模 / フェーズ、チーム / 組織の状況によって変わってくる

結局のところ、中間アウトプットは関係者 / ステークホルダー / 将来の自分 とのコミュニケーションのためのものでしかない

例えば、

プロダクトやチーム、組織の規模が小さいと、中間アウトプットによるコミュニケーションするよりも、対面やチャットでのコミュニケーションのほうが早く、効率的な場合がある

組織の規模の拡大やプロダクトのフェーズの移行に伴って、中間アウトプットによって段階を踏みながら、関係者やステークホルダーと認識をすり合わせたり、将来の自分たちためにドキュメントを残しておくことが、効果的な場合がある

以下では、構造設計のフェーズにおけるアウトプットとそのためのプロセスを中心に紹介していく

hr.icon

ペルソナ

ペルソナとは、アプリの想定ユーザーに対して、インタビュー / 行動観察の結果として導き出されるターゲットユーザー像のことをいう

ユーザーがどのように物事を考え、達成したい目標やそのためにどういった行動を取る人なのか、など

複数の情報を凝縮して削ぎ落とし、一人の架空の人格としてまとめる

そのため、ペルソナは実在する特定の人物ではなく、サービスのターゲットユーザー層を代表する人格である

code:ペルソナに含まれる項目例

顔写真

氏名

性別

年齢

人物像

一日の行動イメージ

欲求

現状の課題

ペルソナは、ターゲットユーザーのもつ価値観や思考パターンなどへの解像度を高め、プロダクト開発に関わるメンバー全体での共通認識とするためにも重要である

こうした共通認識をもとに、サービスの品質を、どのようにユーザーに知覚してほしいかを明確化し、

よりよいアイディアの発想につなげることができる

シナリオ

シナリオは、ペルソナが何ができると目的を達成できるのか、それをどのように実行していくのか、といった目的達成までの道のりを具体化したものである

ユーザーが、について定義する

目的をどのように達成するのか

そのためにどんな要素に強く関心を持ち

どのように操作するのか

アプリ上でどのように振る舞うのか

シナリオを使ってペルソナに動きを与えることで、ペルソナが目的を達成するまでの具体的な行動を理解することができ、そのあとのデザインプロセスを進めやすくする

シナリオを書くときは、実現できるかどうかは考えず、ペルソナが何でも思い通りにできるかのように、自由な発想で書く

目的達成までの様子をできるだけわかりやすく書いていくのがポイント

書いたものを実現する方法は、開発に移った段階で本格的に検討すればいい

価値シナリオ ：抽象度の高いペルソナの欲求から、ユーザーが何をしたいのかを導き出したもの・価値

行動シナリオ ：価値と関連のある具体的なユーザーの行動

操作シナリオ ：行動から落とし込んだ実際にアプリ上で行う操作の流れ

価値シナリオ（バリューシナリオ）

価値シナリオでは、設定したペルソナの欲求に対する価値が、どのようなシーンに関係するのかを書く

ここで書き出されたシーンは、ユーザーがアプリをどのような文脈で使うのか、の仮説設定に役立ち、ユーザーの行動をイメージしやすくする

code:価値シナリオで触れるべき項目

ユーザーの欲求

ユーザーの特徴

ユーザーのやりたいこと（価値）

価値と関連のあるシーン

code:価値シナリオ - 記載例

あとで書く

行動シナリオ（アクティビティシナリオ）

行動シナリオでは、価値シナリオで書き出したシーンをもとに、そのシーンでペルソナが目的を達成するための行動をストーリー仕立てで書く

目標達成までの理想的なストーリーを、以下の点に触れながら、物語のように書いていく

ペルソナの欲求に対する課題や価値を感じたいシーンから

アプリを使った結果、どのように変化して

どうなったから目的を達成できたように感じたのか

次に、書いた行動シナリオをもとに、ペルソナがアプリ上でおこなう必要のあるタスクを抽出する

ユーザーが目的を達成するために、何をするのか、を把握することを意識する

抽出したタスクは、優先度をつけて整理する

例えば、以下のような優先度を設定し、ペルソナの目的と照らし合わせ、アプリの対象スコープを明確にする

A. 必須のもの

B. 必須ではないがあったほうがいいもの

C. 将来はあったほうがいいが、今はやらないもの

code:行動シナリオで触れるべき項目

価値と関連のあるシーン

行動ストーリー

発生するタスク

code:行動シナリオ - 記載例

あとで書く

操作シナリオ（インタラクションシナリオ）

操作シナリオでは、行動シナリオで書き出したタスクをペルソナが実行するために、具体的にアプリ上で行う操作を書く

ここで書き出したものは、ペルソナがアプリ上で実際におこなう操作であるとともに

操作に対するアプリからのフィードバックなどのふるまいにあたる

code: 操作シナリオ　で触れるべき項目

発生するタスク

操作モデル

code:操作シナリオ - 記載例

あとで書く

シナリオを通して、ペルソナの欲求に対する価値から、行動や操作を詳細化し、具体的なタスクに落とし込んでいく

シナリオは、いきなり機能のリストアップからはじめるのではなく

実際の調査結果を確認したり

チームで共有して得られたフィードバックを意識したり

前後の項目を確認しながらすすめていくとよい

シナリオを書くときは、ペルソナから操作モデルまで一方向的に書いていくのではなく、価値シナリオ / 行動シナリオ / 操作シナリオを行き来しながら、ペルソナが目的を達成した様子を想像しやすくなるように書くのがポイント

実装方法やイメージ先行にならないよう注意

※ ここで整理したシナリオは、あくまでペルソナの認知や行動を具体化したもの

より多くのユーザーが持っている目的を達成するための作用や性質を明らかにするためには、シナリオで具体化したものから、抽象と具体を行き来を繰り返してみるといい

これらが、アプリの機能要件やコンテンツ要件につながる

コンテンツ分類軸

ユーザーが達成したい目的や、利用シーンにおいて、必要な情報を見つけやすく、理解しやすくするための要素を抽出して整理する

どのような構造パターンで分類すれば、ユーザーが情報を理解しやすく、探しやすくなるか

シナリオに書かれたペルソナの行動や操作、コンテンツの持つ属性をもとに、コンテンツの分類方法を決める

この分類方法は、ナビゲーションや検索軸などの、ユーザーがコンテンツを探す上でアプリ上で目にするものにつながる

コンテンツ分類軸は、「コンテンツの持つ属性をもとにした分類」と「ユーザーの視点 / 行動をもとにした分類」の2つの観点から検討していく

コンテンツの持つ属性をもとにした分類

そのアプリで関心の対象となるオブジェクトの属性をもとに、分類軸を決める

例えば、「曲」が題材となるアプリの場合、以下のような属性が抽出できる

code:「曲」の属性

曲名

アーティスト名

アルバム名

アルバムアーティスト名

作曲者

曲番

曲の時間

発売年月日

ジャンル

アートワーク

BPM

再生時間

歌詞

ユーザーの視点 / 行動シナリオをもとにした分類

行動シナリオの内容をもとに、以下のような観点から、分類軸を決める

ユーザーがふだんスマートフォンやPCをどれくらい使用しているか

どんなことへの理解が深く、あまり詳しくないことはなにか

そういった知識を他にどれくらい活かせそうか

行動シナリオをもとにして、「曲」を探すときにどのような情報を利用しているかを整理してみる

code:「曲」を探すときに利用する情報

曲名

アーティスト名

アルバム名

歌詞に含まれるフレーズ

使われていたシーンなどの特徴

※ 膨大な情報をまとめる基準は、以下の5つがあるといわれている

code:「LATCH」

Location（場所）：位置情報 ex.地図など

Alphabet（アルファベティカル）：A to Z、あいうえお ex.辞書、連絡帳など

Time（時間）：時間軸、カレンダー、年表 ex.ニュースフィード、Eメールの受信箱など

Category（カテゴリ）：種類、性質による区分 ex.音楽ジャンルなど

Hierarchy（階層）：連続量、順位 ex.番号順、日付順、重さ順など

こうして抽出された分類軸の候補の中から、ユーザーがコンテンツを探すきっかけとなるものを検討する

code:行動シナリオ/操作シナリオから導き出される分類軸

マイライブラリから探す：

登録した曲

登録した曲が含まれるアルバム

登録した曲のアーティスト

検索：

曲名

アルバム名

アーティスト名

歌詞のフレーズ

曲の特徴 ex.使われていた映画など

音声入力 ex.鼻歌など

さらに検索結果 / 一覧画面などで、コンテンツがどのような順序で並ぶといいかを踏まえ、分類軸に反映する

すでにあるアプリやWebサイトを参考に、ユーザーが認識しやすいものを参考にするといい

code:コンテンツの並び順の例

マイライブラリ：

アーティスト：A to Z

アルバム：アルバムアーティスト名のA to Z

曲名：追加順（降順）

検索結果：

同じキーワードで選択されている結果：順位

曲：人気順

アルバム：人気順

アーティスト：人気順

このようなプロセスを経て、情報の構造パターンを選択し、コンテンツ分類軸を決めていく

その際、一度で決めきってしまうよりも、検討結果をプロジェクトメンバーやペルソナに近いユーザーとともに、カードソーティングなどで検証してみるといい

UIモデル

ユーザーが、コンテンツと機能を、どのような手順で操作していけば、目的を達成できるかを考えるため、UIモデルをつくる

整理してきた情報をユーザーにとってわかりやすい形にし、UIデザインのための抽象度の高いモデルをつくる

オブジェクトの抽出

ユーザーがアプリで操作するオブジェクトを抽出する

オブジェクトは、操作シナリオに書き出された、何をどうするのかの「何」を参考にするといい

オブジェクトを特定するときは、ユーザーがアプリで扱うコンテンツの中で、強い関心を持って操作したり、一覧を作成しやすい要素かどうかを手がかりにする

オブジェクトを探す手がかりになるようなものは、オブジェクトの属性 / プロパティとして整理する

何をどうするかの「どうする」は、ユーザーがオブジェクトに対しておこなうアクションとして整理する

フロー図の作成

ユーザーが「何」を見て、「どうする」のかを線でつなぎ、アプリとユーザーのやりとりを視覚的に表現して、UIの流れを整理する

ここでの「何」とは、コンテンツを見つけやすいように分類したカテゴリやコンテンツの属性といった、ユーザーがコンテンツを捉えるために見るものにあたる

「どうする」は、その見えているものに応じてユーザーがおこなうアクションにあたる

code:※画面遷移図とフロー図の違い

フロー図：画面にどう収めるかにとらわれず、ユーザーが目的を達成するために「何」を「どうすれば」いいのかのレベルで整理したもの

画面遷移図：各画面にどんな要素があり、画面それぞれがどのように遷移するのかを可視化したもの

ある程度UIデザインがすすんだ状態で、全体像を把握するために利用する

画面に収められる要素は、アプリを提供するプラットフォームや利用するユーザーの理解度に合わせた表示内容 / 量によって変化する

➡ そのため、この段階で整理する必要はない

情報同士の関係性を捉えやすくなり、ユーザーの目的達成までのタスクを追いやすくなる

画面に収めることにとらわれにくくなったり

必要以上に機能が追加されるのを抑止できる

開発メンバーやステークホルダーとの共通言語となり、コミュニケーションもとりやすくなる

ビューパターンの検討

ユーザーは、アプリ上でコンテンツを、ページやリストといった情報がまとまった形で目にする

コンテンツの見え方のことを、ビューといい、大きく以下の2パターンに分類できる

シングルビュー ：一つの見え方の中に、アプリで扱うオブジェクトを一つ表示する表示（詳細表示）

コレクションビュー ：一つの見え方の中に、アプリで扱うオブジェクトを複数並べるリスト状の表示（一覧表示）

※ 写真やカレンダー、地図上に表示されたピンなども、見え方は異なるがすべてコレクションビュー

ほとんどのアプリでは、こうした見え方を単独または複数組み合わせて構成されている

画面遷移もコレクションビューとシングルビューを行き来する形を取る

シングルビュー / コレクションビューとは別に、ユーザーが操作する状態を示すものとしては以下のパターンがある

対話式の操作、入力フォームなどのタスク支援　ex. 設定画面など

編集などのツール提供　ex. 写真の編集など

UIのモデリング

UIFlowsを拡張し、ビューの種類やビューを構成する要素として見えるもの、見えるものに対してユーザーがおこなえることを表し、UIのモデル / 模型を作成する

抽出したオブジェクトとビューとの関係を意識することがポイント

画面や見た目と切り離して、オブジェクトを具現化し、ユーザーが捉えられる形にする

UIFlowsは、シンプルで情報の構造化がしやすい反面、粒度をコントロールしないと、整理に必要以上の時間がかかる

➡ 見え方の単位で、ユーザーが何を見て、それに応じてどうするのか、という粒度を設定していくといい

ユーザーが見るものを「名詞」、それに応じておこなうアクションを「動詞」で表現するといい

モーダル / モードレス

UIの状態には、モードがある状態（モーダル）とモードのない状態（モードレス）の2つの状態がある

モードとは、ユーザーが特定の操作状態に入り、その操作を完了 or キャンセルするまで、他の操作ができない状態のこと

モーダルの代表的なものとしては、以下のようなものがある

ウィザードのようなリニア型の構造

データを削除する場合などの破壊的な作業を実行する前に確認するダイアログ / アラートメッセージ

モーダルは、ユーザーの操作を限定し、決まったタスクの実行に集中できるようにするといったメリットがある

一方で、ユーザーの行動を制限したり、操作を限定してしまうデメリットがある

また、おこなう操作ごとに、操作対象の画面を用意する必要があるため、画面数が多くなる傾向にある

アプリ内のモードをできるだけ減らすよう意識することで、「何をするか（タスク）」ではなく、「操作する対象（オブジェクト）」を意識しながら、目的を達成でき、結果的にそれが使いやすさにつながる

もし、モードが必要な場合でも、ユーザーに対してどのようなモードなのかをわかりやすく明示し、いつでもモードから出れるような設計にしておけるといい

モードレスでは、わたしたちを取り巻く環境で何かを操作したり、目的を達成するときと同じように、操作する対象を選び、それに対してどのような処理をおこなうか、という手順で操作できる

これによって、ユーザーは思い思いの手順で、目的達成に向けて、操作を実行できていると感じられる

また、操作する対象を先に選んでから、何をするかを決めるため、画面数も少なくできる

基本的には、モードレスで、オブジェクトベースのUIデザインを心がけることで、ユーザーに柔軟な操作性を提供できる

ただし、特定の操作に焦点を絞ったほうがよいと判断した場合には、

目的を持ってモーダルで、タスクベースのUIデザインの導入を検討してもいい

画面構成

ビューごとに整理された情報のまとまりを、ユーザーの理解度やWeb / モバイルなどアプリを提供する環境に合わせて、画面単位に区切っていく

例えば、

PCの場合、画面が大きいたため、複数のビューを組みわせて、画面に広く配置できる

スマートフォンの場合、画面が小さいため、ビューごとに画面を遷移させる必要性がある

※ わかりやすさ / 使いやすさ の正体

「わかりやすい」「使いやすい」というキーワードは、「説明を受けなくても」「直感的な」「慣用的な」と合わせて使われる

つまり、「わかりやすさ」「使いやすさ」とは、わかり方や使い方が決まっていない状態といえる

ユーザーがこれまでの人生や、ふだんの生活でさまざまなものに触れる中で、認知したり、学習してきたことを活かし

ユーザー自身が、自分に合わせて使い方を工夫できるものが、わかりやすく、使いやすいといえる

人間は、初めて使うものに触れるとき、その使い方をこれまでの経験や使い慣れたものに当てはめようとする傾向がある

そうした、人が無意識に持っているモデルを「メンタルモデル」という

そのため、アプリの設計においては、日常手に持つ道具 / ものの見え方 / 位置 / 色のルール / OSのガイドライン / ユーザーのメンタルモデルを踏まえることが重要である

「わかりやすい」「使いやすい」ものは、ユーザーの創造性を高め、ユーザーの日常や仕事を大きく変化させる

ただし、BtoBサービスのアプリの場合、ユーザーの創造性を高めるとともに

本来の業務により集中できるよう、アプリに必要以上に没入させないような設計を心がけることも重要である

プロトタイプ

ここまでに整理してきた、ユーザーの特徴や行動 / アプリで扱うオブジェクトの特徴 / サービスコンセプト を踏まえて、UIモデルに書き出した内容を、画面上にどう表現するかを検討する

プロトタイプには、議論を活性化させ、プロジェクトの成果をよりよいものにすることが求められる

目的としては、良い議論を生み出し、フィードバックを得ること

完成形をつくるわけではないため、ある程度の方向づけをおこなった上で、すばやくアウトプットすることが重要

プロジェクトにかかわるメンバーやステークホルダーが、意見を言い合える環境をつくるファシリテーション能力も重要

プロトタイピングでは、以下のステップを繰り返しながら、具体化と検証をすすめていく

1. プロトタイプの方向づけ

2. プロトタイプの具現化

3. プロトタイプの検証・議論

プロトタイプの方向づけ

プロトタイピングをはじめるにあたって、どういった結果を得るための議論をおこなうのかの方向づけをおこなう

どんなユーザーの課題に向けたものなのか

ユーザーがどのような目的を達成するためのプロトタイプなのか

議論を交わす相手については、細かい表示や実装できるかどうかは気にせず、目的や意図を把握し、同じ目的に対して、別の視点からフィードバックしてくれる人に参加してもらえると、良い議論に発展しやすい

プロトタイプの具現化

意思決定の議論に必要な部分のプロトタイプを作成する

ナビゲーション / レイアウト / インタラクションの観点から、設計を検討していく

ナビゲーションの検討

アプリをどのような構造にして、全体をどのようなナビゲーション構造とするかを検討する

スマートフォンアプリの場合、OSごとにナビゲーション構造に関するガイドラインが準備されているため、これらを参考にする

ナビゲーションは、ユーザーがアプリ上で何を認識し、どのように移動するのか、目的を達成するところまでユーザーをどう連れて行くかを考えながら、複数のパターンを比較できるといい

一つのプロトタイプに対して、複数のナビゲーションパターンで試すのが理想的

ユーザーが目的地に到達するまでに、できるだけ意思決定したと感じさせないようにするのがポイント

もし意思決定の回数が多いようであれば、コンテンツ分類軸（ユーザーがコンテンツを探す方法 / コンテンツのどういった属性で探したいのか）を改めて見直してみるといい

ナビゲーションには、ユーザーがどこにいるのか、をいつでも把握できるようにする役割がある

ユーザーに現在地をわかりやすく伝えるとともに、どちらに行けば、あとどれくらいで目的地に到達するかを示してあげるといい

また、できるだけ移動できる場所を増やさないようにし、ユーザーの現在地や目的地までの道筋を把握しやすいように設計できるといい

※ ドロワーコンポーネント（ハンバーガーメニュー）の採用には、十分な検討が必要です

ドロワーは、ユーザーの現在地や目的地までの道筋を確認するために、メニューを展開する必要があり、ナビゲーションに期待される道標としての機能を果たしているとはいえない

タブバーやボトムナビゲーションに項目が収まらない場合、アプリの目的やコンテンツの分類軸を見直してみて、収められるようにできないかをまず検討してみるといい

レイアウトの検討

ペーパープロトタイプをつかって、手書きでレイアウトを具体化していく

FigmaやSketch、Adobe XDといったデザインツールをつかってワイヤーフレームを描いてもいいが、見た目としての綺麗さ / 線の太さ / フォントサイズ / 要素間の余白 など、細かい部分の調整に時間がかかりがち

本来の目的である、「意思決定の議論のために必要なアウトプットを具現化すること」を意識し、目的に沿わない箇所へのこだわりは捨てるといい

シナリオと照らし合わせながら、どういったレイアウトにすれば、ユーザーは見えているものから、アクションのきっかけを見出し、目的を達成できるかを重点的に考え、精度を高めていく

プロトタイプを実際の端末画面サイズで作成することで、情報の見え方 / 使いやすさ / コンポーネントのサイズ感 の検証にも利用できる

インタラクションの検討

ユーザーのアクションに対して、アプリはどのような反応を返すのか、特にUIFlowsで整理したビューの遷移をどのようにおこなうのか、を設計する

ユーザーの操作とアプリの反応を最適化することで、ユーザーはアプリの「ふるまい」の意図をすばやく理解し、よりかんたんに目的を達成できるようになる

※ マイクロインタラクションは、この段階では検討しなくてもよい

日常で認知しているコンテンツの流れる方向（左から右） / ユーザーがコンテンツを把握しやすい見慣れた体裁 / コンテンツの見え方 / 操作方法を意識し、インタラクションを検討する

ここで重要なのは、あくまでアイディアを具現化して、議論すること

ただただプロセスをなぞることでも、成果物の出来にこだわりすぎることでもない

次のステップへとすすむためには、何が明らかになっているべきかを認識し、それをプロジェクトに関わるメンバーやステークホルダーとともに議論 / 意思決定するために、どういった方法や成果物が必要なのかを考えるといい

プロトタイプの検証・議論

ペーパープロトタイプができあがったら、画面遷移図のように並べたり、紙芝居のように手元で画面を展開してみたり、「POP」や「Prott」などアプリをつかって、スマートフォン上で確認する

開発メンバー / ステークホルダー / ペルソナに近いユーザー などにプロトタイプを試してもらい、フィードバックを得る

得られたフィードバックをもとに、さらにプロトタイプの精度を高めていく