ペルソナとタスクフロー思考：アラン・クーパーのシンプルな方法

なぜ機能リストだけでは良い画面にならないのか

長い機能リストは進捗に見えることがあります。「何を作るか分かっている」と指させます。しかし最初の画面を描こうとすると、そのリストはユーザーが今何をしているのか、今何を終えようとしているのか、アプリが最初に何を見せるべきかを教えてくれないことに気づきます。

機能リストは優先順位を隠します。「通知」「検索」「プロフィール」「設定」はどれも重要そうに聞こえるため、すべてが同じレベルになってしまいます。また意図を隠します。人は「フィルター」や「管理ロール」が欲しいわけではありません。予約を取りたい、支払いを受け取りたい、配達を追いたい、家族と写真を共有したい――そうした具体的な目的があります。

だから機能リスト対ユーザー目標は単なる計画上の議論ではありません。画面を変えます。目標が「金曜のヘアカットを予約する」なら、最初の画面は時間枠と明確な次のステップを見せるべきで、十個の機能メニューではありません。

機能リストはチームをUIの議論に早く引き込みます。ボタンの配置、タブ名、ダークモード、設定ページの数などを議論し始めます。それらは具体的に感じられますが、アプリが誰かを助けるべき仕事に合意する前の推測に過ぎません。

より良い出発点はシンプルです：実在のユーザーを一人選び、その人が一回で終えたい仕事を一つ選び、その仕事を完了する最小のステップをマップする。そうすれば画面は自然に現れます。各画面はフローのステップを支えることで存在意義を得ます。

アラン・クーパーの核となる考え方：特徴ではなく目標に合わせてデザインする

Alan Cooperは、ソフトウェアを機能の集まりとして扱うのをやめ、インタラクションとして扱う転換を普及させました。重要なのはアプリが何をできるかではなく、人が何を成し遂げようとしているか、そしてアプリがそれをいかに摩擦なく助けるかです。

この考え方が現在「Alan Cooperのインタラクションデザイン」と呼ばれるものの中心です。意図と順序に注目してください。旅路を明確に描ければ、画面はほとんど自動的に設計されます。描けなければ、長い機能リストでも救えません。通常、機能は意思決定、ボタン、エッジケースを増やして雑然とさせます。

Cooperの実践的な道具は二つです：

• ペルソナ（誰）： 特定のユーザー像を選び、その人が何をするか予測できる程度に現実味を持たせる。
• タスクフロー（どうやって）： そのペルソナを意図から成果へ導く最小のステップをマップする。

フローは、機能リストが避ける問いに答えさせます：何がタスクをトリガーするのか、何が「成功」か、ユーザーが今すぐ決めるべきことは何か、そのステップで本当に必要な情報は何か。

仮にチャットベースのvibe-codingプラットフォームのようなKoder.aiで作る場合でも、この明確さは必要です。さもないと、もっともらしく見えるが満足のいく開始から終了までの体験につながらない画面が大量に生成されてしまいます。

ペルソナ：まず一人の現実的なユーザーを選ぶ

ペルソナは、最初にデザインする相手を短く信じられる形で描写したものです。完全な伝記ではありません。決断を保留して「状況による」と繰り返す必要がない程度の詳細で十分です。

最初はゴールとコンテキストに注目してください。デモグラフィックではありません。同じ「忙しい親」でも、どこにいるか、どのデバイスを使っているか、どれだけ時間に追われているかで行動は変わります。プロダクトデザインにおける良いペルソナはそれらの制約を具体化し、画面に明確な目的を与えます。

ペルソナが曖昧だとそれが伝わります。「みんな」が対象になり、主にデモグラフィックだけになり、はっきりした目標を示さない好みのリストになり、その人が今日アプリを使う理由を説明できなくなります。

ペルソナは軽く保ってください。数行で十分です：

• 彼らが誰か（役割）
• いつどこでアプリを使うか（コンテキスト）
• 最優先のゴール（分かりやすい言葉で）
• 今日何が行動を遅らせているか（痛点）
• 「成功」は何か（シンプルでテスト可能な勝ち）

例：「Mina、歯科受付。患者の合間にスマホで使う。彼女の目標は翌日の予約を素早く確認すること。痛点は返信が来ない人を追いかけること。成功はリマインダーを送って1分以内に『確認済み』のステータスが見えること。」

もう一つのルール：ペルソナはマーケティングの理想顧客プロファイルではなく設計ツールです。後で多くの対象を持つのは構いませんが、今は一人の主要ペルソナが必要です。画面について議論が出たらMinaに立ち戻ってください：これは彼女が現実の状況で目標を達成するのに役立つか、それともただの別の機能か？

タスクフロー：重要なステップをマップする

タスクフローは、ペルソナが一つの明確なゴールに到達するための最小限のステップです。サイトマップではなく、機能一覧でもなく、全体のジャーニーマップでもありません。「Xをしたい」から「Xが完了した」までの一つの道筋です。

良いフローはトリガーで始まり成功状態で終わります。トリガーはユーザーが始める理由：必要性、メッセージ、ボタン、問題など。成功状態は平易な言葉で書ける「完了」が何か：「予約が入って確認された」「請求書が送られた」「パスワードが変更されてログインできた」など。両方を各一文で説明できなければ、フローはまだあいまいです。

開始、終了、そしてその間の判断

ほとんどのフローは判断が現れるまで単純です。判断は次に何が起きるかを変える分岐点で、「既にアカウントを持っていますか？」「このアイテムは在庫がありますか？」のようなものです。早めにそれらの分岐点を明示することで、現実が現れた瞬間に壊れる完璧なハッピーパスを設計するのを防げます。

フローを形作るために、次の五つの質問に答えてください：

• 何がタスクを始めるのか？
• 単一の成功の瞬間は何か？
• 必要な情報は何（任意の情報は何か）？
• どんな判断が経路を変えるか？
• 何がうまくいかないか、うまくいかなかったときにユーザーに何を見せるべきか？

ユーザーが安心を必要とする箇所

人は不確かだとタスクを放棄します。フローには安心が必要な瞬間をマーキングしてください：進行状況、状態、確認、明確なエラー。

簡単な例は「パスワードをリセットする」です。トリガー：「ログインできない」。成功：「アカウントに戻れた」。判断：「メールにアクセスできますか？」安心ポイント：「メール送信済み」「リンクの有効期限切れ」「パスワード変更済み」「ログイン完了」。これらを書き出せば、各ステップにそれが起きる場所と疑念を取り除くメッセージが必要だと画面が明確になります。

軽量な方法：ぼんやりしたアイデアを明確な最初のフローにする

多くのアプリのアイデアは名詞の山から始まります：ダッシュボード、チャット、カレンダー、支払い。明確化への速い道は、アイデアを約束（promise）、人、ステップの順に無理やり当てはめることです。

まず、フロントページに載せられるような一文を書いてください。誰かが頷くか「それは自分じゃない」と言えるくらい具体にします。例：「フリーランスのデザイナーが2分以内にきれいな請求書を送ってカード支払いを受け取り、より早く支払われるようにする。」

次にバージョン1の主要なペルソナを一人選びます。「みんな」でも「小規模事業者」でもなく、普通の火曜日に想像できる人です。三人同時にデザインすると余計な画面が増えて誰の役にも立たなくなります。

次に、最初にデザインする一つのゴールを選びます。価値を生む主要なものが望ましい。「整理された気分になる」は曖昧です。「請求書を送ってそれが見られたか確認する」は明確です。

繰り返し可能なプロセスはこうなります：

1. 一文の約束を書く（誰＋成果＋時間/労力）
2. 主要ペルソナと一つの制約（時間、デバイス、スキル）を定義する
3. ハッピーパスを短い動詞で草案する（選ぶ、入力する、確認する、確定する、支払う）
4. フローが壊れないように現実的な失敗を2–3個追加する

フローが1ページに収まってから機能リストを書いてください。短く優先順位付けします：ステップを可能にするための少数の機能と、失敗から回復するために最低限必要なものだけ。

Koder.aiのようなビルドツールを使うなら、ここでplanning modeが役立ちます。約束、ペルソナ、フローを一箇所に貼ってチームを整列させ、画面とコードが増える前に合意を作ってください。

フローを画面とアクションに変換する（UIを詮索しすぎないで）

タスクフローは意図の連続です。今、各ステップを画面にするか、その画面上の単一アクションに変えます。

単純に考えてください：一つのステップは一つの明確な成果に等しい。もし一つのステップで二つの成果があるなら、それは通常二つのステップです。

画面はレイアウトではなく目的で命名します。「時間を選ぶ」は「カレンダー画面」より良い。「詳細を確認」は「フォームページ」より良い。目的名は画面が何をするべきかに集中させます。

フローを画面に置き換えるときは、各ステップについて三つを決めます：ユーザーが何を見なければならないか、何を選ばなければならないか、何を入力しなければならないか。そして次の明らかなアクション（通常は主要ボタン）を選びます。それ以外の要素は削ぎ落としてください。

ナビゲーションは退屈でよい。各画面は「次に何をすればいいか」を答えるべきです。メニューが必要で次の動きを探すようなら、その画面はやりすぎです。

また基本的な状態はメモとしてキャプチャしてください：読み込み、空、成功、エラー、主要アクションが無効になるタイミングなど。チームが状態を忘れずに作れる程度のメモで、色や細かい議論に日数を費やす必要はありません。

Koder.aiのようなツールはフローテキストから画面案を作るのを手伝えますが、明確さはあなた次第です：目的、必要情報、次のアクションを定めてください。

例：『予約アプリ』を一貫した画面群にする

たとえば、ローカルのクラス（ヨガ、チュータリング、ヘアカット）の予約をするシンプルなアプリを作りたいとします。機能リストは「検索、カレンダー、支払い、リマインダー」と言うかもしれませんが、それでも最初の画面が何か、誰かが「予約」ボタンを押した後に何が起きるかは示しません。

まず一人のペルソナ：Sam、駐車場でスマホを使う忙しい親で、60秒以内に席を確保したい。アカウントを作りたくない、20の選択肢を比較したくない、長い説明文を読みたくない。

次にハッピーパスを短い物語にします：Samはアプリを開き、すぐに目的のクラスを見つけ、時間を選び、名前を入力し、支払いをして、明確な確認を受け取る。

二つのエッジケースを足します：Samが時間をタップした瞬間にクラスが売り切れる、支払いが失敗する。

そのフローから導かれる画面は明快です：

• クラスを探す： 近隣／近日の選択肢を日付/時間フィルターつきで表示。カードにタイトル、開始時間、価格、残り枠を明示。
• クラス詳細： 次に利用できる時間を上に、所要時間や会場などの基本情報、主要アクションは「時間を選ぶ」。
• 時間を選ぶ： 空きスロット、売り切れラベル、日付切替の簡単な操作。
• あなたの詳細： 名前や（必要なら）領収送信用の連絡先1〜2項目と続行ボタン。
• 支払い： 合計金額、支払い方法、単一の支払ボタン。
• 確認： 予約詳細と次のアクション（カレンダーに追加、予約を見るなど）。

「売り切れ」が起きたら時間選択内で処理します：素直に説明し、近い次のスロットを提案し、Samを同じ画面に留めます。支払いが失敗したら入力済みの詳細は保持し、普通の言葉で何が起きたかを伝え、「再試行」と「別の方法を使う」を提示します。

Koder.aiでこれを作るなら、フローテキストからこれらの画面を生成し、文言と入力項目を調整して60秒の目標が現実的に感じられるまで繰り返します。

フローが壊れる一般的な罠

フローが壊れる主な理由は一つ：群衆向けに設計していることです。ペルソナが「みんな」だと、すべての決定が妥協になります。あるユーザーは速度を望み、別のユーザーは案内を望み、別の人は完全な制御を望む。結果としてフローは満たせなくなります。

対策はペルソナを絞ることです。「忙しい専門職」ではなく「電話の合間に予約を取る受付担当」や「ひび割れた画面で子どものヘアカットを予約する親」など、その日の様子を想像できるくらい具体にします。そうすれば削るべきものが明らかになります。

別の失敗モードは、保存できるデータから設計を始めることです。最初の草案がデータベースのフィールドや内部の管理手順に基づくと、プロダクトは長いフォームになり、主なタスクが埋もれます。人は「フィールドを埋める」ために目覚めるわけではありません。確認する、支払う、リマインドを受け取るために使います。

三つ目の罠は「まず余計な機能」思考です。設定、好み、ロール、タグ、カスタマイズはリストにしやすく、早く侵入してきます。しかし核となるタスクが弱いと、余計な機能は経路と混乱を増やすだけです。

Koder.aiのようなツールで画面を素早く生成する場合も同じリスクがあります：速度はフローが正直である限り有用です。一人のペルソナ、一つのゴール、各画面での明確な次のステップを守ってください。

ビルドを始める前の簡単チェックリスト

デザインツールを開くかコーディングを始める前に、あなたのアイデアが実際に完了できる画面に変わるかを一通り確認してください。

主要ペルソナのゴールを一文で、明確な終着点とともに言えるべきです：「土曜11時にヘアカットを予約して確認を受け取る」など。ハッピーパスが1ページに収まるべきです。広がるなら、二つのタスクを混ぜたか複数のペルソナを同時に解決しようとしている可能性があります。

各画面が目的で命名され、フローステップに紐づいているかを確認してください（目的はウィジェットより重要）。決定と確認を暗黙にせず明示してください。ユーザーが何かを選ぶ必要があるならその選択を見せる。重要なことが起きたら確認か明確なエラーを見せる。

それからタスクを前に進めないものはすべて削ってください。画面が判断、入力、支払い、確認のいずれかを助けないなら、最初のバージョンでは大抵ノイズです。

フローを声に出して読んでみてください：「私はXをしたい、Aをする、次にBをする、確認して完了する」。つまずく箇所があれば、そこが設計上の問題です。

Koder.aiを使う場合、これは強力なプロンプトの出発点にもなります：一文のゴールとハッピーパスのステップを貼り付け、最小の画面とアクションを要求してください。

次のステップ：最初のバージョンを計画してビルドへ移る

主要なペルソナがゴールに到達できることを最もよく証明する単一のフローを選んでください。それを脊柱（spine）として扱います。それが動くまで他はオプションです。

そのフローを小さなビルド計画に変換します：ペルソナが訪れる数枚の画面、各画面で行うアクション、システムが最低限知っているべきデータ、扱うべき短い失敗ケースのリスト、そして「完了」を示す成功状態。

次に何を切るかを決めます。削ることは単に最小主義のためではなく、一つの主要ゴールを楽にするためです。機能が今日ペルソナのフロー完了に役立たないなら、それは「後で」に回します。

計画を検証するにはそれを演じてみてください。ペルソナの説明を読み、その人になりきってステップを辿ります。足りない情報はすぐに表れます：日付はどこから来たのか？選択をどう変えるのか？間違えたらどうなるか？

早く進めたいなら、planning modeでペルソナとフローをチャットで反復してから画面を生成してください。ビルドを始めたら、snapshotやrollbackを活用して「小さな変更」が経路を壊したときに素早く戻せるようにします。