※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

Figmaで画面を作れたら、次は「利用者が迷わず次へ進めるか」を確かめたくなりますよね。プロトタイプは、画面をつないで操作の流れを試すための仕組みです。ボタンを押す、詳細を見る、一覧へ戻るといった動きを再現し、静止画だけでは見つけにくい問題を探せます。

最初から実際のアプリと同じ機能を全部作る必要はありません。まず一つの目的に絞り、開始画面から到達点までつなぎ、必要な戻り道を作ります。そのうえで、スクロール、重ねて表示する案内、第三者による操作テストへ広げると、何のために動きを付けるのかを見失いにくくなります。

この記事では、架空の体験イベントを選ぶ画面を練習例として、Figma Designのプロトタイプを作る手順と確認の観点を説明します。2026年10月3日に公式資料を確認しました。画面位置や使える共有機能は、更新・プラン・権限によって変わります。本文のシナリオと記録票は自作の仮定例、図版は説明用の生成イメージです。

目次
  1. Figmaプロトタイプで確かめること|目的とテスト範囲を決める
  2. 画面と接続を作る|開始点・トリガー・遷移を組み立てる
  3. スクロールとオーバーレイ|画面の動きを必要な範囲で再現する
  4. 操作テストを進める|案内・観察・修正を分けて記録する
  5. 共有と引き継ぎ|権限・動かない接続・未実装部分を確認する

Figmaプロトタイプで確かめること|目的とテスト範囲を決める

試す目的を一つ決めるを説明する生成イメージ

何を確認するための試作なのかを一文にする

プロトタイプの目的を「動くものを作る」にすると、アニメーションを増やす作業に時間を使いがちです。まず、「初めて来た人が参加日を見つけ、選んだイベントの内容を確認できるか」のように、調べたいことを一文にしてください。見るべき画面と操作が絞れます。

この練習では、一覧から一つのイベントを選び、詳細で日時を確認し、確認画面へ進む流れを作ります。支払い、会員登録、実際の予約送信は対象外です。作らない機能も決めておけば、どこまでできれば今回の試作が完成なのか判断できます。

見た目の好みを相談したい場合と、次に押す場所が分かるかを調べたい場合では、試作の内容が変わります。前者は静止画でも確認できることがあります。動きを付ける理由がある箇所へ集中すると、作業量を抑えながら、必要な発見を得やすくなります。

ワイヤーフレーム・デザイン・実装との関係を整理する

ワイヤーフレームは情報の構造や配置を考えるために使い、デザインは色・文字・写真などを含めて見た目を具体化します。プロトタイプは、その画面同士の関係や操作を試す役割を持ちます。実務では範囲が重なることもあるため、呼び方だけで完成度を判断しないでください。

まだ配色が決まっていなくても、主要な操作の流れは試せます。反対に、完成に近い見た目でも、ボタンがつながっていなければ一連の操作を確認できません。「画面は仮の色だが、イベントを選んで戻る流れは試せる」と、今回の状態を説明しましょう。

Figmaのプロトタイプで動いたことは、そのまま本番のWebサイトで動作する証明ではありません。データ保存、認証、送信、キーボード操作、支援技術への対応などは、実装後の確認も必要です。試作で分かったことと、実際の製品で確かめることを分けて残します。

※表は横にスクロールできます。

確認したいこと今回作るもの今回作らなくてよいもの結果の残し方
イベントを探せるか一覧と詳細のつながり全イベントの実データどの情報を手掛かりにしたか
日時が伝わるか詳細の日時・場所予約システムとの連携迷った表示と読んだ順序
選び直せるか詳細から一覧への戻り道すべての検索条件戻った後の位置と行動
補足を読めるか持ち物の案内と閉じる操作多数の補足画面開けたか・閉じられたか
申込み内容を理解できるか見本の確認画面実送信・支払い理解した内容と未確認点

操作する人の状況を仮定する

対象者の想定がないと、作り手が知っている言葉や順番に合わせてしまいます。練習では、「初めてサイトを見た人が、週末の体験イベントを探している」とします。専門用語や過去の利用経験を前提にせず、画面の情報だけで選べるかを見ます。

課題の文は、押すボタンの名前を直接教えないようにします。「詳細ボタンを押してください」では、ボタンが見つかるかを調べにくくなります。「参加できそうな週末のイベントを探し、開催場所を確認してください」と伝えれば、相手がどの情報を手掛かりにするかを観察できます。

ただし、仮定した対象者一人の結果から、すべての利用者に使いやすいと断定はできません。最初のテストは、問題候補を見つけるための小さな確認です。利用者層や端末が違えば、別の確認が必要になることも記録しておきましょう。

必要な画面と状態を紙で数える

操作の順番を紙に書き、必要な画面を数えます。一覧、詳細、確認という三画面に、閉じられる補足案内を一つ加える程度なら、初心者でも全体を把握しやすくなります。画面を増やす前に、どの疑問に答えるための追加なのかを確認します。

通常の流れだけでなく、選び直したい場合の戻り先も考えます。詳細を見て条件が合わなかった人は、一覧へ戻って別の候補を選ぶはずです。前へ進む矢印だけで完成とせず、戻る・閉じる・やめる操作も、今回のテストに必要な範囲で用意します。

入力を再現する場合は、実データを使わず、架空の名前や連絡先などを使います。練習で個人情報を入力させる必要はありません。入力後の見本画面へ進む方式でも、確認したい情報の順番や文言を調べる目的には役立つことがあります。

画面と接続を作る|開始点・トリガー・遷移を組み立てる

開始点と遷移をつなぐを説明する生成イメージ

一画面を一つのフレームとして準備する

まず、一覧・詳細・確認を、それぞれ分かる名前のフレームに用意します。端末に近い縦横比を選び、同じ流れの中では基準の幅をそろえると比較しやすくなります。画面名を「Frame 1」のままにせず、「Event list」「Event detail」など役割が分かる名前にします。

ボタンや文字が正しいフレームの中に入っているか、レイヤー階層で確認してください。見た目では画面の上に乗っていても、階層では外側にあることがあります。スクロールや接続を調べる際に混乱するので、最初に親子関係を整えます。

練習用の写真や文章は、判断に必要な情報だけを入れます。大量の素材を用意するより、日時、場所、対象者、次の行動が読み取れることを優先します。権利が確認できない素材や、顧客の未公開資料を練習用の共有ファイルへ入れないでください。

開始点を決め、最初の接続を作る

Prototypeの設定を開き、一覧画面を流れの開始点にします。画面上の操作対象を選び、接続を行き先のフレームへつなぎます。最初は、一覧の一つのイベントから詳細画面へ移る接続だけを作り、再生して動作を確かめましょう。

Figma公式のプロトタイピングガイドでは、開始点、フロー、接続、操作対象などの用語と基本が説明されています。接続の線をたくさん引く前に、一本について「どこから、何をきっかけに、どこへ行くか」を説明できるようにします。

同じファイルに複数の試作がある場合は、開始点の名前を用途に合わせます。「体験イベントを選ぶ」「申込み内容を確認する」のように目的で名付けると、見る人が自分の確認対象を選びやすくなります。古い試作の開始点が残っていないかも確認してください。

トリガー・アクション・行き先を別々に確認する

トリガーは動作のきっかけ、アクションは何をするか、行き先はどの画面へ進むかです。クリックをきっかけに別フレームへ移動する、クリックをきっかけに案内を重ねて開く、といった組み合わせになります。動かないときも三つを分けて見ると調べやすくなります。

ボタンを押したいのに、ポインターを重ねただけで遷移するなら、きっかけの設定が想定と違うかもしれません。詳細へ進みたいのに別の画面へ行くなら、行き先を確認します。すべてを削除して作り直す前に、どの項目が意図と違うかを探しましょう。

操作対象の範囲にも注意します。文字だけが押せるのか、ボタン全体が押せるのかでは使い心地が違います。大きな透明要素が上に重なって操作を遮っていないかも確認します。画面の見た目とクリックを受ける場所が一致しているかが大切です。

※表は横にスクロールできます。

要素決める内容練習例誤りを探す視点
開始点どこから流れを始めるかイベント一覧古い開始点ではないか
操作対象どこを押すか一覧のイベントカード上のレイヤーが遮っていないか
トリガー何をきっかけにするかクリック・タップ意図しないホバーではないか
アクション何を行うか詳細画面へ移動オーバーレイと混同していないか
行き先どこへ進むか選んだイベントの詳細別案のフレームではないか
戻り道選び直しをどう扱うか一覧へ戻る入ってきた経路で結果が違わないか

戻る操作は、どこへ戻すかを決めてから設定する

詳細画面には、一覧へ戻る操作を用意します。常に指定した一覧へ戻すのか、直前の画面へ戻すのかで、考える動作が変わります。試作の流れに合わせて選び、想定している経路から操作したときに期待どおりかを確認します。

複数の入口から同じ詳細へ来る場合は、「戻る」の意味が曖昧になりやすくなります。たとえばおすすめ一覧と検索結果から同じ詳細へ進む設計なら、それぞれの入口で戻った結果を見ます。練習の範囲を広げないなら、今回は一つの入口だけを作ったと明記して構いません。

確認画面まで進んだ後も、選び直しの経路を試してください。作り手は正解の道を知っているので、最後まで進めることだけを確認しがちです。間違えた、条件が合わない、もう一度読みたいという行動に対し、利用者が行き止まりにならないかを見ます。

一本ずつ再生し、最後に通しで確認する

接続を追加するたびに、その接続を再生して確認します。一本ずつなら、問題が起きた直前の変更を把握しやすくなります。すべての画面をつないでから初めて再生すると、どの接続が原因か探す時間が増えます。

Figmaには編集画面内で試すプレビューと、別の表示で見せるプレゼンテーションがあります。公式のプロトタイプ再生ガイドで役割を確認し、制作中の小さな確認と、共有前の通し確認を使い分けましょう。

最後は開始点へ戻し、一覧から確認まで、次に確認から一覧まで進みます。途中の画面からだけ試すと、入口の設定ミスを見落とすことがあります。送る予定のリンクから開き直して試すところまで含めると、相手の体験に近づけられます。

スクロールとオーバーレイ|画面の動きを必要な範囲で再現する

スクロールと重なりを説明する生成イメージ

スクロールは、見える枠より内容が長い状態で作る

長い詳細ページを試すなら、画面として見えるフレームの範囲と、その中に入る内容の長さを分けて考えます。内容がすべて枠内に収まっていれば、縦スクロールを設定しても、動かす余地がありません。まず内容が枠の外まで続く状態になっているかを確認します。

さらに、その内容が対象フレームの子要素になっているかを見ます。下に並んでいるように見えても、別の階層にあれば、想定するスクロール対象になりません。表示領域と内容の関係を、見た目とレイヤーの両方で確認してください。

Figma公式のスクロールとオーバーフローの説明には、内容の準備、方向、内部要素の位置の設定がまとまっています。本記事の課題では縦方向だけから始め、横方向や複雑な入れ子は必要になってから追加します。

固定する要素は、本文を隠さないかも確認する

上部の案内や下部の操作ボタンを固定すると、長いページでも操作しやすくなる場合があります。ただし、固定要素が大きすぎると、読むための領域が狭くなります。配置しただけで便利になったと判断せず、短い画面でも本文の重要な情報が見えるか確認します。

固定と、一定位置に来たら止まるStickyでは挙動が異なります。設定できる条件や親フレームとの関係もあるため、現在の公式案内と階層を確認してください。オートレイアウト内の要素など、配置条件によって想定した設定が使えない場合もあります。

練習では、詳細ページの下へ進みながら、イベント日時と参加ボタンの両方を確認します。固定ボタンのために注意事項が隠れるなら、余白、配置、固定の必要性を見直します。見せたい要素を残すことと、ほかの情報を邪魔しないことを一緒に考えましょう。

※表は横にスクロールできます。

動き構造の準備確認する体験見落としやすい点
縦スクロール枠より長い内容を子要素にする下部の日時や注意事項が読めるフレームだけ縦長にしている
横スクロール横方向へ続く内容と対象枠必要な候補に移動できる縦操作と競合する意図不明な配置
固定要素親フレームと配置条件を確認操作を残して本文も読める重要な情報を覆っている
Sticky親の範囲と重なりを確認途中から残る案内の見え方親の外まで残ると誤解する
オーバーレイ補足用フレームと開閉の接続読んで元の作業に戻れる開けるが閉じられない
戻った後の位置保持・リセットの意図を決める選んでいた候補を再び探せる遷移だけで完了にする

補足案内はオーバーレイで表現できる

今の画面を残したまま、注意事項や補足説明を上に表示したい場合は、オーバーレイが候補になります。練習では「持ち物を見る」を押すと補足カードを開く形にします。別ページへ移動させたい情報なのか、今の画面の文脈で見せたい情報なのかを考えて選びます。

補足用のフレームを作り、操作対象から接続し、Open overlayなど目的に合うアクションを設定します。位置、背後の見え方、外側を押したときに閉じるかなどを確認します。Figma公式のオーバーレイ作成ガイドに、設定項目と再利用時の扱いが説明されています。

開く操作だけでなく、閉じる操作を必ず試してください。外側を押す方法だけに頼ると、閉じ方が分からない人がいるかもしれません。画面に閉じる操作を見せるか、どの動作を今回のテストで想定するかを決め、補足を読んだ後に元の作業へ戻れることを確認します。

動きの演出は、検証の邪魔をしない範囲にする

画面が滑らかに変わると完成度が高く見えますが、演出を増やした分だけ、接続や状態の確認も増えます。最初は単純な切り替えで流れを確かめ、動きそのものを評価したい場面だけ調整する方が、問題を切り分けやすくなります。

たとえば、イベント選択の意味を調べたいときに長い演出を入れると、参加者が待ち時間に気を取られることがあります。見た目の演出が原因なのか、情報の順序が原因なのか分からなくなるため、今回の目的に必要な動きかを判断してください。

また、プロトタイプで再現したアニメーションが、そのまま実装の負荷や実端末の性能を示すわけではありません。動きの意図、始まる条件、終わった後の状態を記録し、実装時に確認すべき点として引き継ぎます。

スクロール位置と再開位置を試す

一覧を下へスクロールしてから詳細へ進み、戻ったときにどの位置になるかを確認します。利用者は、さっき見ていた候補の近くへ戻りたいかもしれません。画面の切り替えが動くことだけでなく、戻った後に探し直す負担がないかを見ます。

スクロール位置の保持やリセットなど、状態の扱いには設定があります。必要な挙動を決めてから公式の案内で確認してください。学習の初回は、保持の高度な設定まで作り込まず、「今回は先頭へ戻る試作である」と説明して、未確認の点を残す方法でも構いません。

再生の途中状態が残っていると、次の参加者の開始条件が変わる場合があります。テスト前に開始点へ戻し、同じ条件から試せるかを確認します。作業を再開したときも、どのフローをどこから再生しているかを最初に確かめましょう。

操作テストを進める|案内・観察・修正を分けて記録する

操作を観察して直すを説明する生成イメージ

テスト前の説明は短く、課題は行動で伝える

参加者には、完成したサービスではなく試作であること、動かない場所があること、実際の申込みや支払いは行われないことを説明します。個人情報を入力する必要がないことも伝えます。試作品の制約を隠すと、使う人が自分の操作が悪いと感じてしまう場合があります。

そのうえで、今回の課題を一つずつ渡します。自作例なら「週末に参加できる体験イベントを選び、開催場所を確認してください」です。ボタン名や手順を説明しすぎず、相手が何を探し、どこを押そうとするかを観察できる形にします。

録画や画面収録をする場合は、目的、保存先、共有範囲を事前に説明して同意を得てください。許可がないなら、必要な行動をメモする方法でも進められます。練習だからといって、参加者の顔・声・画面情報を無断で公開しないことが大切です。

困っていても、すぐ正解を教えない

相手が迷った瞬間に押す場所を教えると、どこが分かりにくいかを観察できなくなります。少し待ち、何をしようとしているかを確認します。「今どの情報を探していますか」のような問いなら、特定のボタンへ誘導せず状況を聞きやすくなります。

ただし、長く困らせることが目的ではありません。決めた範囲で進められない場合は、その事実を記録し、必要な補助を行ったと分かるように残します。自力で到達した場合と、説明して到達した場合を同じ結果にまとめないでください。

プロトタイプの接続ミスが見つかった場合は、設計の分かりにくさと区別します。押すべき場所は分かったのに反応しなかったなら、参加者の理解の問題とは限りません。テスト用素材の不具合として記録し、修正後に同じ操作を確認します。

※表は横にスクロールできます。

記録欄自作の記入例区別すること改善へつなぐ問い
課題週末イベントの場所を確認する操作手順を教えない何を達成したい人か
観測した行動日時の文字を二度押した解釈と事実を分ける押せると見えた理由は何か
本人の言葉日付から選ぶと思った発言と行動を別に残す表示の意味が一致しているか
補助の有無途中で案内を加えた自力到達と混同しないどこで支援が必要だったか
試作の不具合接続先が別案だった設計問題と分ける修正後に同じ条件で試せるか
次の仮説日付を操作の見た目から外す一度に全部変えない変更で行動が変わるか

観測した事実と自分の解釈を分ける

記録には、「詳細の下部までスクロールしてから一覧へ戻った」「日時の文字を二度押した」のような観測した行動を書きます。その後で、「日時を選択操作だと思った可能性がある」と解釈を分けます。最初から「分かりにくい人だった」と書くと、改善点が見えなくなります。

参加者が言ったことも、行動とは別に残します。「分かりやすかった」という感想があっても、実際には何度も迷っていたかもしれません。反対に、見た目が好みではないと言われても、課題には問題なく到達できた可能性があります。感想だけで合否を決めないようにします。

数人の練習テストで割合や平均時間を出すこと自体はできますが、広い利用者全体を代表する数字とは限りません。参加者、条件、補助の有無を残し、断定的な成果として宣伝しないことが必要です。本記事の記録例も、実際の調査結果ではありません。

修正は原因の仮説を一つ置いて進める

迷いが見つかったら、文字が曖昧なのか、操作できる見た目に見えないのか、必要な情報が遠いのかを考えます。原因を確かめず、色・位置・文章・画面数を一度に変えると、何が改善につながったのか分かりにくくなります。

たとえば「日時の文字を押したが反応しない」という観察があれば、日時がリンクのように見えることを仮説にできます。文字の扱いを見直す案と、意図する操作の説明を改善する案を検討し、必要な変更から試します。大きな画面改修より、小さな検証で方向を確かめる方法もあります。

修正記録には、問題、仮説、変更、再確認結果を並べます。「色を変えた」だけでは、なぜその変更をしたかが残りません。別の人に説明できる記録を作ると、副業の制作でも、好みだけの修正依頼と使いやすさの改善を話し合いやすくなります。

自分だけで確認する場合の工夫

第三者がいない場合は、作った直後に正解の道だけを通る確認を避けます。少し時間を置き、課題文を読み、開始点から実際に操作します。別の端末や表示幅でも、見える範囲と押す場所を確かめると、作業画面では気づかなかった問題が見つかることがあります。

さらに、順路と逆順の二つを試します。詳細へ進む、補足を開く、閉じる、一覧へ戻る、別候補を見る、というように操作を組み合わせます。接続一本ずつの確認では正常でも、一連の流れで状態が変わることがあります。

ただし、自分が仕様を知っているという偏りはなくなりません。自己確認で問題がなかったことを、初めての人でも迷わない証明にはしないでください。次に誰かへ見せられるときの質問と未確認項目を残しておくと、学習をつなげられます。

共有と引き継ぎ|権限・動かない接続・未実装部分を確認する

共有前に通し確認を説明する生成イメージ

送る相手と見せる範囲を確認する

プロトタイプのリンクを送る前に、誰に見せるのか、閲覧だけでよいのか、元のデザインファイルまで見せてよいのかを確認します。便利だからという理由で公開範囲を広げると、同じファイル内の別案や未公開情報も見られる可能性があります。

特に、表示画面から共有したリンクなら元ファイルへ入れない、とは一律に言えません。Figma公式のファイル・プロトタイプ共有ガイドでは、プロトタイプのみの共有とプランによる違いが説明されています。Starterでは表示画面から共有しても元ファイルを開ける場合があるため、内容の分離と権限の確認が必要です。

業務で預かったファイルは、依頼者の承認した相手と範囲だけで共有します。外部参加者に見せるなら、必要な画面だけを含む確認用ファイルを用意する方法も検討できます。ただし、複製や外部共有が契約上許されるかも先に確認してください。

共有リンクから相手と同じ条件で開く

自分は編集者なので開けても、相手は権限がなくて開けないことがあります。共有前に、予定する相手の権限で閲覧できるかを確認します。組織のルールで公開リンクが制限されている場合は、勝手に回避せず、管理者に適切な共有方法を相談します。

送信するリンクには、確認してほしい流れ、開始点、操作できる範囲を添えます。自作の案内例は、「イベント選択の流れを確認してください。一覧から詳細へ進み、確認画面まで操作できます。入力と実送信は再現していません」です。何を見ればよいかが分かると、感想も集めやすくなります。

リンクの表示設定を変えた場合は、実際に送るURLを再取得して確かめます。古いリンクや別フローのリンクを送ると、作った内容と相手が見ている内容がずれます。共有の完了は、URLをコピーした時点ではなく、相手が対象の内容を開けることまで含めて考えます。

※表は横にスクロールできます。

共有前の点検確認すること相手へ伝える内容未完なら行うこと
対象者と権限誰が閲覧・編集できるか必要なアクセス範囲管理者と共有方法を確認
元ファイルの扱い別案や未公開情報を含まないか試作のみかファイルも見えるか必要な確認用内容に分ける
開始点とリンク送るURLから対象が開くか確認するフロー名正しいリンクを取得し直す
接続と戻り道開始から到達・選び直しまで動かせる範囲行き止まりを直すか明記
入力・送信実動作と見本を分ける個人情報入力は不要架空データの画面へ整理
検証結果観測事実と残る課題確認済み・未確認の条件次の担当と確認予定を決める

動かないときは症状から調べる

クリックしても何も起きない場合は、操作対象、重なっているレイヤー、トリガー、接続の行き先を順に確認します。別の画面へ飛ぶなら行き先、最初から違う画面が開くなら開始点と共有リンクを見ます。症状ごとに調べる項目を変えると、関係のない設定を触らずに済みます。

スクロールできない場合は、内容が枠より大きいか、対象フレームの子要素か、スクロール方向が設定されているかを見ます。全部見えるほどフレームが縦に長くなっている場合も、想定する表示範囲との関係を見直します。操作に入る前の構造が原因になることもあります。

共有先でだけ動かないなら、権限、リンク、閲覧方法、端末を分けて確認します。「Figmaの不具合」と決めつける前に、同じ開始点と同じ操作で再現するかを確かめましょう。問い合わせる際は、必要な範囲の画面と再現手順をそろえ、秘密情報を含めないようにします。

未実装部分を隠さず、次の担当へ渡す

プロトタイプが滑らかに動くほど、見る人が「もうサービスができた」と受け取ることがあります。引き継ぎには、再現した動作、固定の見本データ、未実装の入力・送信・例外処理を明記します。何が本物で何が試作用なのかを説明することも制作の一部です。

画面遷移の意図は、図や短い文章で残します。たとえば「補足を閉じたら詳細の同じ文脈へ戻る」「一覧へ戻ったら選び直せる」といった利用者の目的を書きます。アニメーションの設定値だけを渡すより、実装担当が判断しやすくなります。

また、今回のテストで分かったことと、今後の確認事項を分けます。「二人が日時を見つけた」という結果と、「スマートフォンの片手操作では未確認」という課題は両方必要です。未確認を隠さないことで、次にどの検証へ時間を使うか決められます。

最初の一本を完成させるための振り返り

練習の終わりには、開始点から目的地へ進める、戻り道がある、補足を閉じられる、必要な情報までスクロールできる、共有範囲を説明できるかを確認します。全機能を覚えることより、ひとつの目的を持つ流れを最後まで検証する経験が大切です。

操作テストや画面設計へのレビューを受けたい場合は、Webデザインスクールの学習内容・添削支援の比較も参考になります。先に自分で試作を作ると、操作方法を知りたいのか、設計の理由を相談したいのか、必要な支援を整理しやすくなります。

Figmaプロトタイプは、動きを付けて完成らしく見せるだけの機能ではありません。利用者が進み、迷い、戻る流れを見えるようにし、実装前に話し合うための道具です。まず三画面の小さな流れをつなぎ、観察した事実から一つずつ直していきましょう。