1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、かなり大きな気づきがあった。
それは、体験設計の考慮が甘かったということだ。
画面の見た目を良くする。
アイコンを改善する。
導線を整理する。
ボタン文言を直す。
自動テストを追加する。
こうした改善はもちろん重要である。
ただし、それ以前に、その画面がユーザーにとってどんな体験であるべきかをもっと明確にしなければならなかった。
内部処理としては、すでに結果が生成されている。
内部的には、保存済みデータをもとに画面を組み立てている。
開発者目線では、それを「リプレイ」「再生」「結果からの表示」と呼びたくなる。
しかし、ユーザーにとって初めて見る体験は、そうではない。
ユーザーから見れば、まさにその瞬間に初めて体験するイベントである。
そこに開発者都合の文言やUIが出てしまうと、一気に没入感が壊れる。
元の議論でも、初回体験と2回目以降の見返しを分ける必要性、そして内部実装都合を通常画面に出さないことが整理されていた。
2. 開発者視点では「再生」でも、ユーザー視点では「初体験」
今回の反省点はここである。
開発者視点では、すでに生成された結果を表示している。
だから、つい「再生」「リプレイ」「プレイヤー」のように考えてしまう。
でも、ユーザー視点では違う。
初めてそのイベントを見るユーザーにとっては、それは過去データの再生ではない。
今まさに、自分が結果を知る瞬間である。
ここを間違えると、画面全体が安っぽくなる。
たとえば、初回体験なのに、
リプレイ
再生
プレイヤー
簡易表示
結果から生成
ライブではありません
次フェーズ
のような文言が前面に出ると、ユーザーは一気に現実へ戻される。
「これはゲーム内の体験ではなく、開発中の確認画面なんだな」
と感じてしまう。
これはかなりまずい。
3. 実装の都合が画面に漏れていた
今回の問題は、単なる文言ミスではない。
実装の都合が画面に漏れていたことが問題である。
開発側からすると、内部的にどう表示しているかは重要である。
データがいつ作られるのか。
どの時点で結果が確定するのか。
画面側では何を受け取って表示するのか。
テストではどう再現するのか。
これは開発上は重要である。
しかし、それをユーザーにそのまま見せてはいけない。
ユーザーが見たいのは、内部処理の説明ではない。
ユーザーが体験したいのは、サービス内の世界である。
「これは確定結果を元にした表示です」
「これは実際のライブではありません」
「これは簡易リプレイです」
こうした説明は、開発者にとっては正直かもしれない。
しかし、体験設計としては弱い。
正直であればよい、という話ではない。
ユーザー体験として、どの文脈で見せるべきかが重要である。
4. 初回体験と2回目以降は分けるべきだった
今回もっとも重要なのは、初回体験と2回目以降の見返しを分けることだ。
初回は、ユーザーにとって結果を知る瞬間である。
だから、画面上は「今から見る」「見守る」「結果を知る」体験であるべきだ。
一方で、2回目以降は見返しでよい。
一度見た後なら、
もう一度見る
見返す
回顧する
振り返る
という文脈で問題ない。
つまり、同じ画面でも、ユーザー状態によって見せ方が違う。
初回は「体験」。
2回目以降は「回顧」。
この区別が必要だった。
これを区別しないまま、最初から「リプレイ」的に見せてしまうと、一番大事な初回体験を壊してしまう。
5. ユーザーごとの体験状態が必要になる
初回と2回目以降を分けるには、当然ながらユーザーごとの状態管理が必要になる。
そのユーザーが、そのイベントを初めて見たのか。
途中まで見たのか。
最後まで見たのか。
もう一度見返したのか。
こうした状態を持たないと、画面文脈を切り替えられない。
最低限、以下のような状態が必要になる。
まだ見ていない
見始めた
最後まで見た
見返した
最初から本格的なDB実装までやるかは別として、仕様としては必要である。
ここを設計しないまま画面だけ作ると、すべてのユーザーに同じ表示を出すことになる。
その結果、初回体験なのに見返し扱いになる。
あるいは、見返しなのに初回のように見える。
これは体験として不自然である。
6. 結果を先に見せすぎる問題
もう一つ重要なのが、結果のネタバレ問題である。
ユーザーがまだ初回体験を終えていないのに、別画面で詳細結果が見えてしまう。
通知や履歴や一覧で、先に結末が分かってしまう。
その後に体験画面へ行っても、もう驚きがない。
これはかなりもったいない。
もちろん、すべての画面で完全に結果を隠すのは大変である。
初期段階で一気にやると、影響範囲も大きい。
ただし、少なくとも主要導線では考慮すべきである。
未体験のものについては、詳細結果よりも「体験へ進む」導線を優先する。
体験後に、結果、詳細、記録、回顧を表示する。
この順番を守るだけで、かなり印象が変わる。
7. 操作UIも体験を壊すことがある
今回、文言だけでなく操作UIも見直す必要があると感じた。
たとえば、動画プレイヤーのようなUIが前面に出すぎると、体験ではなく操作ツールに見えてしまう。
速度変更自体は便利である。
一時停止も必要かもしれない。
最初から見返す機能も、2回目以降ならあってよい。
しかし、それらが初回体験の中心に出すぎるとよくない。
特に、開発者向けの「次フェーズ」のような操作は、通常画面に出してはいけない。
それは完全にデバッグ機能である。
一般ユーザー向けには、画面の世界観に合った言葉にする必要がある。
「再生」ではなく「見る」。
「プレイヤー」ではなく「体験画面」。
「次フェーズ」ではなく、そもそも通常画面には出さない。
こういう細部が、体験の品質を左右する。
8. 画面名も重要
画面名もかなり重要である。
内部URLやコンポーネント名は開発都合でよい。
しかし、画面上に出るタイトルはユーザー体験に合わせるべきである。
初回なら、初回体験としての名前にする。
2回目以降なら、見返しや回顧としての名前にする。
同じ内部画面でも、ユーザー状態に応じてタイトルを変えることは十分あり得る。
内部的には同じ実装でも、ユーザーに見せる文脈は違う。
ここを意識しないと、内部構造がそのまま画面に出てしまう。
9. AIへの実装指示にも体験設計が必要
今回の反省点は、AIへの指示にもある。
AIに対して、
「この画面を改善して」
「見た目を良くして」
「UI文言を直して」
だけでは不十分だった。
本来は、最初にこう指示すべきだった。
この画面は、ユーザーにとって初めて結果を知る体験である。
内部処理としては結果生成済みでも、画面上では初回体験として扱う。
開発者向け文言を通常画面に出さない。
初回体験と2回目以降の見返しを区別する。
ここまで書かないと、AIは開発者視点で実装してしまう。
AIは仕様に書かれていない文脈を、常に正しく補ってくれるわけではない。
だから、体験設計を言語化して渡す必要がある。
10. 見た目改善だけでは足りない
最近、画面のビジュアル改善も進めている。
アイコンや表示を良くする。
画面の見た目を整える。
スマホでも見やすくする。
これはもちろん重要である。
しかし、見た目が良くなっても、体験文脈が間違っていれば安っぽくなる。
どれだけ見た目を良くしても、初回体験なのに「リプレイ」と出ていたら台無しである。
どれだけ演出を入れても、「これはライブではありません」と出ていたら没入感は消える。
どれだけUIを整理しても、結果を先に見せていたら体験の意味が薄れる。
つまり、必要なのは見た目改善だけではない。
体験の順番、文脈、状態、ネタバレ制御、初回と回顧の区別である。
11. これはサービス品質に直結する
この問題は、細かい文言の問題ではない。
サービス品質に直結する。
ユーザーが初めて触る。
自分の関心があるイベントを見る。
結果を見守る。
ゴールや完了の瞬間を知る。
その後、結果やコメントや次の行動へ進む。
この一連の体験が気持ちよくつながるかどうか。
ここが弱いと、サービス全体が安っぽくなる。
逆に、ここがしっかりしていれば、内部的にはシンプルな実装でも、体験としてはかなり良くなる。
体験設計は、実装コスト以上に価値を生むことがある。
12. 今回の結論
今回の反省は、体験設計の考慮が甘かったということだ。
内部的に結果が先に生成されているからといって、ユーザー画面でそれを「リプレイ」「再生」「簡易表示」のように見せてはいけない。
初めて見るユーザーにとっては、それは初回体験である。
初回体験では、ユーザーに結果を先に見せすぎない。
画面上は、今まさに見ている体験として扱う。
2回目以降は、見返しや回顧として扱う。
開発者文言を通常画面に出さない。
デバッグ操作を通常画面に出さない。
便利機能はあっても、主役にしない。
これは、単なるUI修正ではない。
体験設計の修正である。
AIを使うと、実装は速い。
しかし、体験の思想まできちんと指示しないと、開発者都合の画面がすぐにできてしまう。
今後は、画面を作る前に、その画面がユーザーにとって何の体験なのかを定義する。
見る画面なのか。
初めて結果を知る画面なのか。
見返す画面なのか。
操作する画面なのか。
確認する画面なのか。
ここを明確にしてから、実装に進める必要がある。
今回の気づきはかなり大きい。
サービスイン前に気づけてよかったと思う。
