自分で作ったアプリを、初参加のつもりで使ってみる
TomokiImaizumiカラオケで自分の歌を録って聴き返すと、歌っていたときとは印象が違うことがあります。しっかり届けたつもりの歌詞が聞き取りづらかったり、力を抜いたところが意外と自然に聴こえたり。歌っている最中には気づかなかったことが、録音には残っています。
Webアプリの開発にも、似たところがあります。作っているときは、ボタンの意味も、次に開く画面も知っています。いざ利用する人の立場で画面を開くと、押す前に知りたいことや、操作のあとに確かめたいことがいくつも出てきます。
僕は音楽コミュニティを約15年運営しながら、イベントや活動を支えるWebアプリ「BeMyStyle」を開発しています。今回は、初めて音楽セッションに参加する人が、スマホでイベントを見つけて申し込むまでを題材に、作り手が自分のアプリをどう見直せるかを書いてみます。
📖 目次
- 作った人には、次の画面が見えている
- 初参加のつもりで、入口からたどる
- どこで迷ったかを、行動で残す
- 一箇所だけ直して、もう一度試す
- 参加者にお願いする前に、自分でやってみる
1. 作った人には、次の画面が見えている
音楽セッションの主催者は、会場に着いたらどの部屋に行くか、曲をどこで選ぶか、申し込み後に何を準備するかを知っています。案内を書くときも、その流れが頭にあるので、短い説明で伝わった気になりがちです。
一方、初参加の人は、申し込む前からいくつかの判断をしています。自分のパートに空きがあるか。曲は先に練習していくのか。参加費はいくらか。申し込んだら参加が決まるのか、それとも主催者からの連絡を待つのか。演奏してみたい気持ちがあっても、次に何が起きるか分からないと、ボタンの手前でいったん考えます。
たとえば、ページの下のほうに参加条件が書いてあっても、先に申し込みボタンが目に入れば、その時点で「自分も押していいのかな」と迷うかもしれません。開発側から見ると説明は掲載済みです。参加者にとっては、判断したい瞬間に見つかるかどうかが大切です。
ここで考えたいのは、その人はこの画面で何を決めようとしているのかということ。イベント一覧では「自分が行けそうな会か」、詳細ページでは「参加するために何が必要か」、操作の直後には「申し込みはどこまで進んだか」。画面ごとに答えるべき問いが分かると、どの情報を先に見せるかも決めやすくなります。
まとめの一言
作り手が知っている流れを、参加者が知りたい順番で見直してみる。
2. 初参加のつもりで、入口からたどる
開発中は、確認したい画面のURLを直接開いたり、ログイン済みのアカウントで操作したりすることがあります。ひとつの画面を素早く確認するには便利です。初参加の体験を見直すときは、イベントを知ったところから始めると、画面の間にある迷いまで見えてきます。
たとえば、SNSで初心者セッションの案内を見つけたギタリストを想定します。スマホを片手に、仕事帰りの電車の中でページを開く。時間は数分。自分が参加できるかをその場で判断したい。こうして場面を決めると、開発者として見慣れたページにも、別の目で向き合えます。
📱 申し込みまでを確認する手順
- 入口を決める。 SNSの告知リンクやイベント一覧など、参加者が実際に使う入口からスマホで開きます。
- 初参加に近い状態で見る。 ログアウト状態から始め、ログインが必要になったら検証環境の一般ユーザー用アカウントを使います。参加条件で表示が変わるなら、条件を満たす場合と満たさない場合を分けて見ます。
- 申し込む前の判断を確かめる。 日程や費用、参加条件、必要な準備をどこで見つけたか記録します。ボタンを押す直前に何が起きると思ったかもメモします。
- 操作の結果まで確かめる。 テスト用のイベントで操作し、受付や承認待ちなど、その場の状態と次の行動が分かるかを確認します。ログインを挟む場合は、もともと見ていたイベントに戻れるかも見ます。
同じ申し込みでも、管理者の画面と参加者の画面では、見える情報やできることが変わります。実際に使う人の権限と入口をそろえるだけでも、普段の確認では通らない道を歩けます。
まとめの一言
画面を開くところから申し込んだあとまで、一人の参加者として通してみる。
3. どこで迷ったかを、行動で残す
アプリを使い直して「なんとなく分かりづらい」と感じたら、あとで見返せるように、指が止まった瞬間を一行で残します。
たとえば、「参加できるパートを探して詳細ページを下までスクロールし、いったんイベント一覧に戻った」。ここまで具体的に書くと、どの情報をどこで探したのかが分かります。「ページが長い」という感想だけでは、文章を短くするべきか、募集パートを上に出すべきか、判断しづらいところです。
開発者本人が使うときは、画面を開く前に答えを思い出せてしまいます。そこで、初めて触る人にも、同じ場面を試してもらいます。スマホでイベントの詳細を開いてもらい、「ギターで参加できそうか、確かめてください」と目的だけ渡します。途中で指が止まったら、どこを探しているか、何が分かれば先へ進めそうかを聞きます。操作方法を教えるのは、そのあとです。
メモには、見えた行動と、その理由についての仮説を分けて書きます。たとえば「申込ボタンを押す前に一覧へ戻った」は見えた行動です。「募集中のパートが分からなかったのかもしれない」は仮説です。本人に聞いてみたら、日程をもう一度確認したかっただけかもしれません。同じ動きでも、理由が違えば直す場所は変わります。
迷いなく進めた箇所も、同じように書き残します。参加費を一目で見つけられたなら、その見せ方は残す理由があります。次に変える部分と、今のままで役に立っている部分がそろうと、手を入れる範囲を絞れます。
まとめの一言
「分かりづらい」と感じたら、どこで何を探したかまで記録する。
4. 一箇所だけ直して、もう一度試す
試してみると、ボタンの文言も説明の順番も、気になるところが一気に出てきます。そこでまず、参加するかどうかの判断に関わる箇所を一つ選びます。
たとえば、募集パートが説明文の途中に埋もれていて、申し込み直前まで自分が参加できるか分からないとします。この場合は、募集パートの表示を申込ボタンの近くに移す案が考えられます。変更したら、別の初参加者に同じ入口から見てもらい、ボタンを押す前に募集パートを見つけられたか、自分が参加できるかを判断できたかを確かめます。
画面の改善は、次のようにメモしておくと、あとで見直しやすくなります。
| 確認すること | 記録の例 |
|---|---|
| どこで止まったか | 募集パートが分からず、申し込みの手前で一覧に戻った |
| 何を変えたか | 募集パートを申込ボタンの近くに移した |
| 次に何を見るか | ボタンを押す前に、自分のパートで参加できるか判断できたか |
歌の練習でも、サビの息継ぎとテンポと声量を同時に変えると、何が聴こえ方に効いたのか分かりにくくなります。アプリでも、一回の確認で試すことを絞ると、次にどこを見ればいいか決めやすくなります。
少人数で試した結果は、次の修正を考える手がかりです。たとえば、一人が募集パートを見つけられても、別の人は「募集終了」と「申込締切」の違いに迷うかもしれません。そのときは、新しく分かったことを残して次の確認に進みます。
まとめの一言
一つ変えたら、見た目より先に、参加者がその場で判断できたかを見る。
5. 参加者にお願いする前に、自分でやってみる
イベント運営をしていると、参加者に事前に確認してほしいことが増えていきます。開催場所、集合時刻、曲の準備、当日の連絡先。どれも大切なので、つい案内文に一文ずつ足していきたくなります。
そんなときは、案内を足す前に、自分のスマホで一度たどってみます。初めての会場に向かうつもりでイベントページを開いて、集合場所を探す。申し込んだ直後の画面を見て、曲を選ぶ場所まで行けるか確認する。それで迷ったら、読む人に注意を促す言葉を増やす前に、必要な情報を、必要になるところへ置けるか考えます。
自分でやってみた経験は、改善を誰かに説明するときにも役に立ちます。たとえば「申し込み後、曲を選ぶ場所を探してイベント詳細に戻った。受付の案内に曲選びへのリンクがあれば、続けて準備を始められそうだ」。どこで止まって何を変えたいかが具体的なら、主催者とも開発者とも、同じ場面を思い浮かべながら話せます。
音楽のセッションで、演奏が止まったら、まず主催者自身が次にどこから合わせるかを示す。アプリでも、参加者にやってほしい手順を、まず自分でたどる。僕にとって「背中で語る」は、そんな身近な行動です。
初めてのセッションに申し込む人の楽しみは、その先にあります。知らなかった人と音を合わせて、練習してきた一曲を一緒に演奏すること。その時間に向かって気持ちよく準備できるように、BeMyStyleでも、参加者が最初に開く画面から考えていきたいと思います。
まとめの一言
誰かに使ってほしい流れほど、まず自分で入口から歩いてみる。
