ホーム›読みもの›UIの失敗5つ

学習アプリを個人で5つ作って分かった、UIの失敗5つ

2026年8月13日 ／ フジケン

毎日ラボで公開しているツールは今のところ5つです。全部ひとりで作っていて、レビューしてくれる同僚もいないので、失敗はだいたい公開してから自分で踏みます。この記事は、実際に出してしまったUIの失敗と、そのたびに決めた自分用のルールの記録です。うまくいった話より、こっちのほうが役に立つと思うので。

失敗1：正しい手が「不正解」と判定された

いちばん質の悪いバグでした。麻雀のツールで、明らかに正しいはずの牌を切ったのに不正解が出る。しかも毎回ではなく、特定の操作をしたときだけ。

原因は2つの変更の組み合わせでした。ひとつは、結果を少し遅らせて表示するために入れた遅延処理。もうひとつは、その少し前に入れた画面モードの切り替え機能です。遅延して実行される処理が、モードを切り替えたあとに発火して、切り替え先の画面の表示だけを書き換えていた。表示されている牌と、採点の対象になっている牌がズレる。だから「正しい手なのに不正解」になる。

厄介だったのは、この2つの変更がそれぞれ単体では完全に正しかったことです。遅延表示のコードにバグはないし、モード切り替えのコードにもバグはない。組み合わせたときだけ壊れる。

ここから決めたルールは3つです。

• 遅れて実行される処理は必ず取り消せるようにしておき、画面が切り替わるときに全部止める
• 実行されるときの先頭で「今もまだ自分が想定している画面か」を確認してから動く
• 遅延処理か、画面をまたぐ状態管理か、どちらかを新しく足したら、もう一方を必ず見直す

3つ目が本質だと思っています。個人開発だと、変更を1つずつ確認して満足しがちですが、事故は変更と変更の隙間で起きます。

失敗2：大事な表示が読む前に消えていた

正解・不正解の表示や、引いたカードの内容を、アニメーションで気持ちよく出して、気持ちよく消していました。作っている本人は答えを知っているので何の問題もありません。初めて使う人は、何かが光ったのは分かるけど内容は読めていない、という状態になります。

「見えた気がするだけで流れていく」というのは、学習ツールとしては完全な失敗です。学習の中身は、まさにその一瞬の表示にあるので。

それ以来、自動で進んだり消えたりする要素を入れるときは、必ずこう自問しています。初見の人が、内容を読み終えるまでそこに残っているか。 残っていないなら、時間を伸ばすのではなく、そもそも自動で消さないようにします。次に進むのはユーザーがタップしたときだけ、という作りが結局いちばん安全でした。

失敗3：指で押せないボタンを作っていた

パソコンで作ってパソコンで確認していると、マウスカーソルの精度を前提にした小さなボタンを平気で作ります。それをスマホで開くと押せない。あるいは、隣のボタンを誤爆します。

今は、タップできる要素は最低でも指1本分（おおよそ40px以上）の高さを確保する、というのを守っています。見た目が小さくても、当たり判定は大きく取る。文字の小さいリンクほど、周りの余白を含めて押せる範囲にしておく。

それから、確認は必ず幅375pxで行います。iPhoneの標準的な幅です。ここで横スクロールが出ないか、文字がはみ出していないか、表が切れていないかを見る。パソコンの画面を狭めるだけでもかなり分かります。この確認を入れる前は、テーブルが画面外にはみ出したまま公開していたことが何度かありました。

失敗4：連打・二重送信を考えていなかった

回答ボタンを素早く2回押すと、2問分カウントが進む。ポーカーのチップ管理ツールでは、ベットボタンの連打で意図しない額が入る。どちらも、まともに使っていれば起きないけれど、通信が一瞬遅れたときに人は必ずもう一度押します。

対策自体は単純で、一度押したら処理が終わるまで受け付けない、というだけです。ただ、これを「あとで気づいて足す」のと「最初から入れておく」のとでは、直すコストが全然違いました。特に、お金や点数のようにあとから辻褄を合わせられない数字を扱うところは、最初から入れておくべきでした。

失敗5：ハッピーパスしかテストしていなかった

自分でテストするとき、無意識に「正しい順番で、最後まで、素直に」操作します。実際のユーザーはそうしません。アニメーションの途中で別の画面に移動するし、設定を途中で変えるし、答えを2回タップするし、そもそも途中でブラウザを閉じます。

失敗1のバグも、突き詰めれば「アニメーションの途中で画面を切り替える」という中断パスを試していなかったから見つからなかったものです。今は新しい機能を足したら、わざと次の操作を試すようにしています。途中で離脱する、連続でタップする、途中で設定を変える、戻るボタンを押す。

あわせて、「画面に表示されている内容と、内部で持っている状態は常に一致している」という条件だけはテストとして書き残すようにしました。細かいテストをたくさん書くより、この1本があるほうが効きます。

ひとりで作ることについて

5つ並べて気づいたのは、失敗の中身がバラバラなようで、全部「作り手の視点と、初めて使う人の視点のズレ」だということです。作った本人は答えを知っていて、操作の正しい順番を知っていて、どこにボタンがあるかも知っている。この人がテストしても何も見つかりません。

なので今は、実装に入る前に一度だけ、初めてこの画面を開いた人として通しで想像するようにしています。ここで迷わないか。速すぎて何が起きたか分からない箇所はないか。押したいものが押せるか。作ってから直すより、この1パスのほうが圧倒的に安いです。

継続の設計そのものについてはこちらの記事に、データを端末内に保存している理由はこちらに書きました。画面まわりをスマホ前提で組み直した話はこちら、問題データを作るときの失敗はこちらです。

2026年8月13日公開

← 読みもの一覧へ