アプリのワイヤーフレームとプロトタイプを外注するには？本開発前に固める5項目

アプリのアイデアはあるものの、必要な画面やボタンの配置まで決められないことがあります。

この状態で本開発を依頼すると、制作途中で「この機能も必要だった」「想定していた操作と違う」と判明し、仕様変更や追加費用が発生する原因になります。

そこで役立つのが、ワイヤーフレームとプロトタイプです。

本格的なプログラミングへ進む前に、画面の構成と操作の流れを目に見える形にすれば、発注者、デザイナー、開発者の認識をそろえられます。

ワイヤーフレームとプロトタイプの違い
ワイヤーフレームだけ外注する場合との違い
外注範囲は4段階から選ぶ
外注前に固める5項目
主要な操作だけを先に作る
画面数を数えるときの注意点
開発者と連携できるデザイナーを選ぶ理由
外注先へ渡す資料
参考アプリの伝え方
今回のサービスで依頼できる流れ
無料修正が無制限でも仕様変更は別
外注先を比較する項目
見積もり相談で送る文章の例
よくある外注の失敗
まとめ

ワイヤーフレームとプロトタイプの違い

ワイヤーフレームとプロトタイプは、どちらも本開発前に作りますが、確認する内容が異なります。

制作物	主に確認する内容	一般的な状態
手書きラフ	アイデアと必要機能	紙や簡単な図
ワイヤーフレーム	情報の配置と画面構成	白黒または簡素な画面
UIデザイン	色、文字、余白、ボタン	完成に近い静止画
プロトタイプ	画面遷移と操作感	タップして画面を移動できる
動作版・MVP	実際の機能や市場反応	一部機能が動くアプリ

ワイヤーフレームは、画面に何を置くかを整理する設計図です。

見出し
画像
入力欄
検索条件
メニュー
ボタン
注意事項
料金
商品やサービスの一覧

これらの位置と優先順位を決めます。

一方、プロトタイプは、作成した画面をつないで操作の流れを確認する試作品です。

プロトタイプには静止画に近いものから、実際の機能を一部実装したものまで複数の種類があります。UI制作サービスで提供されるものは、ボタンを押すと別の画面へ移動する「クリッカブルプロトタイプ」が中心です。

ワイヤーフレームだけ外注する場合との違い

ワイヤーフレームだけを外注すれば、画面の配置は整理できます。

ただし、完成UIや操作可能なプロトタイプまで作らない場合、次の項目は確認しにくくなります。

ボタンが見つけやすいか
文字量が多すぎないか
画面を移動する順番が自然か
戻る操作で迷わないか
入力から完了までが長すぎないか
重要な操作が目立っているか
開発者が完成形を理解できるか

アプリでは、各画面の見た目だけでなく、画面同士のつながりが使いやすさに影響します。

ワイヤーフレームを作る際も、画面内の配置と、利用者の行動に沿った画面遷移の両方を整理する必要があります。

外注範囲は4段階から選ぶ

必要以上に多くの作業を頼むと費用が増えます。

反対に、外注範囲を狭くしすぎると、本開発前に確認できない項目が残ります。

現在の準備状況に合わせて依頼範囲を選びます。

ワイヤーフレームだけ依頼する

次の条件に当てはまる場合に向いています。

アプリの目的が決まっている
必要な機能が確定している
UIデザインを担当する人が別にいる
開発会社がワイヤーフレームを求めている
画面数と情報配置だけを整理したい

完成するのは、各画面の骨組みです。

色や細かな装飾は含めず、情報の優先順位を確認します。

ワイヤーフレームとUIを依頼する

画面構成に加えて、完成時の見た目まで確認したい場合に向いています。

配色
文字サイズ
ボタン
入力欄
カード
アイコン
余白
写真の配置

開発担当者へ完成画面を渡せるため、見た目の認識を共有しやすくなります。

ワイヤーフレーム・UI・プロトタイプを依頼する

本開発前に操作感まで確認したい場合に向いています。

ボタンを押した後の移動
戻る操作
入力から確認までの流れ
メニューの切り替え
ログイン前後の分岐
完了後の案内

早い段階でプロトタイプを確認すると、完成後の認識違いを見つけるのではなく、設計段階で方向を修正できます。

動くアプリまで依頼する

データ保存、ログイン、検索、通知、決済など、実際の機能を試したい場合は開発作業が必要です。

UIのプロトタイプと、実際に動作するMVPは同じではありません。

プロトタイプは主に操作や画面構成の検証に使い、MVPは必要最小限の機能を実装して市場の反応を確認するために使います。

依頼前に「どこまで動く必要があるか」を明確にしてください。

外注前に固める5項目

完成された仕様書は必要ありません。

ただし、次の5項目が曖昧なままだと、ワイヤーフレームを作っても判断基準がありません。

1．アプリを作る目的

最初に、事業者側の目的を決めます。

商品を販売する
店舗予約を受け付ける
有料会員を獲得する
業務を効率化する
顧客と継続的に接点を持つ
情報を記録・管理する
広告収益を得る
サービス利用者同士をつなぐ

「便利なアプリを作りたい」だけでは、必要な機能や画面を判断できません。

たとえば予約件数を増やすことが目的なら、店舗紹介の情報量より、検索から予約完了までの短さが重要になります。

2．利用する人

同じ機能でも、利用者によって適した画面は変わります。

年齢
職業
利用する時間帯
スマートフォンへの慣れ
個人または法人
毎日使うか、必要なときだけ使うか
無料利用か、有料契約か
アプリを使う場所

高齢者向けなら、文字やボタンを大きくするだけでは足りません。

専門用語を避け、入力項目を減らし、操作後の結果を明確に表示する必要があります。

社内業務アプリなら、見た目の華やかさより、繰り返し操作の速さが優先されます。

3．最も重要な行動

利用者へ最終的に取ってほしい行動を1つ決めます。

会員登録
予約
購入
問い合わせ
投稿
保存
記録
有料プランへの申込み

主要な行動が決まっていないと、ホーム画面へ複数のボタンが同じ強さで並びます。

「予約」が最重要なら、ホーム画面から予約機能へすぐ移動できる構成にします。

4．必要な機能

思いついた機能をすべて入れるのではなく、優先度を分けます。

優先度	内容
必須	この機能がないとサービスが成立しない
重要	利用しやすさや継続率に影響する
将来追加	初回リリース後でも対応できる
不要	目的に直接関係しない

予約アプリなら、店舗検索、日時選択、予約確認は必須です。

口コミ投稿、ポイント、チャット、クーポンは、事業内容によって重要度が変わります。

すべてを初回版に含めると、画面数と開発費が膨らみます。

5．プロトタイプで確認すること

プロトタイプは、作ること自体が目的ではありません。

何を確認する試作品なのかを決めます。

登録の手順が長すぎないか
検索条件を選びやすいか
購入ボタンを見つけられるか
予約完了まで迷わず進めるか
管理者と一般利用者の画面を分けられるか
開発会社へ完成イメージを伝えられるか
社内の承認を得られるか
顧客へ企画を説明できるか

確認目的が異なれば、必要な画面数やプロトタイプの精度も変わります。

主要な操作だけを先に作る

最初からアプリ全体のプロトタイプを作る必要はありません。

利用者にとって最も重要な操作を選び、開始から完了までを先に作ります。

予約アプリなら、次の流れです。

ホームを開く
店舗を検索する
店舗詳細を見る
日時を選ぶ
利用者情報を入力する
予約内容を確認する
予約を完了する

この流れだけでも、少なくとも次の問題を確認できます。

検索条件が不足していないか
詳細画面に必要な情報があるか
予約ボタンが見つかるか
入力項目が多すぎないか
確認画面が必要か
完了したことが伝わるか

設定、通知、お気に入りなどの補助機能は、主要フローが固まってから追加できます。

画面数を数えるときの注意点

見積もりでは「5画面」「10画面」のように制作数を伝えます。

ただし、画面名だけで数えると、必要な状態を見落とします。

たとえばログイン画面には、次の状態があります。

通常表示
未入力
入力エラー
パスワード表示中
読み込み中
ログイン失敗
パスワード再設定

これらをすべて別画面として制作するのか、基本画面の一部として扱うのかは、依頼先によって異なります。

見積もり前に、次の項目を確認してください。

ポップアップは1画面に含まれるか
エラー表示は別料金か
メニューを開いた状態も制作するか
ログイン前後で別画面になるか
スマートフォンとタブレットを両方作るか
管理者画面も含むか
プロトタイプ設定は基本料金に含まれるか

開発者と連携できるデザイナーを選ぶ理由

完成したUIがきれいでも、実装方法を考慮していなければ、開発段階で変更が必要になることがあります。

たとえば次のデザインです。

OSで再現しにくい複雑なアニメーション
状態ごとの表示が決まっていないボタン
文字数が変わると崩れるカード
小さすぎて押しにくい操作部分
データ量を考慮していない一覧
エラー時の表示がない入力フォーム
開発予定にない機能を前提とした画面

デザイナーとアプリ開発者が連携していれば、見た目だけでなく、実装時の制約や必要な状態も考慮しやすくなります。

特に、デザイン完成後に同じ依頼先へアプリ開発も相談する可能性がある場合は、デザインと開発を分断しない方が引き継ぎを進めやすくなります。

スマホアプリのUI/UXデザインを作成します

外注先へ渡す資料

専門的な企画書を作る必要はありません。

次の情報を1つの文書へまとめます。

アプリの概要
アプリを作る目的
想定している利用者
最も重要な行動
必須機能
将来追加したい機能
参考にしているアプリ
手書きラフ
希望する画面数
対応端末
希望納期
予算
プロトタイプで確認したい内容
本開発を依頼する予定の有無

手書きラフは、整った資料でなくても構いません。

スマートフォンの枠を描き、「ここに検索欄」「ここに一覧」「ここに予約ボタン」と書くだけでも、考えている構成を共有できます。

ワイヤーフレームを発注者側で作る場合と、専門家へ依頼する場合にはそれぞれ利点があります。自作すると費用を抑えられる可能性がありますが、情報設計や操作性に問題が残ることもあります。

参考アプリの伝え方

参考アプリを送るときは、「これと同じにしてください」と依頼しません。

参考にしたい箇所を具体的に指定します。

ホーム画面の情報量
下部メニューの構成
商品カードの見せ方
会員登録の短さ
検索条件の選択方法
予約完了までの流れ
ボタンの大きさ
文字と余白のバランス

反対に、避けたい点も書きます。

機能が多すぎる
文字が小さい
広告が目立ちすぎる
登録前に使えない
メニューが深い
戻る場所が分かりにくい
入力項目が多い

参考にする部分と避ける部分を分ければ、既存アプリのコピーではなく、自社に必要な設計を依頼できます。

今回のサービスで依頼できる流れ

今回紹介しているサービスでは、次の順番でUI/UXデザインを制作すると案内されています。

アプリの目的とターゲットをヒアリング
必要な機能を明確化
ワイヤーフレームを作成
UIデザインを作成
操作可能なプロトタイプを作成

単体画面の装飾だけではなく、アプリ全体の設計を扱う点が特徴です。

また、デザイナーとアプリ開発者の2人が連携して制作し、自社アプリのデータ解析をもとに、コンバージョンが発生しやすいUIを提案すると説明されています。

掲載されている料金目安は、1画面8,000～12,000円です。

項目	掲載内容
料金目安	1画面8,000～12,000円
ラフ提案	2案
無料修正	無制限
納期	要相談
対応範囲	ワイヤーフレーム、UI、プロトタイプ
制作体制	デザイナーとアプリ開発者が連携

画面数、情報量、必要機能によって見積もりは変わります。

仕様確定後の大幅な変更は別料金になる場合があるため、制作開始前に主要機能を整理してください。

無料修正が無制限でも仕様変更は別

無料修正回数が無制限でも、アプリの仕様を何度でも変更できるとは限りません。

一般的に修正として扱われやすいのは、次の内容です。

色を調整する
文字サイズを変える
余白を調整する
ボタンの位置を少し変える
表現を修正する
画像を差し替える

別作業になりやすいのは、次の内容です。

機能を追加する
画面数を増やす
ターゲットを変更する
画面遷移を全面的に変える
予約アプリからECアプリへ方向転換する
制作済み画面を別端末用に作り直す

プロトタイプはフィードバックを反映しやすい一方、確認項目を決めずに修正を繰り返すと、費用や期間が膨らむ可能性があります。

各回の確認では、感想だけでなく、問題のある操作と修正理由をまとめて伝えます。

外注先を比較する項目

価格だけで依頼先を決めると、必要な作業が含まれていない場合があります。

比較項目	確認する内容
ヒアリング	目的とターゲットから確認するか
機能整理	必要機能の優先順位も相談できるか
ワイヤーフレーム	基本料金に含まれるか
UIデザイン	何案提案されるか
プロトタイプ	どの画面を操作できるか
開発知識	実装を考慮した提案が可能か
修正	回数と対象範囲
納品	開発担当者へ渡せる形式か
本開発	デザイン後も相談できるか
実績	アプリ全体の設計経験があるか