個人開発では、機能を実装できた時点で「完成」に見えます。しかし、実際に使うと、押しにくい、今の状態が分からない、文字を大きくすると崩れる、失敗後に戻れないといった問題が見つかります。UI改善は色や余白を整えるだけでなく、利用者が迷わず目的を達成できる状態にする作業です。
この記事では、GTANSU LABで作っているVoice Interval Timer、幹事くん、Scorebookの利用場面を例に、改善時のチェックポイントをまとめます。
最初に「この画面で一番したいこと」を決める
一つの画面に同じ強さのボタンが並ぶと、利用者は毎回読み直します。まず、その画面を開いた人が最も多く行う操作を一つ決め、位置、サイズ、色、文言で優先順位を付けます。補助操作は主操作より控えめにし、設定や説明は必要な場所から到達できるようにします。
Voice Interval Timerの実行画面なら、残り時間と開始・停止が中心です。幹事くんの参加者画面なら、誰が支払い済みかを素早く確認することが中心です。Scorebookの試合中画面なら、現在の打者・カウント・走者と次の記録操作が中心になります。アプリ全体で同じレイアウトを使うより、利用場面に合わせて優先情報を決めます。
1. 画面を3秒見て現在地が分かるか
- 画面タイトルや対象データが見える
- 選択中のタブや現在の工程が分かる
- 保存済み・未保存、実行中・停止中などの状態が分かる
- 主操作が他のボタンより見つけやすい
- 空の画面でも次に何をすればよいか分かる
状態は色だけに頼らず、文字、アイコン、形を組み合わせます。たとえば支払い済みを緑だけで示すのではなく、「支払い済み」というラベルやチェックアイコンを付けます。タイマーの停止中も背景色だけでなく、停止中の文字と再開ボタンを表示します。
2. タップ領域は見た目より広くする
Androidのアクセシビリティガイドでは、操作要素のフォーカス可能な領域、つまりタップ対象を少なくとも48dp×48dpにすることが推奨されています。24dpのアイコンを使う場合でも、周囲に余白を持たせて押せる範囲を確保します。
- 小さなアイコンだけがタップ対象になっていない
- 隣り合う操作の間に誤タップを防ぐ余白がある
- 片手操作で頻繁に使うボタンへ届く
- 長押しやスワイプだけに重要操作を依存していない
- ボタンの文言から実行結果を予測できる
試合中や会計中、運動中は落ち着いて画面を狙えません。机に置いた端末、屋外、歩きながらではなく停止した状態など、実際の利用姿勢で押しやすさを確認します。
3. 文字を大きくしても読めるか
端末のフォントサイズを上げ、見出し、ボタン、表、ダイアログを確認します。文字が途中で切れる場合は、固定の高さや一行前提を見直します。特に数値中心の画面では、単位とラベルが消えると意味が分からなくなるため、数字だけでなく文脈も残します。
- 本文と補足の大きさに十分な差がある
- 重要な数値だけを極端に小さくしていない
- ボタン文字が省略されても意味を誤解しない
- 行間と段落間に余白があり、密集して見えない
- ダークテーマ・ライトテーマの両方で読める
4. 色だけに意味を持たせない
成功、警告、エラー、選択状態を色だけで表すと、色の見え方が異なる利用者や、明るい屋外、画面の省電力設定で区別しにくくなります。色に加えて、短いラベル、アイコン、枠線、太さの変化を使います。
確認時は画面をグレースケールにしても状態を区別できるか、明るさを下げても文字が読めるか、スクリーンショットだけで主操作が分かるかを見ます。ブランドカラーを増やすより、背景、本文、補助情報、アクセント、警告の役割を固定する方が一貫性を保ちやすくなります。
5. 入力エラーは「直し方」まで伝える
「入力に誤りがあります」だけでは、利用者は探し直す必要があります。該当項目の近くで、何が必要か、どの形式ならよいかを具体的に表示します。入力内容を保持したまま修正できることも重要です。
- エラー箇所へ視線やフォーカスを移せる
- 正しい入力例を示す
- 再試行でき、入力内容が消えない
- 通信失敗と入力ミスを別のメッセージにする
- 保存や削除の結果を短く通知する
破壊的な操作には、削除対象を明記した確認を出します。可能なら取り消しを用意し、確認ダイアログを何度も出すのではなく、誤操作の影響が大きい場面へ限定します。
6. 読み込み・空・失敗・完了の4状態を作る
開発中はデータが入った状態ばかり見がちです。しかし初回起動時は空で、通信や保存は失敗することがあります。各画面について、読み込み中、データなし、失敗、表示完了の4状態を並べて確認します。
空状態では「データがありません」だけで終わらず、何を追加できるかと操作ボタンを示します。失敗状態では再試行と問い合わせに必要な情報を用意します。読み込み表示が長引く場合は、アプリが停止していないことが伝わるようにします。
7. TalkBackで操作の順番と名前を確認する
画像やアイコンには目的が分かる説明を付け、装飾だけの画像は読み上げ対象から外します。「ボタン1」「画像」のような名前ではなく、「タイマーを開始」「参加者を追加」のように操作結果が分かるラベルにします。
- フォーカス順が画面の読み順と一致している
- 選択済み、オン・オフ、進捗などの状態が読み上げられる
- アイコンボタンに目的を示すラベルがある
- スワイプだけの操作に代替手段がある
- 時間やスコアの変化を過剰に読み上げない
8. 端末ではなく「利用できる画面幅」に合わせる
Android端末はスマートフォンだけでなく、タブレット、折りたたみ端末、ChromeOS、マルチウィンドウでも使われます。公式ガイドでは物理端末の種類ではなく、アプリに利用できるウィンドウサイズを基準にレイアウトを適応させる考え方が示されています。
小さい幅では一列、大きい幅では一覧と詳細の二つの領域を表示するなど、情報量を増やす方法を検討します。ただし、大画面でスマートフォン画面を単純に引き伸ばすだけにしません。横向き、分割画面、ソフトウェアキーボード表示中も主要操作が隠れないか確認します。
実例別に見る確認ポイント
| アプリ | 利用場面 | 優先して確認するUI |
|---|---|---|
| Voice Interval Timer | 運動中、画面を見続けない | 残り時間、開始・停止、音声状態、誤タップ防止 |
| 幹事くん | 会計時に短時間で確認 | 支払い済み表示、参加者検索、合計、取り消し |
| Scorebook | 試合進行中に連続入力 | 現在の打者・カウント、入力順、訂正、屋外視認性 |
同じデザインルールを当てはめるだけでなく、失敗したときの影響を考えます。タイマーの誤停止、会費の誤記録、試合結果の誤入力では必要な防止策と修正方法が異なります。
リリース前のUIチェックリスト
- 各画面の主操作を一つ説明できる
- 48dp以上のタップ領域を確保した
- フォントサイズを上げても操作できる
- 色を見なくても状態を区別できる
- 読み込み・空・失敗・完了を確認した
- 削除や上書きの対象が明確で、必要なら取り消せる
- TalkBackで主要な流れを完了できる
- 横向き、分割画面、異なる幅で崩れない
- 実際の利用場所と姿勢で実機確認した
まとめ
UI改善は、見た目を豪華にする作業ではありません。利用者の目的、現在の状態、次の操作、失敗からの戻り方を分かりやすくすることです。まず一番利用される画面を選び、主操作、48dpのタップ領域、文字サイズ、色以外の状態表示、空・失敗状態を順番に確認すると、小さな修正でも使いやすさを改善できます。