使いやすいアプリを作るための、とても簡単で、確実な方法があります。
それは、ユーザの問い合わせに対応することです。具体的に言うと、問い合わせが気軽にできるようなUIにして、そこで得た情報源を元にUIを分かりやすく改良していく。(機能追加とはまた別の話)
ただ、直感的に感じるように、これは手間がかかるのでたくさんの人は逆のことをしようとする。つまり、ユーザヘルプを設置して、問い合わせ先は出来るだけ発見しにくい洞窟の奥深くに設置する。
でも、問い合わせには、アプリの利便性向上につながるヒントが豊富に隠されています。ユーザがどんな問題やニーズを持っているかのヒントもザックザック出て来ます。ザックザックです。
アプリ開発にとって、やったことがいい事は星の数ほどあって、そのどれもをやろうとすると時間やお金がいくらあっても足りません。だから、”やったほうがいい事”の優先順位は常に意識して、メリットとそれにかかる負担を天秤にかけないといけない。
それにもかかわらず、”ユーザの問い合わせに答える”という、直感的に開発側が一番避けたがることが、実は一番コストパフォーマンスがよく、楽チンだという結論に達しました。
もちろん、UIがクールで、死ぬほど使いやすくても、誰も欲しがらないモノはたくさんありますよね。
ただ、今回は話を簡単にするため、欲しがる人がいるという前提で、アプリの使いかってや分かりやすさをどう向上させていくかに絞って書いてみます。
リリース前の段階
リリース前は誰も問い合わせしてこない。なぜかというと、まだリリースしてないから。
結果的に、この段階では開発側のUI設計能力や経験に大きく左右されます。なので、この段階は楽チンではないんです。
できることといえば、なんでも出来るアプリを作らないようにすること、一つの強みに絞ること、周りの人に説明せずに触ってもらってよく観察することでしょうか。
他には、機能やボタンの数を減らすこと、標準的なUIに出来るだけ従うのも重要です。
口でいうのは簡単なんですが、どれもがとても難しい。。そもそも経験や知識が必要なうえに、それぞれの決断でかんたんな正解はないからです。トレードオフの連続です。
ここで重要なのは、UI設計ではトレードオフが無数にあり、優先順位がリリース前には困難だということです。
僕も3年ぐらいアプリ作っているけど、未だにリリースしたアプリの改良点は山済みで、ユーザフィードバックがない段階で使いやすいUIを作るのはかなりムズイ。
というわけで、この記事の趣旨である、簡単な方法とは話がずれてくる。この段階での話は昔書いてたので良ければ参考に。
*参考記事
使いやすいiPhoneのUIを作るために気をつけていること
UI設計の優先順位がリリース前では困難
UI設計における優先順位はリリース前ではすごく難しいんです。
例えば、タイムラインの更新をPullToRefresh（画面を引っ張るやつ)でやるか、右上にわかりやすく更新ボタンを設置したほうがいいか。
設定画面へのボタンはどの位置がいいか。ボタンは画像だけにするか、文字だけにするか。
ボタン文字はわかりやすく説明的にするか、アプリ内のスペースを取りすぎないよう短く簡潔にするか。どの部分をダイアログ付きで詳しく説明するべきか、どこまでがやりすぎで逆にうっとうしくなるか。
どの決断もトレードオフがあり、アプリを使うユーザ層によって、バランスの取り方が変わってくる。
この段階の決断は、経験や知識である程度の精度まで高められるんだけど、リリースするまでは予測できないことがはるかに多いんです。
リリースしないと、どういったユーザ層が本当に使うかわからないんです。そして、ユーザ層が正確にわからないと、UI設計の判断も正確に下せない。
つまり、最適なUIを設計するには、どういうユーザ層に使われるか未来を予測しないといけない。未来なんて誰にも予測できません。
だから、リリース前に完璧なUI設計なんて出来ると思い込まずに、早めにリリースして、ユーザからの質問や要望を聞きながら改良していくのが一番かんたんで、精度も高くなります。
楽チンコースに進むため、機能を削りまくり、荒削りでいいから早めにリリースして、問い合わせもらいながら開発できる段階にさっさと進みましょう。
問い合わせの数で優先順位を決定する
さて、無事リリースできたとします。
リリース前には、「あそこもっと説明したほうがいいかな？」とか「あのボタンは気付かれるかな？」とか、いろいろ懸念事項があったと思います。でも、人気が出る可能性も分からない段階で細部を詰めることはやめ、早めにリリースしたとする。
リリース前の、UIを向上させる改良点のTODOリストの中で、どこから手をつけていくかの優先順位は曖昧です。
それらの悩み事が、ユーザからの問い合わせがくるようになった途端に一気にわかりやすくなります。
なぜかというと、ユーザからの問い合わせが一番多い順に改良していけばいいだけなんです。とても簡単。専門知識も経験もいりませんね！
これならドナルド・ノーマンやカーネマンの本を読まなくてもできる、簡単な判断基準です。
僕の話をすると、今まで作ってきたアプリで多かった質問は、有料版へのアップグレード関連でした。やっぱりお金を払う前はみんな不安になるようです。
例えば、確定申告の帳簿入力アプリTaxnoteでよくあったのが、「機種変更したけど、もう一度有料版買う必要ありますか？」とか、「iPhone版でアップグレードしたけど、iPad版も別料金ですか？」とか、「月額課金ですか？」などです。
もちろん、ヘルプなんて誰も読まないので、流れの中で分かってもらえる方法をいろいろ考えました。
シンプルな方法として、アップグレードボタンを押した時に下記のようなメッセージを表示することにしました。
「有料版では月15件の入力制限がなくなります。お支払いは一回のみ。iPhone・iPad版どちらかで購入すれば片方は無料です。一度購入すれば、機種変更時も無料でアップグレードできます。」
こうした後は、かなり同じ質問が減りました。これでも、まだわかりづらいという人もいるので、もう一歩行きたい。
改良してみて、以前来ていた問い合わせが来なくなったらよい兆候。まだ同じような問い合わせがくるなら、もっと分かりやすくする余地があるということです。
こうして、よく質問される部分からUI設計を改良し、質問がこないぐらいになるまで工夫していくと、効率的に重要な部分から手をつけていける。
想像もしなかった改善点に気づく
上記で説明した部分は「どこから手をつけていくかを知ること」でした。でも、アプリの改善でもっと重要なのは、「自分が想像もしてなかった改善点に気づく」という部分です。
これはそもそも自分の想像外の事なので、事前に準備できない要素です。他人から指摘されて、「ああ、そうか！ここがわかりにくかったのか！」となるところ。
実際アプリの問い合わせや質問の内容の95パーセント以上は「ああ、やっぱりそうですよね、ここ改善しないといけないよな。。」と想定の範囲内の事柄なんです。
でも、たまーに、5パーセントぐらいの確率で、「え、そういう視点があったのか。。」とか、「なに、そこで詰まるのか。。」とか、自分の想像もできなかった問い合わせがきます。
これは本当に貴重なフィードバックで、とてもとても重要なんです。
なんで重要かというと、自分の想像外の領域を拡張してくれて、アプリを新しい角度から使いやすくするキッカケとなる。さらに、想定してなかった部分だから、シンプルな解決策が見つかることが多いのです。
事前に想像できた部分なら、そこのUIを改良することに時間がかかるなどの理由で後回しにしていることが多いのです。例えば、アニメーションを実装したら分かりやすいけど後回しにしたとか。
だから、事前に想像できた部分は、理由があって後回しになっていることが多い。
でも、自分の想定外のことなら、とても単純な解決策でさくっと利便性が向上することもある。例えば、メッセージの単語を少し工夫するだけとか。
気づかれてない機能を発見する
問い合わせあるあるの一つにこういう場面があります。
ユーザ「Aという機能が欲しいです」
開発側「Aという機能はすでにありまして、~という画面の~というボタンを使うとできます。」
というような、すでに実装しているのに、その機能が気づかれてないという事態。
気づかれない機能はないのと一緒でもあるし、あまり多くの機能を追加できないアプリの中において、厳選された機能が気づかれないのは大いに問題です。
こういう問題点も問い合わせの数でよくわかります。
僕が作っているZenyという家計簿アプリでよくある要望に、「カテゴリの並び替えができると嬉しい」というのがあります。
そして、アプリ内にはカテゴリの並び替え機能はあるのです。
*下記の画面でいうと、右上の編集ボタンをタップすると出来る。
これはセルの長押しとか、いろいろな選択肢の中から、iOSの標準UIがベターだろうと思ってこうなったんだけど、気づかない人が大量にいます。途中、ダイアログで説明するように改良したけど未だにくる。
こうなると、同じような問い合わせがこなくなるまで、もっとよい方法を考えようという認識ができます。
今考え中なのは、編集ボタン名を「カテゴリの編集」という名前に変えるとか、いくつか検討中です。
実装予定機能の事前調査にも
例えば、アプリにこういう機能をアップデートでつけたいなあと思ってたとする。
そんな時、問い合わせで要望が多いと、そのアップデートにお墨付きができたも同然です。「やはり必要だったか！」と。
逆に言えば、「こういう機能つけたいな」と思っている機能に対して要望がなかったら現時点では強い要望はないともわかる。
まあ、ユーザが想像してなかった便利な機能という可能性もあるので、最終的な優先順位はこれだけでは決められないんですが。
機能要望が来た時、「こんなふうに実装しようと思っているんですが、これで使えそうですか？」と、こちらから逆質問することもできる。
これ、こんなチャンスは普通だとなかなかないです。
自分からユーザインタビューをしようとしたら、アプリのターゲットユーザ層を探して、無理やりつかってもらって感想を聞くとか、すごく時間もコストもかかるわけです。
お金払ってターゲット層かどうかも分からない社外の人にユーザインタビューするより、遥かに効率がよくてお金もかかりません。
開発戦略の貴重な情報源
ここまで説明していたように、ユーザからの問い合わせはアプリを改善する上での重要な情報源となるので、開発に関わっている人間が直接対応するのがベストであります。
よく、新規アプリや新規事業の相談を受ける時、サポート対応は出来るだけしたくないとか、外注するとか言われるのだけど、すごく貴重な学びや情報源のリソースを自ら遮断することになっちゃう。
もう継続的な開発をしないアプリとか、リリースした後は放置する予定のものだと合理的なんですけどね。
もちろん、UIで解決できないサポート案件が多いサービスもあるので、サポートチームが別途必要な時もあるんですが、情報源として貴重だという事実は変わらないのです。
スタートアップぐらい本気レベルだと、創業者が常に電話対応するぐらいのレベルでいいと思う。Airbnbの創業者は常に頭にヘッドセットをつけて、ユーザからの電話対応ずっとやってたらしい。電話だとチャットよりもっと詳しくわかるし、こっちから質問するチャンスも多いですね。
僕はスタートアップみたいに仕事はできないので、1日に1-2回、ユーザのサポートメールに返信するっていうレベルですが。
問い合わせの設置方法
さて、問い合わせを具体的に設置する方法としては、外部のサービス使うのがお手軽で、なおかつ出来もよい。
自分のオススメはアプリだとHelpshift、WebサービスだとoLarkでしょうか。
*参考記事
アプリに組み込むヘルプサービス、Helpshiftがいい
その他の補足
今回は問い合わせがメインの話だったけど、問い合わせくる以前にユーザがアプリから離脱しているケースも多々あります。
さらに、問い合わせでは分からない要素もあるので、そんな時にデータ分析です。データ分析とユーザフィードバックの両輪でアプリを改善していきましょう。
*参考記事
Lean Analyticsとアプリ開発
また、機能要望に全部答えていたら酷いアプリになるので、ほとんどの要望にはNOという必要があるけど、どう返信すればいいのとお悩みの方に。
*参考記事
ユーザーの意見にNOと言うのは大切だけど、実際にどう言うかが難しい
サポートが必要ないぐらいアプリを改善するとか、ヘルプを読みやすくするということの投資対効果についてはこちら。
*参考記事
ユーザヘルプの改善は投資対効果がとても高い
*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。
