Product
新しいアプリを開いて、起動直後に権限ダイアログが3連続で出ると、私は反射で閉じてしまいます。
私自身それを何度もやりました。あとで機能を使おうとして「設定でマイクを許可してください」と出ると、後悔と苛立ちが同時に来る。文脈がないまま決めたことを、後で自分で直すことになるからです。
だから Reso のオンボーディングでは、最初に一つ決めました。初回体験をプレッシャーにしないこと。
問題は「使い手が許可したくない」ことではなく、だいたい次の2点です。
1. なぜ必要なのかが分からない
2. 連続ポップアップは信頼ではなく圧力を生む
友だちのために作る
Reso の最初のプロトタイプを作ったとき、オンボーディングはあまり気にしていませんでした。自分は全部分かっていたからです。けれど友だちに配り始めたとき、感覚が変わりました。
大切な人のために作るなら、体験はやわらかくあるべきだと思ったんです。押しつけない。要求しすぎない。
初対面でいきなり「電話番号は？ どこに住んでる？ 仕事は？」と聞かないのと同じです。そんな始まり方は誰も好きじゃない。
設計原則
最終的に、指針は2つに絞りました。
- 不快感を最小化する: 急がせない。畳みかけない。呼吸できる余白を残す。
- 大事な機能は取りこぼさない: 摩擦は減らしつつ、重要情報は確実に伝える。
このバランスには、私が通っている即興クラスの影響もあります。場の空気を読む、エネルギーを合わせる、無理に場面を押し切らない。
実装したこと
Reso は正常に動くために、マイク権限と約2GBの ML モデルが必要です。最初に求めるには重い。
だから、最初には求めません。
- 必要な瞬間に1つだけ: マイク権限は、実際に録音しようとしたタイミングでだけ要求。文脈が明確です。
- それ以外はバックグラウンド: 触っている間にモデルを静かにダウンロード。進捗バーで操作を止めない。確認したい人向けに控えめな表示だけ。
- Graceful degradation: モデル準備前でもアプリは動く。少し遅いだけ。今何が起きているか（"0.3x speed - optimizing..."）を表示し、作業は続けられます。
仕上げで効く部分
ここまで来るには反復が必要でした。友だちが debug ビルドを入れ、残すバージョンで迷い、エッジケースに当たる。オンボーディングに想像以上の時間を使い、「心地よい」「押しつけがましい」「壊れて見える」の境界を検証し続けました。
目標はずっと同じです。箱を開けたら、もう動いている。エレガントでミニマル。必要なときは居て、不要なときは見えない仕事相手のように。
最高のオンボーディングは、オンボーディングに見えません。アプリが最初からあなたを分かっているように感じられることです。
これは宣伝ではなく、作りながら実際にはまった落とし穴の記録です。