1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、実機確認やシナリオ試験を進める中で、かなり本質的な問題が見えてきた。
それは、導線カオス問題である。
ただし、これは単にUIが悪いとか、デザインが弱いとか、ボタンが多いとか、そういう表面的な話ではない。
もっと根本的には、画面設計のミスだったのだと思う。
画面数が足りない。
画面分割が足りない。
本来は別画面にすべき機能を、既存画面にどんどん追加してしまった。
その結果、1つの画面に複数の目的が詰め込まれ、ユーザーから見ると「この画面で何をすればいいのか」が分かりにくくなっている。
これは、考えてみれば当然だった。
必要な画面を作らずに、機能だけ追加していけば、そりゃカオスになる。
2. 問題は「画面要件の粒度不足」だけではなかった
最初は、画面要件の粒度が粗いことが問題だと思っていた。
画面ごとの目的。
主CTA。
副導線。
表示優先順位。
状態別表示。
空データ表示。
スマホ表示。
受け入れ条件。
こうした画面単位の詳細要件が足りない。
これは確かに問題である。
しかし、さらに深く考えると、それ以前の問題があった。
そもそも必要な画面数が足りていない。
画面が足りないから、既存画面に機能を足す。
既存画面に機能を足すから、その画面の目的がぼやける。
目的がぼやけるから、主導線が分かりにくくなる。
主導線が分かりにくくなるから、ユーザーが迷う。
つまり、画面要件を細かく書けば解決する話ではない。
必要な画面を追加し、分けるべき画面を分ける必要がある。
3. 1画面に詰め込みすぎた
今の問題は、いくつかの中心画面に機能が集中しすぎていることだ。
たとえば、ログイン後の中心画面は、本来であれば「現在の状態」と「次にやること」を示す入口であるべきだ。
しかし、そこにあれもこれも置こうとすると、全機能置き場になってしまう。
詳細画面も同じである。
本来は概要を見る画面なのに、そこに操作、確認、履歴、結果、補足情報、関連情報まで詰め込んでしまうと、何のための画面なのか分からなくなる。
個別の情報は必要かもしれない。
個別の機能も必要かもしれない。
でも、それを全部同じ画面に置く必要はない。
見る画面。
選ぶ画面。
実行する画面。
確認する画面。
結果を見る画面。
これらは、本来分けるべきだった。
4. 機能追加のスピードに、画面設計が追いついていなかった
AIを使っていると、機能追加のスピードはかなり上がる。
アイデアを出す。
仕様を作る。
実装指示を出す。
Cursorがコードを書く。
テストも追加する。
ドキュメントも更新する。
この流れで、かなり速く前に進める。
ただし、その副作用もある。
機能はどんどん増える。
でも、画面体系の整理が追いつかない。
結果として、既存画面にとりあえず機能を追加してしまう。
「この画面に置いておけば、とりあえず使える」
「既にある画面だから追加しやすい」
「別画面を作るより早い」
そうやって短期的には進む。
しかし、長期的には画面が壊れていく。
これは、AI開発の怖いところでもある。
実装速度が上がるほど、設計の粗さも早く露呈する。
5. 常時参照画面と操作画面を混ぜてはいけない
今回かなり重要だと思ったのが、常時参照画面と特定タイミングで操作する画面を分けることだ。
常時参照できる画面は、いつでも見られる必要がある。
たとえば、
自分の状態を見る画面
対象一覧を見る画面
詳細を見る画面
履歴を見る画面
通知を見る画面
ヘルプを見る画面
こういうものは、常にアクセスできてよい。
一方で、特定のタイミングで操作する画面もある。
準備する画面
実行する画面
結果を確認する画面
振り返る画面
イベント発生時だけ出る画面
これらは、常時参照画面とは性質が違う。
ここを混ぜると、導線が崩れる。
常時見られるべき情報と、今だけ操作すべきタスクが同じ強さで並ぶ。
その結果、「今、自分は何をすればいいのか」が分からなくなる。
6. フェーズ別のハブ画面が必要だった
今回の整理で、フェーズ別のハブ画面が必要だと感じた。
ログイン後の中心画面にすべてを置くのではなく、現在の状態に応じた入口を分ける。
たとえば、
準備フェーズ用の画面
実行フェーズ用の画面
結果確認用の画面
振り返り用の画面
イベント確認用の画面
こうした画面を用意する。
ログイン後の中心画面は、全機能置き場ではなく、現在の状態と次にやることを示す入口にする。
そして、実際の細かい操作は、それぞれのハブ画面や専用画面へ逃がす。
これにより、中心画面の情報量を減らせる。
ユーザーに対しても、
「今はこの状態です」
「次にやることはこれです」
「詳しい操作はこちらです」
と案内しやすくなる。
7. 詳細画面も分割が必要
詳細画面も、かなり注意が必要である。
詳細画面は便利なので、つい何でも置きたくなる。
概要。
状態。
操作ボタン。
履歴。
関連情報。
補助説明。
結果導線。
コメント。
レポート。
しかし、詳細画面に全部置くと、その画面の役割が崩れる。
詳細画面は、あくまで概要と状態を把握し、状態に応じた次の導線を出す画面にするべきだと思う。
実行系の操作は、必要に応じて専用画面に分ける。
詳細を見る
操作する
確認する
完了を見る
結果を見る
この流れを分けることで、ユーザーの迷いを減らせる。
8. イベント発生画面も別カテゴリとして考える必要がある
もう一つ大きいのが、イベント発生画面である。
進行型のWebサービスでは、通常画面だけでは足りない。
特定の時期だけ出る画面。
特定の条件で発生する画面。
通知から入る画面。
結果確認で表示される画面。
未処理タスクとして出す画面。
アーカイブとして残す画面。
こうしたイベント系画面を、通常画面に無理やり詰め込むと、また導線がカオスになる。
イベントは、イベントとして別カテゴリで整理する必要がある。
すべてをグローバルナビに置く必要はない。
すべてをダッシュボードに大きく出す必要もない。
重要なイベントは未処理タスクとして表示する。
軽いイベントは通知でよい。
選択が必要なイベントは専用画面にする。
記録として残すものはアーカイブにする。
こういう整理が必要になる。
9. ダッシュボードを全機能置き場にしてはいけない
今回かなり反省しているのは、ダッシュボード的な画面の扱いである。
ダッシュボードは便利である。
何でも置ける。
何でも入口にできる。
各機能へのリンクを置きやすい。
状態表示も置きやすい。
しかし、それが危険である。
ダッシュボードに何でも置くと、すぐに全機能置き場になる。
本来の役割は、ユーザーに現在地と次の行動を示すことだと思う。
だから、ダッシュボードは以下に絞るべきである。
現在の状態
次にやること
未処理タスク
重要通知
主要導線
常時参照ページへの最小限の入口
詳細な情報や低頻度の導線は、別画面やメニュー配下に逃がす。
ダッシュボードは、全部を見せる場所ではない。
迷わず次に進ませる場所である。
10. 画面数を増やすことは悪ではない
画面数が増えると複雑になるのではないか、という考えもある。
もちろん、無計画に増やせば複雑になる。
しかし、必要な画面を作らない方が、もっと複雑になることもある。
1画面に複数目的が混ざる。
1つのカードに複数の導線が入る。
同じ画面で見る、選ぶ、実行する、確認する、結果を見るまでやらせる。
そうなると、見た目は1画面でも、体験としては複雑になる。
画面数を適切に増やすことで、むしろ分かりやすくなる。
重要なのは、画面数を減らすことではない。
ユーザーの目的ごとに、画面を適切に分けることである。
11. 今後は画面体系を再設計する
今後は、画面体系を再設計する必要がある。
まずは、以下のような分類で整理したい。
トップ・認証・初回導線
ダッシュボード
常時参照できる基本画面
準備系画面
実行系画面
結果確認・振り返り系画面
履歴・記録系画面
ニュース・お知らせ系画面
プロフィール・ランキング系画面
ヘルプ・FAQ・用語集
時期・イベント発生画面
管理者画面
このように分類してから、必要な画面を洗い出す。
そのうえで、既存画面に詰め込みすぎている機能を、どの画面へ切り出すかを決める。
12. 詳細要件はP0画面から作る
全画面の詳細要件をいきなり作るのは重い。
だから、まずは画面体系を整理する。
次に、P0画面だけ詳細要件を作る。
各画面について、以下を定義する。
画面の目的
対象ユーザー
到達経路
主導線
副導線
表示情報
情報優先順位
操作・ボタン
状態別表示
エラー・空状態
スマホ表示要件
E2E観点
実機確認観点
受け入れ条件
未確定事項
ここまで整理すれば、AIに実装させるときもブレにくい。
実機確認でも、何を見ればよいか明確になる。
13. これは設計ミスの修正である
今回の問題は、単なる改善ではない。
これは設計ミスの修正である。
機能を増やすことに意識が向きすぎて、画面体系の整理が追いついていなかった。
画面数が足りないのに、機能ばかり追加した。
その結果、既存画面に機能が集中した。
画面ごとの目的がぼやけた。
導線がカオスになった。
ここを認める必要がある。
ただし、気づけたことは大きい。
サービスイン前に気づけたなら、まだ直せる。
今後は、画面数を増やすことを恐れず、必要な画面をきちんと追加する。
そして、各画面の目的を明確にする。
14. 今回の結論
導線カオスの根本原因は、UIの見た目だけではなかった。
画面数が足りなかった。
画面分割が足りなかった。
必要な画面を作らず、既存画面に機能を追加しすぎた。
そりゃカオスになる。
今後は、以下を徹底したい。
画面の目的が違うなら画面を分ける
操作タイミングが違うなら画面を分ける
見る、選ぶ、実行する、確認する、結果を見るを分ける
常時参照画面と特定タイミングの操作画面を分ける
イベント発生画面を別カテゴリとして整理する
ダッシュボードを全機能置き場にしない
詳細画面に全操作を詰め込まない
P0画面から詳細要件を作る
AIを使うと、機能追加は速くなる。
しかし、画面設計を怠ると、速くカオスになる。
今回の学びはそこだ。
これからは、機能を足すだけでなく、画面を分ける。
必要な画面を追加する。
画面ごとの目的を明確にする。
サービスイン前に、この設計ミスを立て直したい。
0 件のコメント:
コメントを投稿