成功するアプリを開発する上で考えておくべきこと
要約:私たちは今年になって10,000ものアプリをダウンロードしました。そこで、私たちがどのようにアプリを発見したのか、どんな検証をしたのか、そしてアプリを作る上で学んだ教訓についてみなさんとシェアしたいと思います。アプリが失敗しないために行うべきToDOリストも用意しました。
今年、Brianと私は10,000以上のモバイルアプリをダウンロードしました。その過程でアプリを制作するにあたってやったほうがいいこと、やってはいけないことについて多く学んだのです。
この調査の主な目的は我々のサービスであるLinkTextingの開発の参考にするためでした。LinkTextingは、SMS、テキストメッセージからアプリのランディングページへ飛べるダウンロードリンクを生成することができるサービスです。
アプリのランディングページはユーザーがアプリの価値をすぐに理解できるシンプルなものでなければいけません。
LinkTextingはそういったことを可能にするサービスです。http://linktexting.comこのようなツールによってアプリ運用は少し楽になります。アプリに長期的な価値を生み出すための簡単な方法などありません。何百、何千ものユーザーと対話しながら開発し続けて流れた血と涙と汗が、本当にクオリティの高いアプリへの道のりを作っていくのです。
モバイルアプリ市場は、Brianと私が今まで調査に着手した中で、最も興味深い市場の一つであると思っています。
毎日500以上の新しいアプリがリリースされている
市場には、毎日500以上ものアプリがリリースされています。普段の生活の中で初対面の人に会う機会があれば、あまり有名ではないアプリで最も使っているものはどれかと尋ねています。特に、海外のアプリストアにアクセスできる外国人に聞くことが多いです。
アプリDL中の一コマ
モバイルアプリに1,200ドルを費やす
これにはそれぞれ私たちなりの理由があります。Brianはモバイルアナリティクスのベンチャー企業を持っており、その参考のために。そして私は単にテクノロジーが大好きだからという理由です。私たちのお気に入りの課金アプリをいくつか挙げましょう。
- 『SayHi Translate』
- 『Dropcam』
- 『Telegram』
- 『Venmo』
- 『1Password』
- 『Docusign』
- 『UX Companion』
- 『Timbre』
- 『AppStatics』
- 『Streak(CRMツール)』
- 『Helpouts』
どうやって調査するアプリを決めたのか
調査に使ったツールは以下の通りです。
私たちは出来るだけ多くの興味深いアプリを見つけてダウンロードするために、以下のアカウントを利用しました。
アプリを開発するベンチャーが大切にするべき10の教訓
初めのうちは重要な機能の設計だけにすること
アプリの設計に着手する際は、ユーザーにアプリを使ってもらう上でどの機能が絶対的に必要となるのかを考え、それ以外の機能は省きましょう。
例:私たちは長距離ライドシェアリングアプリの『Coride』と仕事をしたことがありました。そのアプリでは、メールアドレス、スタート地点とゴール地点の位置情報、そして日時を重要情報と決めました。その後、創業者であるAdamは価格も計算できるようにアプリを再設計し、ユーザーがアプリを使う上で大きな障壁となっていた「価格を推測する」必要性をなくしたのです。
メモ
次回以降に書く記事でアプリの設計におけるこれらのコンセプトやアクションをどのように適用するかついて詳しく話そうと思います。続きを知るにはLinkTextingをフォローしてくださいね。
簡単なUX調査を実施すること
http://ixdchecklist.comを利用してみてください。そこで、基本的なUXの基準をどれだけ満たしているか確認し、アプリの質をチェックしましょう。もしあなたのアプリが『ixdchecklist』において最低でも10点満点中5点も獲得できないのならば、あなたのシリコンバレーにおける存在感はアプリにメリットをもたらすほどではないと考えてよいでしょう。
自分のアプリを使い倒すこと
あなたの制作したアプリの全機能を使ってみましょう。リリース時には毎回、チームのメンバー全員で機能の利用をすべきです。自分たちが制作したアプリを利用してほしいと主張しない創業者にも会ったことがありますが、彼らと同じ空間にいることはいらだたしく感じます。
他社アプリのランディングページをベンチマークすること
あなたのアプリのランディングページをhttp://goodui.orgと比較してベンチマークしましょう。私はこのサイトを、シリコンバレーのランディングページの質と考えてベンチマークしています。
顧客が不満を簡単に報告できるようにすること
顧客が画面上のどこででも愚痴をこぼしたり、問題を報告できるようにしましょう。チーム全員で支援できるようにし、返信が遅れたらチームの人が謝るべきです!
実際に『linktexting』の顧客に対して反応が2時間以上遅れたときはいつでも、チーム全体の責任だと考えています。私たちは良いときに数分で報告に対し反応できていますが、問題を報告できないようになっているアプリもいくつか見つけました。
一番最初にアプリを使ってくれるユーザーを見つけること
『Reddit』はアプリをよく使ってくれる初期ユーザーを獲得するための素晴らしいサービスであり、リリースしたてのアプリを批評してくれるでしょう。『Quora』もまた素晴らしいサービスですが、乱用はせず、あなたが調査を通して発見したことやユーザーの振る舞いについての質問に答えるなど、価値をきちんと提供しましょう。これらのサービスを用いて、アプリを利用してくれているユーザーや問題点を調査してください。
マルチプラットフォーム対応を急ぎすぎないこと
私たちはこのタイミングを見極めることが非常に困難であるということを身をもって経験してきました。創業者が技術者でない場合はさらに見極めは困難でしょう。
アプリのレビューにお金を支払ったり、説明文でユーザーを誤解させたりしないこと
いくつかのアプリはこういったことをしているのではないかと疑っています。今のところ『Simpler』という連絡先を整理するアプリが、レビューに対してお金を支払っていると考えています。レビューを拾い読みし、アプリを自ら利用してみれば、サクラを使ってレビューを書いてもらっているかはわかります。
不確かなことは何か把握しておくこと
もしユーザーの行動についてわからないことがあるならば、行動を定義し、その結果を測りましょう。そうすれば次のリリースにおいて、そのデータをもとにデザイン変更の大きな決断ができます。また、もしあなたが基本的な問題点や数値、信頼区間(全体の平均(母平均)をある確率で含む範囲)を理解できれば、ユーザーテストの妥当性も把握することができるでしょう。
非プログラマの創業者ならば、経験面でプログラマの創業者より不利な立場になるのを覚悟しておくこと
残念ですがそういうものです。
アプリ開発に携わるすべての人が自分自身に問うべき簡単な質問
- ユーザー体験の始めから終わりまでを作り出すために、ユーザーから引き出す必要がある具体的な情報とは何ですか?
- 1日に少なくとも3回は自分のアプリを使いましたか?『LinkTexting』ではアプリをアップデートしたら毎回、最初から最後までアプリを使います。
- チームのメンバー全員が少なくとも1日に1回、または一定期間に1回はユーザーに話しかけましたか?ここでいう一定期間とは、ターゲットユーザーに合わせて設けられた合理的なタイムスパンを意味します。
- チームのメンバー全員が顧客からのフィードバックメールを見ましたか?
- はっきりとわからないことは何ですか?どうやったら自社アプリでわからないことをアナリティクスで分析したり、追跡できますか?
- 定期的にチームの他の人とアプリのアナリティクスのデータを見ましたか?
これら6つの質問に従わない場合の代償
- グループ写真を共有する『Cluster』というアプリは、アプリのより良いユーザー体験のために必須とは言えない機能を追加してしまい、のちに事業のピボットを余儀なくされました。
- 私たちはモバイルアプリ会社とのサポートメールを始め、創業者が知らなかった機能をアプリ内に発見しました。これは創業者がプロダクトに関わっていないという明確な証拠です。
- CEOが自分たちは最高のチームだと呼んでいて、顧客と「スーパーエンジニア」の「コミュニケーションレイヤー」として存在しているチームを見てきました。私たちはそこで時々「弊社のエンジニアは優先すべきタスクではない別のことに取り組み始めてしまう」という言葉を耳にします。このセリフは技術にうとい創業者にとっての危険信号であることが多く、エンジニアチームを疲労困憊させてしまう創業者にありがちなセリフです。
- 「コミュニケーションレイヤー」として存在しているCEOは機能しません。私たちは「ビジョン」や「プロダクトのロードマップ」を知っていると主張するCEOを見てきましたが、彼らは自分が知っていることを指図し、チームに困難な要求をするだけでした。一方、顧客のフィードバックは素晴らしいアプリを作るためのソースコードであるため、これをチーム内で共有することで誰もが協調して働きやすくなるのです。
- 友人であるBibs MobileのGalen Danzingerは、自身が作ったマラソン登録アプリに非常に複雑な機能を実装したがっていました。わたしたちは彼に、機能を制限して多くの人が参加登録しているイベントだけを表示するようにした時にユーザーが参加登録するのかどうかをテストしてみてはどうかを提案しました。結果はご察しのとおりですが、満員に近いマラソンイベントでは登録者が少なくなるということがわかりました。つまり、ユーザーは他の人を見ながら走るのは好まないということがわかったのです!
- 繰り返しになりますが、これはチーム全体でプロダクトのロードマップ決定の背後にあるソースコードを共有しようという話です。自社の分析基盤を理解していない創業者はだいたい無能であり、もし彼らが成功するようなことがあれば、それは最強のCTOがいるからでしょう。あなたはきっとこの記事の中で私たちが技術に理解のある創業者を好んでいるということに気が付くでしょう。
シンプルさを実現することの困難さ
これらの質問を自分自身に問うことで、非常に難しいこと、つまりシンプルさを実現したアプリに自然と近づくことができるでしょう。これら質問の一覧は、あなたがアプリを作り上げる経験の中で生じるすべての質問を網羅しているわけではありませんが、起こりうる問題の大半を処理してくれるでしょう。
この記事は、 Medium上の記事 " 10,000 Mobile Apps later and What we learned."を著者の了解を得て日本語に抄訳し掲載するものです。Repro published the Japanese translation of this original article on Mediumin English under the permission from the author.