アプリ開発も、「無駄」を楽しめたら最強。回り道で見つける、使いやすさ🗒️
TomokiImaizumiイベントの詳細画面に「申し込む」ボタンがある。開発した側から見ると、参加したい人はそこを押せばいい。けれど、初めて使う人は、その手前で「自分も参加できるのかな」と考えているかもしれません。
ボタンを見やすくするつもりで開いた画面を、あえてイベント一覧からたどり直す。そうすると、手を入れたい場所が変わってくることがあります。まず伝えたいのは、ボタンの位置よりも、誰が参加できるのかという情報かもしれないからです。
僕は音楽コミュニティ「MMM」を運営しながら、音楽仲間が集まるWebアプリ「BeMyStyle」を開発しています。イベントを準備する側と、アプリを作る側。両方を行き来していると、同じページでも、見る人によって気になるところが違うと感じます。
noteでは「人生、『無駄』を楽しめたら最強」というテーマで、暇や回り道を楽しむことについて書きました。今回はそのテーマを、アプリを作る日々に引き寄せてみます。作業の手を止める時間、触ってみて初めて分かること、現場でふと出た質問。どれも、開発の予定表では小さく見える時間です。
目次
- 暇を楽しむ｜仕様を決める前に、画面を一周する
- 無駄を味わう｜小さな試作で、画面の順番を比べる
- 回り道で発見する｜現場の質問を、次の改善につなげる
- 改善を確かめる｜公開前に、いつもと違う条件で触る
- 余白を残す｜作り続けるための、小さな開発習慣
1. 暇を楽しむ｜仕様を決める前に、画面を一周する
開発をしていると、時間が空いたら、つい積んでいたタスクを一つ進めたくなります。表示を直す、テストを追加する、次の機能の調査をする。手を動かしていると、今日はここまで進んだと区切りをつけやすいですよね。
そこで、ときどきやってみたいのが、直すものを決めずに、自分のアプリを触る時間をつくることです。
たとえば金曜の夜、初めてセッションに行こうとしているギタリストのつもりで、スマホからイベント一覧を開きます。予定が合うイベントを探し、会場を見て、参加できるかを確かめる。画面の見た目を採点するより、次にどこを押したくなったか、どんな疑問が浮かんだかに目を向けます。
開発者のアカウントには、参加済みのコミュニティや管理者だけに見える情報があります。普段の自分のアカウントで試すと、初めての人が出会う画面を通り過ぎることがあります。確認には検証環境を使い、未ログインや参加前の一般ユーザーなど、見たい場面に合う状態から始めます。
10分だけ確認するなら、こんな流れです。
- 「初めて参加するイベントを探す」など、やることを一つだけ決める。
- 一覧やトップページから始め、普段使う端末でたどってみる。
- 手が止まったら、画面名と、そのとき知りたかったことを一行で残す。
たとえば「詳細画面の参加条件を読んだあと、自分が対象か確かめるために別のページを探した」。ここまで書けると、あとから何を検討するかが具体的になります。迷うところがなければ、そのまま閉じてもいい。空いた時間を毎回チケットに変えようとすると、せっかく気軽に見て回れる時間が、次の仕事になってしまいますからね。
まとめの一言
画面を直す前に、初めて使う人のつもりで一周してみる。
2. 無駄を味わう｜小さな試作で、画面の順番を比べる
「初参加の人に、参加できる条件が伝わりづらい」という仮説が立ったとします。すぐに実装へ入ると、文言を考えるのと同時に、テンプレートや余白を直し、テストも調整することになります。時間をかけて作った案ほど、あとから順番を変えたくなったときに腰が重くなることもあります。
そんなときは、画面のスクリーンショットにメモを重ねるくらいの試作がちょうどいいです。
たとえば、複数のコミュニティが対象のイベントで、参加条件をイベント名の下に置く案と、申し込みボタンの近くに置く案を並べます。文言もボタンも同じにして、位置だけを変える。初めて見る人には「このイベントに自分が申し込めるか、どこで確認しますか」と聞いてみます。先に正解の場所を示さず、視線や操作の順番を見ていると、説明を置く場所の判断材料になります。
完成させる前に、確かめたいことを一つに絞る。
ここで見たいのは、たとえば「参加条件に気づけるか」です。どちらのデザインが好きかを聞くと、配色や文字の好みにも話が広がります。もちろん見た目も大切ですが、今回の迷いを解くには、どこを見て何を理解したかを知りたいところです。
比べた結果、条件の位置より文言が難しそうなら、次は位置をそろえて言い方だけを変えてみる。「対象コミュニティ」のような機能の用語を、行動が分かる言葉に言い換える余地もあります。たとえば「以下のいずれかのコミュニティに参加している方が申し込めます」なら、自分が当てはまるかを考えやすくなります。
一人の反応から、全員の使い方までは分かりません。それでも、作る前に一度見てもらうと、自分の想像と違ったところを手がかりにできます。使わなかった案も、その違いを知るためには役に立っています。
まとめの一言
迷っているところだけを試作すると、作り込む前に選べる。
3. 回り道で発見する｜現場の質問を、次の改善につなげる
音楽セッションの案内には、集合時間や曲目、持ち物など、いろいろな情報が載ります。ひととおり書いてあっても、初参加の人がその場で知りたいことは、もっと具体的です。ギタリストなら「エフェクターは持っていったほうがいいか」。ボーカルなら「歌いたい曲があるとき、いつ希望を出せばいいか」。
こうした質問を受けたら、まず、その人が安心して参加できるように答えます。開発のヒントになるのは、その少しあとです。案内に書いてあるのに聞かれたなら、見つけにくかったのかもしれない。書いていなかったなら、主催側が当たり前だと思っていたことに気づくきっかけになります。
ここで、質問をそのまま機能の名前にしないようにしたいです。「希望曲の出し方が分かりません」と聞いて、すぐに新しい入力フォームを作ると、すでにある機能と入口が二つに分かれることもあります。まず、その人はどのページを見て、次に何をしようとしていたのかを確かめます。既存の「リクエストする」というボタンがあっても、初めて来た人には、何をリクエストできるのかまで伝わっていないかもしれません。
現場の気づきを持ち帰るなら、メモはこの三つ。
- 場面 初参加の人が、イベント詳細を見ていた。
- 疑問 希望曲を出せるか、いつまでに出せばいいかが分からなかった。
- 次に試すこと リクエストの入口付近で、対象と締切が伝わるようにする。
原因がまだ分からないところは、仮説として残しておきます。別のイベントで同じ質問が出るか、案内を少し直したあとに質問の内容が変わるかも手がかりです。逆に、イベントごとにルールが違うなら、アプリの共通文言で言い切るより、主催者がイベントごとに説明できる場所があるほうが合う場合もあります。
イベント当日には、進行表にない短いやり取りがたくさんあります。アプリの中で拾いにくい「どこで不安になったか」が、そのやり取りには見えることがあります。質問してくれた人と同じ画面を眺める数分が、次に作るものを変える。コミュニティ運営と開発を両方やっていて、面白いところです。
まとめの一言
質問の答えと一緒に、質問が生まれた場面も覚えておく。
4. 改善を確かめる｜公開前に、いつもと違う条件で触る
変更が入って、自分のアカウントで動いた。ここまでくると早く届けたくなります。でも、参加条件に関わる変更は、使う人の立場によって見える画面や、できる操作が変わります。ここは少し時間をかけたいところです。
たとえば、二つのコミュニティが合同でセッションを開催するとします。ルールが「どちらか一方に所属していれば申し込める」なら、主催側のコミュニティに入っている人だけで確認を終えると、もう一方にだけ所属している人が申し込めるかは分かりません。両方の人で、同じイベントに対して同じように参加できるかを試します。
この例なら、検証環境で次の順に確認します。
- 主催側だけに所属している人と、共催側だけに所属している人で、それぞれイベントの詳細から申し込む。
- どちらにも所属していない人で、参加できない理由が画面に出るか、申込処理も拒否されるかを確かめる。
- 以前からある単独開催のイベントで、従来の参加条件と申込操作が機能するかを確認する。
画面に出る案内と、実際にできる操作をセットで見る。
画面でボタンを隠すだけでは、申込処理の側で参加条件が守られていることまでは確認できません。開発者はサーバー側でも条件を判定し、その条件を満たさない操作を受け付けないことをテストします。利用者にとっては、申し込めなかったときに理由が分かることも大切です。案内と処理の両方が、同じルールを伝えているかを見ます。
ここで書いたのは、変更の見方を説明するための一例です。実際には、機能ごとのルールに合わせて確認する立場やデータを選びます。仕様を増やすたびに全部を手で試すのは大変なので、繰り返し確かめたい判定は自動テストに置き、表示の分かりやすさや画面をたどる感覚は実機で見る。両方に役割があります。
まとめの一言
いつものアカウントで動いたら、次は別の立場で同じ入口を通る。
5. 余白を残す｜作り続けるための、小さな開発習慣
個人開発で面白いのは、作ったものを自分でも使い、使ったその日に「ここ、もう少し分かりやすくできそう」と考えられるところです。ただ、浮かんだことを全部その週にやろうとすると、仕事のあとも週末も、アプリを開くたびに宿題が増えていきます。
だから、改善する時間と、ただ触ってみる時間を分けて考えます。今週は参加条件の文言を見直す。次に検証することはメモに残しておく。日曜に少し余裕があったら、スマホでサイトを一周する。そこで気になった箇所も、急ぎでなければその場で直さず、次の作業を決めるときに見返します。
次の開発日には、これくらいから始められます。
- 今週届けたい変更を一つ決める。たとえば、イベント詳細で参加条件が分かるようにする。
- 別に10分だけ取り、普段とは違う立場で画面を触る。何も見つからなければ、そこで終える。
- 次に試したいことが見つかったら、「誰が・どの場面で・何に迷ったか」を一行残す。
一度メモにして手を止めると、次に開いたとき、前より少し引いて見られることがあります。改善すべきだと思っていた箇所が、その日の自分には気にならないかもしれないし、イベントがある週だけ起きる困りごとだと分かるかもしれません。判断する材料が足りないなら、次に見る場面を決めておけます。
BeMyStyleを作っていると、僕にとっては見慣れた画面が、誰かにとっては「初めて人と音を合わせる日」につながる入口なんだと思うことがあります。その人が一歩踏み出すところまで想像すると、画面を開き直す時間も、イベントで足を止めて話を聞く時間も、案外好きになれるんですよね。
忙しい日ほど、まっすぐ実装に入りたくなるものです。そんな日に、たまにはコードを開く前に、イベント一覧からゆっくりたどってみる。その回り道で見つけた一行が、誰かの「参加してみようかな」につながったら、開発者としてうれしいです。
まとめの一言
作る予定のそばに、触ってみるだけの時間を残しておこう。
