動くのに使えない UI — 開発中に見落とされる導線の失敗パターン

動くことと、使えることは別

実装は仕様どおり。テストも通っている。それでも触ってみると詰まる画面があります。

理由ははっきりしています。仕様は多くの場合、正常に進んだときの流れを書いたものだからです。 画面が想定より狭いとき、操作に失敗したとき、途中で中断したときの見え方は、書かれていないことがほとんどです。

書かれていない状況の使い勝手は、誰も設計していません。詰まる箇所はそこに集中します。使う人からすると「動いていない」のと同じに見えてしまうので、放っておけない種類の問題です。

パターン 1: 表示領域を使い切れていない

よくあるのが、画面の中に小さな領域だけを使って情報を出しているケースです。たとえば、開いたモーダルが画面のごく一部しか占めておらず、中身が数行しか見えていない状態です。

作った側の意識では「スクロールすれば読める」ですが、使う側は 見えている範囲がすべてだと判断します。 下に続きがあることに気づかず、必要な情報を読まないまま閉じてしまいます。

確認の目安は単純です。

• 開いた瞬間に、何をする画面かが分かるか
• 続きがあることが、見た目で分かるか
• 一番大事な操作が、最初の表示に入っているか

この 3 つが揃っていない場合は、領域の使い方から見直したほうが早いです。余白を詰める調整では直りません。

そもそも、その内容をモーダルで出すべきかを疑う価値もあります。モーダルが向くのは、元の画面に戻る前提で、短く終わる操作 です。確認、単一の入力、選択くらいまでが目安になります。

内容	向く形	理由
削除の確認、単一項目の入力	モーダル	短く終わり、元の画面に戻る
複数の入力項目がある	独立した画面	縦に長くなり、狭い画面で破綻する
読ませたい説明が長い	独立した画面	スクロールを前提にできる
途中で保存したい作業	独立した画面	中断と再開の導線が要る

長い内容をモーダルに押し込むと、狭い画面で真っ先に破綻します。判断に迷ったら、画面幅の狭い環境で開いてみてください。そこで読めないなら、モーダルにする内容ではありません。閉じる操作が見えているかも、あわせて確認しておくと安全です。

パターン 2: 失敗したあとの戻り道がない

2 つ目は、エラーや期限切れのあとに行き止まりになるものです。

分かりやすいのが、ログインの有効期限が切れたときの挙動です。期限が切れること自体は正しい動きなのですが、切れたあとに「もう一度ログインする」導線が用意されていないと、使う人はそこで止まります。前の画面にも戻れず、何が起きたのかも分かりません。

同じ形の見落としは、通信の失敗、入力の不備、権限が足りないときにも起きます。共通しているのは、止めることだけ実装されていて、その先が実装されていないこと です。

戻り道を用意するときは、次の 3 つを画面に置いてください。文言は短くて構いません。

1. 何が起きたか。「ログインの有効期限が切れました」のように、状態を一言で伝えます
2. 次に何をすればよいか。「もう一度ログインしてください」と対処を書きます
3. そのための操作。ログイン画面へ進むボタンやリンクを置きます

抜けやすいのは 3 つ目です。状態と対処は書かれているのに、そこへ進む手段が置かれていない画面をよく見ます。使う人はメッセージを読んだあと、自分で経路を探すことになります。読ませて終わりにせず、押せる状態まで作るのが導線です。

もう 1 つ、戻り先の設計も一緒に決めておくと親切です。期限切れで中断した場合、ログインし直したあとに元の画面へ戻れるのか、最初からやり直しなのかで体験が変わります。入力の途中だった場合はなおさらです。

パターン 3: 操作したのに反応が分からない

3 つ目は、押したのに何が起きたか分からないものです。保存したはずなのに画面が変わらない、送信したのに完了の表示がない、といったケースです。

使う人は反応がないと「効いていない」と判断します。その結果、もう一度押します。二重に登録される、同じ問い合わせが 2 通届く、といった問題はここから生まれます。

厄介なのは、この症状が 裏側では正常に動いているときにこそ起きる ことです。処理は成功していて、記録も残っている。ただ画面が変わらないだけ。ログを見ても異常が出ないため、問い合わせを受けてから原因にたどり着くまで時間がかかります。

反応として必要なのは、次の 3 種類です。

タイミング	出すもの	無いと起きること
押した直後	押されたことが分かる見た目の変化	効いていないと思って再度押す
処理中	進行中であることの表示	固まったと判断して離脱する
完了後	何が終わったかの表示	できたのか分からず確認に行く

真ん中の「処理中」が特に抜けやすい部分です。開発中は手元の環境で処理が一瞬で終わるので、待ち時間そのものが発生しません。実際の利用では通信の状況によって数秒かかることがあり、その数秒のあいだ画面が無反応に見えます。

FIXIT

ちゃんと保存されてるなら、表示は無くてもよくない？

Hinata

使う人からすると、反応がないと効いていないように見えるんですよ。

FIXIT

それで 2 回押しちゃうのか。

Hinata

そうなんです。小さな表示ですけど、入れておくと事故が減りますよ。

パターン 4: 戻ると入力が消える

4 つ目は、途中まで入力したあとに前の画面へ戻ると、入力内容が消えてしまうものです。

作った側からすると、戻る操作は「やり直したい」という意思表示に見えます。ところが実際には、確認のために戻っているだけ ということが多くあります。前の画面に何を入れたか見に行って、そのまま帰ってくるつもりだった、という動きです。

この差が事故になります。確認のつもりで戻ったら全部消えていた、という体験は、そのまま離脱につながります。長い入力ほど痛手が大きく、二度目を入力する気にはなりません。

対処としては、次のどちらかになります。

• 戻っても入力を保持する
• 保持できないなら、戻る前に「入力内容は保持されません」と伝える

前者が本筋ですが、実装が難しい場合でも後者は必ず入れてください。消えること自体より、消えると知らなかったことが問題です。 事前に分かっていれば、使う人は別の手段で控えを取ります。

パターン 5: 何が必須なのか分からない

5 つ目は、入力欄を前にして手が止まるものです。どこまで埋めれば先に進めるのかが分からない状態です。

よくあるのは、送信を押して初めてエラーが出る作りです。押すまで分からないので、埋めながら不安が続きます。項目が多いほど、この不安は大きくなります。

先に示しておけば済む話です。

• 必須の項目が、入力前から見て分かる
• 任意の項目には、任意だと書いてある
• 進めない理由が、押す前から分かる

3 つ目まで揃うと、迷いがなくなります。逆に、押してから怒られる作りは、使う人を試している状態 に近くなります。

似た形で、エラーの文言が具体的でないケースもあります。「入力内容に誤りがあります」だけでは、どこを直せばよいのか分かりません。どの項目が、なぜ通らないのか まで書いてください。文言を具体的にするだけで、問い合わせが減ることがあります。

なぜ開発中に気づけないのか

5 つとも、実装した人が悪いわけではありません。確認の順番がそうさせています。

作った人は、正常な手順を、自分の環境で確認します。手順を知っているので迷いませんし、画面も広い環境で見ています。この条件で触るかぎり、上の 5 つはどれも通ってしまいます。

見落とす理由	起きること
手順を知っている	迷う場所に気づかない
正常系から確認する	うまくいった安心感で、残りが流れる
自分の環境だけで見る	狭い画面での見え方が確認されない
失敗を再現しない	エラーや期限切れのあとの画面を見ない
一度で通してしまう	戻る・やり直すといった動きを試さない

最後の行が、パターン 4 と 5 を見逃す理由です。作った人は最短の経路を一度通して確認します。実際に使う人は、迷いながら行ったり来たりします。確認しているのは同じ画面ですが、通り方が違います。

この差は、意識して真似しないと埋まりません。次の節の順番は、その真似を手順にしたものです。

リリース前は異常系から触る

順番を変えるだけで、かなり見つかります。正常系は最後で構いません。

1. 何も入力せずに進もうとする。何が必須なのかが分かるかを見る
2. わざと失敗させる。入力を空にする、通信を切る、権限のない状態で開く
3. 途中で戻る。入力が保持されるか、保持されないなら告知があるかを見る
4. 途中で放置する。期限が切れた状態から再開できるかを見る
5. 狭い画面で開く。最初の表示だけで何をする画面か分かるかを見る
6. 最後に、正常な手順を通す

もう 1 つ効くのが、その機能を知らない人に触ってもらうことです。説明なしで進めるかどうかは、作った人には判断できません。1 人に 5 分見てもらうだけでも、詰まる場所は出てきます。

このとき、横から操作を教えないでください。教えた瞬間に、その人も「手順を知っている人」になります。黙って見て、どこで手が止まったかだけを記録するのが正しいやり方です。止まった場所そのものが、直すべき箇所です。

直す順番は影響の広さで決める

見つかった問題を一度に全部直そうとすると、リリースが止まります。優先順位をつけてください。

判断の材料は 2 つで足ります。その画面を通る人の多さ と、詰まったときに先へ進めるかどうか です。

通る人	先へ進めるか	扱い
多い	進めない	最優先。リリース前に直す
多い	進める	次点。リリース後すぐ直す
少ない	進めない	次点。回避の案内だけでも置く
少ない	進める	記録して後回しでよい

先へ進めない問題は、機能が存在しないのと同じ扱いになります。使う人の側からは違いが分かりません。一方、進めるが分かりにくい問題は、体験として損ではあるものの止まりはしません。この差で線を引くと、判断が速くなります。

なお、問い合わせが来ていないことを「問題が無い」の根拠にはできません。 詰まった人の多くは、連絡せずに離れます。届く声は、詰まった人のごく一部です。この前提で優先順位を決めてください。

AI に実装させるときはとくに書き足す

AI コーディングエージェントに画面の実装を任せる場合、この傾向はさらに強く出ます。指示に書かれた画面は作られますが、書かれていない状態は作られません。

具体的には、依頼のときに次を一緒に渡してください。

• 想定する最小の画面幅と、そのときの表示の優先順位
• エラー・期限切れ・権限不足のときに何を出すか
• 操作の直後、処理中、完了後にそれぞれ何を見せるか

正常系の画面だけを渡すと、残りは実装する側の判断に委ねられます。人が作る場合は経験で埋まることもありますが、その埋まり方はばらつきます。先に書いておけば、どちらに任せても同じものが出てきます。

設計の段階で決めておくこと

ここまでは公開前の確認の話でしたが、設計の段階で決めておけば、そもそも発生しません。

画面を設計するとき、正常な状態だけでなく次の 3 つを一緒に決めてください。

1. 狭い画面での見え方。何を優先して見せるか、何を折りたたむか
2. 失敗したときの表示。文言と、そこからの戻り先
3. 待っているあいだの表示。処理中に何を見せるか

3 つとも、あとから足すと不格好になります。先に決めておけば、実装の判断がぶれません。 逆に正常系の画面だけを渡すと、残りは実装する側が都度判断することになり、画面ごとに扱いがばらつきます。

デザインを外部に依頼している場合も同じです。納品物に上の 3 つが含まれているかを確認してください。含まれていなければ、それは実装側の判断に委ねられているということです。

直したあとに確認すること

修正したあと、直ったかどうかの確認も、見つけたときと同じ順番で行ってください。正常系だけ触って終わると、直った気になって終わります。

具体的には、次の 3 点です。

• 元の詰まり方が再現しないこと。同じ手順をもう一度たどる
• 別の詰まり方が生まれていないこと。とくに戻り先を足した場合、その先で止まらないか
• 他の画面に同じ問題が無いか。1 箇所で起きた見落としは、たいてい他にもあります

3 つ目が抜けやすい部分です。モーダルの高さで問題が出たなら、他のモーダルも同じ作りである可能性が高い。 1 件直して終わりにせず、同じ形の箇所を横に探すのが結局は早く済みます。

最小構成で作るときの優先順位は SaaS の MVP の作り方 に、開発全体の品質の作り方は AI 駆動開発の品質保証 にまとめています。

まとめ

• 仕様は正常系しか書いていないことが多く、それ以外の使い勝手は未設計になる
• 失敗が集中するのは、表示領域の使い方・失敗後の戻り道・操作後の反応・入力の保持・必須の明示
• 見落とすのは注意不足ではなく、正常系を自分の環境でしか触らないため
• リリース前は異常系から触る。正常系は最後でよい
• 知らない人に 5 分触ってもらうと、詰まる場所が具体的に出る
• 設計の段階で「狭い画面・失敗時・待ち時間」を決めておけば、そもそも起きない