フォトブックアプリ、ゼロから売れるまで
第4話
UI/UXの設計―「簡単そう」が一番難しい
「簡単でしょ」という思い込み
デザイナーに最初のブリーフィングをしたとき、こう言ってしまった。
「写真を選んで、レイアウトを決めて、注文するだけなので、シンプルにお願いします」
デザイナーの眉がピクリと動いた。
「……どのくらいのステップ数を想定してますか？」
考えたことがなかった。
BtoCのモバイルアプリでは、ステップが1つ増えるたびにユーザーが離脱するんだよ。
一般的に、購入フローのステップが1つ増えると離脱率は10〜20%上がると言われている。
「写真選択→レイアウト→確認→住所入力→支払い→完了」の6ステップがあれば、最初に100人いたユーザーが最後まで到達する人数は、劇的に少なくなるよ。
「簡単そう」に見えることが、実は最も難しい設計課題なんだよね。
悪いUXと良いUXの具体例
デザイナーと一緒に、競合アプリの「悪い体験」を洗い出した。
写真選択画面
悪い例： アルバムを選ぶ→写真一覧が開く→1枚ずつタップして選ぶ→「追加」ボタンを押す→次へ
良い例： アプリを開くと自動で最近の写真が表示される→長押しで複数選択→そのまま次へ
ステップ数は同じでも、「操作している感覚」が全然違う。
エラーメッセージ
悪い例： 「エラーが発生しました（コード：0x0042）」
良い例： 「写真のアップロードに失敗しました。Wi-Fiに接続して、もう一度お試しください」
UXは「画面のデザイン」だけじゃないんだよ。言葉も体験の一部だから。
エラーが出たとき、ユーザーは不安になっている。そこに「エラーコード」だけ出されても何もできない。「何が起きたか」「どうすれば解決するか」を人の言葉で伝えることが、不安を安心に変えるんだ。
BtoCでは、ユーザーは説明書を読まない。画面に書いてあることだけで、すべてを判断するよ。だからすべてのテキスト、すべてのボタンのラベル、すべての通知文言が「UX」なんだよね。
モバイルUXの基本原則
実際の設計で意識した、モバイルUXの原則をまとめた。
親指で届く範囲にボタンを置く
スマホは基本的に片手で使う。画面の上の方にある重要なボタンは、押しにくい。「次へ」「購入する」などの主要アクションは、画面下部に固定する。
タップ領域は最低44px
指の腹でタップするため、小さいボタンは押し間違いが多発する。Apple・Googleともに最低44pxを推奨している。「見た目のサイズ」より「タップできる範囲」を広く取る。
入力は最小限に
住所入力で郵便番号を入れたら自動補完する。名前を毎回入力させない（保存・ログイン活用）。支払い情報は一度入れたら記憶する。
当たり前なんだけど、意外と実装されていないアプリが多いんだよね。
そして「当たり前のことが当たり前にできている」アプリが、ユーザーから「使いやすい」と評価されるんだ。
UXの改善は派手な新機能じゃないよ。「当たり前の体験を、当たり前に届ける」地道な積み重ねが、離脱率を下げて購入率を上げる。
オンボーディングの設計
アプリを初めて開いたユーザーに、最初に何を見せるか。これがオンボーディングだ。
初回体験で「なるほど、こういうアプリか」「使えそう」と思ってもらわないと、そのまま削除される。
今回設計したオンボーディング
- 起動画面：「大切な写真を、感動のカタチに」（価値提案を一言で）
- 写真アクセスの許可：「あなたの写真からフォトブックを作ります」（なぜ必要か説明）
- サンプルを見せる：完成したフォトブックのイメージ写真3枚
- 「さっそく作ってみる」ボタン
会員登録は最初に求めない。
会員登録を最初に求めると、離脱率が劇的に上がるんだよ。
ユーザーはまだサービスの価値を体験していない状態で「個人情報を入力してください」と言われる。「怪しい」「面倒」と感じて、多くの人がそのまま離脱しちゃうから。
正しい順番は「価値を体験させてから、登録を求める」だよ。
フォトブックをある程度作ってもらった後で「保存するためにアカウントを作ってください」と求めると、ユーザーはすでに時間を投資しているから、登録する動機がある。この順番の違いだけで、登録完了率が2〜3倍変わることもあるんだよね。
プロトタイプでユーザーテスト
画面設計ができたら、すぐ実装せずにプロトタイプを作ってユーザーに触ってもらった。
FigmaでクリッカブルなUIモックアップを作り、ターゲットユーザー5人に操作してもらう。「思ったことを声に出しながら操作してください」とお願いして、詰まった場所を記録する。
3人が同じ場所で詰まったら、そこは設計ミスだ。
「写真を複数選択できることに気づかなかった」「このボタンが注文ボタンだとわからなかった」——こういう発見が、実装前に取れるのがプロトタイプテストの価値。
実装してから直すと、コストが10倍になるんだよ。
設計段階で直すコストが1なら、実装後は10、リリース後は100と言われる（「バグの発見が遅いほど修正コストが高い」の法則）。
プロトタイプテストに使った時間は1週間。でもその1週間で防げた手戻りは、数週間分の開発工数だったんだ。
「作る前に確かめる」がBtoCプロダクト開発の基本姿勢だよ。