1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、開発はかなり進んできた。
画面も増えた。
機能も増えた。
自動テストも整ってきた。
確認用端末での実機試験も始めている。
開発用PCと確認用端末の役割分担も、だいぶ整理されてきた。
ただ、ここに来てかなり重要な問題が見えてきた。
それが、導線カオス問題である。
これは単なるUIの見た目の問題ではない。
ボタンの色が悪いとか、余白が少し狭いとか、そういうレベルではない。
もっと根本的な問題である。
その画面が何のための画面なのか分かりにくい。
操作できる選択肢が多すぎる。
情報量が多すぎて、重要な操作が埋もれている。
ユーザーが次に何をすればよいのか分からない。
これは、サービスイン前にかなり真剣に潰す必要がある。
2. 機能が増えるほど、画面は分かりにくくなる
開発中は、つい機能を増やしたくなる。
この情報も見せたい。
この導線も置きたい。
このボタンも必要そう。
この補助説明もあった方が親切。
この将来機能の入口も先に置いておきたい。
そうやって少しずつ足していくと、画面はどんどん重くなる。
最初はシンプルだった画面が、気づけばリンク、ボタン、カード、説明文、補助情報、ステータス表示でいっぱいになる。
開発者目線では、それぞれに意味がある。
しかし、初見ユーザーから見ると、全部が同じ強さで並んでいるように見える。
結果として、
「で、結局この画面では何をすればいいの？」
となる。
これは非常に危険である。
3. 導線カオスは、バグより分かりにくい
バグは分かりやすい。
ボタンを押してエラーが出る。
画面が壊れる。
データが保存されない。
ログインできない。
処理が失敗する。
こういうものは、比較的見つけやすい。
しかし、導線カオスは分かりにくい。
画面は表示されている。
ボタンもある。
リンクもある。
機能も動いている。
一見すると、問題がないように見える。
しかし、実際に人間が触ると迷う。
どこを押せばいいか分からない。
どの情報が重要か分からない。
なぜ似たようなカードが複数あるのか分からない。
今すぐ使うべき機能と、後で見ればよい情報が混ざっている。
これは、通常の自動テストでは拾いにくい。
だから、確認用端末には通常のバグ探しではなく、人間が触って迷う画面を洗い出す試験をさせる必要がある。
4. 今回確認したい観点
今回の試験では、単に機能があるかどうかを見るのではない。
確認したいのは、以下である。
その画面が何のための画面か一目で分かるか
ユーザーに最初に何をしてほしい画面か分かるか
主要アクションが明確か
ボタンやリンクが多すぎないか
情報量が多すぎて重要な操作が埋もれていないか
初見ユーザーが迷わないか
サービスイン初期に本当に必要なものだけが前面に出ているか
これは、かなり重要な観点である。
今までは「機能を作る」「動くようにする」「エラーを減らす」という意識が強かった。
しかし、サービスとして人に触ってもらうなら、それだけでは足りない。
使えることと、迷わず使えることは違う。
5. 各画面の目的を棚卸しする
今回やるべきことは、各画面の目的の棚卸しである。
それぞれの画面について、まず以下を考える。
この画面は何のための画面なのか。
ユーザーに最初に何をしてほしいのか。
この画面で絶対に必要な操作は何か。
この画面に置かなくてもよい情報は何か。
別画面に逃がすべき機能は何か。
この整理をしないまま機能を増やすと、画面は必ず複雑になる。
特に、ログイン後の中心画面、初回ユーザーが最初に入る画面、主要操作に関わる詳細画面は重要である。
ここがカオスだと、ユーザーは離脱する。
6. Primary Actionを絞る
画面設計で重要なのは、Primary Actionである。
その画面で、ユーザーに一番押してほしいボタンは何か。
一番進んでほしい導線はどれか。
これが分からない画面は弱い。
現状、いろいろな画面で、複数のボタンやカードが同じ強さで並んでいる可能性がある。
そうなると、ユーザーは迷う。
理想としては、
Primary Actionは1つ
Secondary Actionは2〜3個
それ以外は控えめにする
詳細情報は折りたたむ
後回し機能や将来機能は前面に出しすぎない
という形にしたい。
機能を消す必要はない。
ただし、画面上の優先順位は明確にする必要がある。
7. 情報量を減らす勇気
開発していると、情報を出したくなる。
せっかくデータがあるなら表示したい。
せっかく機能があるなら入口を置きたい。
せっかく説明を書いたなら見せたい。
しかし、情報が多いことは、必ずしも親切ではない。
初見ユーザーにとっては、情報が多いほど混乱することがある。
重要情報と補助情報が同じ強さで表示されていると、何を読めばよいか分からない。
だから、情報量を減らす勇気が必要である。
初回に必要な情報だけ出す
補足は折りたたむ
詳細は別画面に逃がす
将来機能は控えめにする
内部的な状態や細かい説明を前面に出しすぎない
これは、かなり大事だと思っている。
8. 新規ユーザー視点が特に重要
既に仕様を知っている自分が触ると、多少画面が複雑でも理解できる。
しかし、新規ユーザーは違う。
初回ログイン後に、何をすればよいか分からない。
専門用語や独自概念が一度に出る。
画面上に複数の導線があり、どれが最初なのか分からない。
空データ状態で何も起きていないように見える。
これでは厳しい。
新規ユーザーには、まず「次にやること」を明確に出す必要がある。
最初からすべての機能を見せるのではなく、最初に進むべき道を示す。
これは、サービスイン初期では特に重要である。
9. 確認用端末にやらせる試験の価値
今回の導線カオス問題は、確認用端末にやらせる価値が高い。
開発用PCは、どうしても実装目線になりやすい。
この機能は動くか。
このテストは通るか。
このエラーは直ったか。
このPRはマージできるか。
一方で、確認用端末には、実際に触った人間目線で見てもらいたい。
初見で迷うか
ボタンが多すぎるか
情報量が多すぎるか
主要導線が見えているか
画面の目的が分かるか
どの画面が一番カオスか
これは、実装側だけでは見落としやすい。
だから、二台運用の意味がある。
開発用PCは作る。
確認用端末は迷う。
迷った箇所を報告する。
開発用PCが整理する。
この流れが重要である。
10. 試験レポートで見たいもの
今回の試験では、単なる不具合一覧ではなく、画面目的棚卸しレポートが必要である。
各画面について、以下のように整理したい。
画面名
想定される本来の目的
現状の印象
迷いやすい点
残すべき主要機能
削る、下げる、別画面に逃がすべき要素
推奨する画面整理方針
重要度
スクリーンショット
さらに、全体サマリーとして以下も欲しい。
最も導線がカオスになっている画面 Top 5
最も情報量が多すぎる画面 Top 5
主要機能が分かりにくい画面 Top 5
初見ユーザーが最初に詰まりそうな箇所
サービスイン前に必ず整理すべきP0指摘一覧
P0ではないが品質に大きく影響するP1指摘一覧
全画面共通の改善方針
開発用PC側に実装依頼すべき改善案
ここまで整理できれば、かなり次の改善に使える。
11. 点数化する意味
各画面について、5段階で点数化するのも有効だと思っている。
観点は以下である。
目的明確度
主要アクション明確度
情報量適正度
導線整理度
初見ユーザー理解度
サービスイン適合度
点数化すると、感覚論だけでなく、優先順位を付けやすくなる。
たとえば、ある画面が以下のような状態なら、かなり危険である。
目的明確度：2
主要アクション明確度：1
情報量適正度：2
導線整理度：1
初見ユーザー理解度：1
サービスイン適合度：2
こういう画面は、単なる見た目改善ではなく、P0/P1として扱うべきである。
12. サービスイン初期では、機能を前に出しすぎない
サービスイン初期に大事なのは、何でも見せることではない。
むしろ、最初は絞るべきである。
ユーザーが最初にやるべきこと。
中心になる体験。
最低限確認すべき情報。
次に進むための導線。
これだけを分かりやすく出す。
将来機能、補助情報、詳細データ、ランキング、細かい履歴、管理寄りの導線などは、必要に応じて下げる。
全部をトップレベルに出すと、サービスの魅力が伝わるどころか、逆に分かりにくくなる。
機能が多いことを良いことと評価しない。
これが大事である。
13. 今回の結論
導線カオス問題は、単なるUIの見た目問題ではない。
これは、画面設計、情報設計、導線設計の問題である。
各画面に操作できる選択肢が多すぎる。
画面ごとの主要目的が分かりにくい。
本来その画面で何をすればよいのかが直感的に分からない。
リンク、ボタン、カード、補助情報が多く、導線がカオス状態になっている。
情報量が多すぎて、重要な操作が埋もれている。
この状態では、機能があっても使われない。
だから今、確認用端末を使って、各画面の目的と導線を棚卸しする。
見るべきなのは、バグだけではない。
人間が触って迷うかどうか。
初見で何をすればよいか分かるか。
主要アクションが見えているか。
情報量が過剰ではないか。
サービスイン初期に本当に必要なものだけが前面に出ているか。
これを確認する。
今回の試験で出てくる指摘は、単なるUI改善ではない。
サービスイン前のP0/P1整理として扱うべきである。
機能を増やすフェーズから、画面の目的を絞るフェーズへ。
ここを越えないと、人に見せられるサービスにはならないと思っている。
0 件のコメント:
コメントを投稿