画面を紙とふせんで描く：ノーコード初心者の画面設計と遷移の整理

先に知っておくこと：紙の「画面」とツールの単位はずれる

紙に描く「画面」と、ノーコードツール上の部品の単位は、完全には一致しません。たとえばBubbleのマニュアルでは、ページをWebアプリの画面を載せる白紙のキャンバスと説明しています。各ページにはURLが付き、別のページへはワークフローの「Go to page」アクションやリンクで移動します。

一方、Bubbleには1つのページの中で表示と非表示を切り替えて、画面が変わったように見せる単一ページ(SPA)の作り方もあります。同じマニュアルは、数百から数千の要素やワークフローを含む複雑なSPAでは、初回の読み込みが遅くなりうることや、よく使う機能は1ページに集め、あまり使わない機能は別ページに分ける構成例にも触れています。

ここから分かる通り、紙の上で「画面」を決めても、ツールでそれを「ページ」にするか「表示の切り替え」にするかは別の判断です。紙の段階では、その判断を気にしなくて構いません。決めるのは「利用者にとって、いくつの場面があるか」だけです。ツールごとの呼び名や上限は変わることがあるので、実際に使うツールの公式ドキュメントで確認してください。

手順1：やりたいことを動詞でふせんに書く

ふせん1枚に1つ、利用者がやりたいことを「〜する」の形で書きます。ここでは色を決めて、ピンクを「やること」とします。

説明用の例として、友人同士でボードゲームを貸し借りする記録アプリを考えます。

• 貸し出し中のゲームを見る
• 貸したゲームを登録する
• 登録内容を直す
• 返してもらったことを記録する
• 過去の貸し借りを見返す

画面の名前や見た目はまだ考えません。「ボタンを置く」のような作る側の言葉も使わず、利用者の目的だけを書きます。

手順2：ふせんを画面にまとめる

次に、ピンクのふせんを机の上で近いもの同士に寄せます。まとまり1つが画面の候補です。迷ったときは、下の判断表で扱いを決めます。

• 目的が違い、見る情報も違う、扱い：別の画面にする、例：一覧と履歴
• 目的が同じで、入力項目も同じ、扱い：1つの画面を使い回す、例：新規登録と編集
• 押すだけで終わり、新しい情報を見せない、扱い：画面にせず、ボタンの動作にする、例：返却済みにする
• 確認の一言だけ出したい、扱い：画面にせず、確認メッセージにする、例：削除してよいか

この表は編集上の目安です。例のアプリでは「登録内容を直す」と「貸したゲームを登録する」を同じフォームにまとめ、「返してもらったことを記録する」は詳細画面のボタンに回します。

手順3：画面一覧表を書く

まとめた結果を、紙に次の表の形で書き出します。画面の数は、この表の行数です。

説明用の例：画面一覧

• S1、画面名：貸出中一覧、目的(1行)：今貸しているゲームを見る、載せる情報：ゲーム名、借りた人、貸した日、主な操作：行を選ぶ、追加する
• S2、画面名：詳細、目的(1行)：1件の内容を確認し、返却を記録する、載せる情報：上記に加えメモ、返却予定日、主な操作：編集する、返却済みにする
• S3、画面名：登録フォーム、目的(1行)：新規登録と編集を行う、載せる情報：ゲーム名、借りた人、貸した日、メモ、主な操作：保存する、やめる
• S4、画面名：履歴、目的(1行)：過去の貸し借りを見返す、載せる情報：ゲーム名、借りた人、返却日、主な操作：行を選ぶ

「目的」が1行で書けない画面は、2つの目的を抱えている可能性が高いです。その場合は分けることを検討します。逆に、目的がほぼ同じ画面が2つあるなら、まとめられないか考えます。初めてのアプリなら、画面は3〜5個程度に収めると完成まで進みやすいです。

手順4：遷移表を書く

画面ごとに、「どの操作で、どこへ行くか」を1行ずつ書きます。戻り方まで書くのが重要です。ここが抜けると、ツールで作ったときに行き止まりの画面ができやすくなります。

説明用の例：遷移表

• S1、きっかけ：「追加」を押す、行き先：S3(新規)、戻り方・補足：保存後はS1に戻る
• S1、きっかけ：行を選ぶ、行き先：S2、戻り方・補足：「戻る」でS1
• S2、きっかけ：「編集」を押す、行き先：S3(編集)、戻り方・補足：保存後はS2に戻る
• S2、きっかけ：「返却済みにする」を押す、行き先：S1、戻り方・補足：画面は増やさず状態だけ変更。履歴に移る
• S3、きっかけ：「やめる」を押す、行き先：直前の画面、戻り方・補足：入力内容は保存しない
• 共通メニュー、きっかけ：「貸出中」「履歴」を選ぶ、行き先：S1 / S4、戻り方・補足：どの画面からでも行ける
• S4、きっかけ：行を選ぶ、行き先：S2、戻り方・補足：「戻る」でS4

共通メニュー(画面の下や横に常に出る切り替え)は、毎回すべての画面から矢印を引くと紙が見づらくなります。そこで表では1行にまとめ、「どの画面からでも行ける」と書きます。

手順5：ふせんを紙に並べて、指でたどる

画面ごとに1枚ずつふせんを貼り、矢印を描いて配置します。画面ふせんは黄色、共通メニューは青など、色で役割を分けます。

説明用の例：ふせん配置

[共通メニュー(青): 貸出中 | 履歴]
        │             │
        ▼             ▼
   ┌─────────┐   ┌─────────┐
   │S1 貸出中一覧│   │S4 履歴     │
   └──┬──▲───┘   └───┬─────┘
 追加 │  │保存後/戻る     │行を選ぶ
      ▼  │               ▼
   ┌──┴──────┐◀────────┘
   │S3 登録フォーム│   (S1・S4の行 → S2)
   └──▲──────┘
      │編集 / 保存後
   ┌──┴──────┐
   │S2 詳細     │
   └─────────┘

罫線の細部にこだわる必要はありません。大事なのは、全部の画面から次の行き先が1つ以上あり、各画面から戻れることです。

配置したら、次の3つのシナリオを、指で矢印をなぞって確認します。

1. 新しいゲームを貸した記録を付ける
2. 返してもらった記録を付ける
3. 先月貸した相手を履歴から探す

指が止まった場所、戻る道がない場所、同じ矢印が何本も交差している場所は、設計の穴です。ふせんを動かしたり、画面を減らしたりして直します。

AIに手伝ってもらう場合の任せ方

AIは、書き出した内容の抜け漏れチェックや表の整形に向いています。ただし、「何を作りたいか」の判断は人が持ち、AIには材料を渡して点検してもらう使い方が安全です。

AIに渡す情報: アプリの目的(1〜2文)、想定する利用者、手順1のやることリスト、手順3・4の表。実在する人の名前や社内の情報は、説明用のダミーに置き換えてから貼ります。

依頼文の例(そのまま使えます):

次のアプリの画面設計を点検してください。ノーコードツールで作る予定で、
利用者はプログラミング未経験です。

【目的】友人同士のボードゲーム貸し借りを記録する
【やりたいこと】(ここに手順1のリストを貼る)
【画面一覧】(ここに表を貼る)
【遷移表】(ここに表を貼る)

次の点を指摘してください。
1. 行き止まりの画面、戻れない画面
2. 目的が2つ以上ある画面、目的が重複する画面
3. やりたいことのうち、どの画面でも実現できないもの
4. 画面数を減らせる案(理由つき)
修正案は、元の表と同じ形式で示してください。

人が確認すること:

• AIの指摘が、本当に自分のアプリの目的に必要か。画面を増やす提案は、そのまま採用しません。
• 修正後の表を、手順5のシナリオでもう一度なぞれるか。
• 提案が使うツールの機能で実現できるか。AIの回答はツール固有の仕様を取り違えることがあるため、公式ドキュメントで確かめます。

紙が完成したら、ツールに持ち込む前に見る3点

• 画面一覧の行数と、遷移表で行き先に出てくる画面が一致しているか。
• 各画面に載せる情報が、データの項目(表の列)として挙げられているか。
• 「画面」を、ツール上でページにするか、同じページ内の切り替えにするか。Bubbleなら前述の2通りがあり、他のツールでは使う機能の名前と上限を公式ドキュメントで調べます。

ここまで決まれば、ツールを開いたときに迷うのは「どの部品でどう作るか」だけになります。画面の数や移動の流れで迷ったら、またこの紙に戻ってふせんを動かしてください。