アプリの公開前にしてしまいがちな6つの間違いとは

Hannah Levenson

HannahはAppseeのコンテントマーケティングマネージャー。

この記事はUsabilityGeekからの翻訳転載です。配信元または著者の許可を得て配信しています。

What You Wish You Had Not Done Before You Launched Your App (2017-04-27)

モバイルアプリの公開寸前で、今まで注いできたすべての努力を無駄にしてしまうような間違いをおかすときがあります。これらの間違いによって、ユーザー体験を完全に台無しにしてしまい、低い継続率や悪いレビュー評価をもらい、マネタイズの失敗などにつながってしまうのです。このような状況は、クライアントからの圧力や急速なエコシステムの変化、不十分なプロジェクト計画など、さまざまな原因で起こる可能性があります。

済んだことを後悔しても仕方ないと言う人もいます。ですが、簡単に防げたかもしれない間違いのせいで何ヶ月もの努力が水の泡になり、低評価のレビューばかりが投稿されたら大声で叫びたくなるでしょう。間違いのいくつかは比較的よく起こり得るもので、あなたが予想する以上に頻繁に発生しています。

この記事では、アプリ開発のプロが公開前によくしてしまう間違いについて、クロスプラットフォームの開発者の知見も交えながら紹介したいと思います。これらのアイデアによって、最悪の失敗を避けることができるかもしれません。

1. 機能を付けすぎる

多種多様な機能を提供することでユーザーの興味を引こうとするのはやめましょう。特にまったく新しいアプリであればなおさらです。アプリに過剰に機能を付けてしまうと、真逆の効果を生んでしまう可能性があります。ユーザーは多すぎる機能に困惑し、何をしたかったのか見失ってしまうかもしれません。

ユーザーは何かの目的を行うために、アプリをダウンロードしているということを忘れないでください。中核となる特定の機能に焦点を絞ることで、以下の3つのことを達成できるでしょう。

  1. ユーザーが確実に目的を達成できるようになる(結果的に継続率を高めます)。
  2. 不具合の可能性を最小限にできる(懸念すべき機能が少なくなります)。
  3. アプリの公開時期を早めることができる 

新しく公開されたアプリやその機能については、「少ないほど得るものが多い」と言えます。フリーランスのクロスプラットフォームアプリ開発者のJason Kneen氏は初版ではコアの機能だけに集中するべきだと述べています。

私がクライアントに伝えることの1つに、初版にもっとも必要なMVPに焦点を絞ることがあります。バージョン1.1の作業は、そのあとすぐに開始できるでしょう。クライアントは初版にたくさんのことを詰め込みすぎて、結果的にプロジェクトを長引かせてしまっていることがよくあります。アプリは早めに公開し始め、新しい機能はあとから随時アップデートしていくほうが良いでしょう。

2. 自分自身でアプリのベータテストを行う

ベータテストは、バグや反応のないアクション、正常系における問題などを発見するのに優れた方法です。通常、アプリ開発者は第三者機関や開発チームではない者を雇い、アプリのテストを行います。これが一般的な方法ですが、稀に完全に身内だけでアプリのテストを行い、ひどい失敗をおかすことがあります。締め切りまでの期間が短すぎるケースや、資金調達が不十分であるケース、開発者たちが身内のフィードバックがあれば十分だと考えているケースなど、さまざまな原因があるようです。

ですが、アプリの開発に携わった人たちはアプリのテストを行うのに適切ではありません。アプリは開発者のためではなく、特定のエンドユーザーのために作り上げてきたからです。開発者とエンドユーザーの間で、何が正しく機能していて、何がしていないのかという意見は一致するかもしれませんし、しないかもしれません。しかしここで重要なのは、意見が異なる可能性があるということです。ですから、リスクを取らずに、実際のエンドユーザーに対してベータテストを行うべきなのです。

またエンドユーザーにベータテストに参加してもらうことで、新たにクリエイティブなアイデアやアプリの機能に関する提案が生まれる可能性もあります。

3. 事前に決めるKPIと決めないKPI

KPI(重要業績評価指標)とは、アプリの成功を評価する指標のことです。さまざまなKPIが存在していて、進行度を記録して評価したり、アプリの成功に必要な変更の決断をしたりするのに使われます。

あなたは事前にKPIを決めていますか? もし決めているようであれば、どれを選んでどれを候補から外しましたか? もちろん、この質問に対する単純な回答はありませんし、どんな場合にも通用するような解決策もありません。アプリで何を達成したいのか、アプリを使ってユーザーにどのように行動してほしいのかという問題に、明確なビジョンを持っておく必要があります。これらが第一歩です。

たとえば、Wifi Analyzerのようなユーティリティアプリを作り上げるとします。このようなアプリでユーザーが長い時間を費やさないことは推測できると思います。ユーザーたちはアプリを起動させて、もっとも混雑していないチャンネルを探し、アプリを閉じるでしょう。ですからこの場合、アプリの使用時間は重要なKPIにはなりません。一方で、使用頻度は重要なKPIであると言えるでしょう。ユーザーに繰り返しアプリの利用を続けて欲しいからです。

ですが、事前に設定したKPIにこだわりすぎないようにしましょう。そうしてしまうと、どこかで重要になりうる指針を入手する機会を失う危険があります。進行度を測定したり情報に基づいて変更したりするプロセスは常に変わり続けるため、さまざまなKPIを取り入れられるよう視野を広く持つことが大切です。

4. 定性データを無視する

アプリを作り上げるとき、集めるすべてのデータには価値がありますが、すべてのデータを定量化して数字で表すことができるとは限りません。数字で表現することができないデータもありますが、それは決してアプリの開発に役立たないということではないのです。実は、それらの定量化できない要素によってアプリのユーザー体験が定義されます。

なぜユーザーたちはあなたが作ったログインフォームに苦労しているのでしょうか? なぜ支払い画面で購入をやめる確率が高いのでしょうか? このような疑問に答えるには定性データが必要になります。しかし、ただ対面インタビューから得たデータではなく、観測バイアスのないアプリでの実際の体験談から得たデータが必要なのです。

反直感的なUIの要素を特定する、クラッシュやバグを可視化する、反応のないアクションやユーザー体験の齟齬に注目するなど、このような定性分析は、すべて優れた製品を作る際の根本的な要素です。アプリの品質が高くなると、ユーザー体験はさらに繊細で独特になっていきます。公開前の期間にアプリを測る定性分析プラットフォームを利用することで、ユーザー個々人の体験をさまざまな側面から見ることができるようになります。これにより、アプリを大きく拡張させていく前に、効率的にバグをなくし、ユーザーの期待を正確に把握できるようになります。

5. ナビゲーションを真剣にとらえていない

ユーザーフローとユーザー体験の結びつきを強める、アプリのもう1つの重要な要素は、アプリのナビゲーションです。不十分なナビゲーションは、ユーザーのエンゲージメントに大きな影響を及ぼす可能性があります。たとえばある研究では、ハンバーガーメニューがユーザーのエンゲージメントを半減させたと言われています。継続率には大打撃です。

優れたナビゲーションシステムの構築は、ある種矛盾している部分があるかもしれません。当たり前ですが視界に入らなければ認識できないので、ある種のナビゲーションはスクリーンに表示されている必要があります。一方で、ナビゲーションは目立ちすぎてはいけません。目立ちすぎると、コンテンツの邪魔になりユーザーの気を散らしてしまうでしょう。これは簡単に達成できることではありませんが、定性分析やA/Bテスト、ブレインストーミングを行えば、何があなたのアプリにもっとも適切なのか見極めることができるでしょう。

6. ターゲットサイズを考慮していない

私たちは異なる画面サイズのスマートフォンを持っています。また、指の大きさもそれぞれ異なります。しかし1つすべてに共通しているのは、アプリの要素にインタラクションする視覚的な確認やサインが必要だということです。たとえば、Twitterのホームボタンは押されたときに小さなアニメーションが付いていて、クリックした音と共に、ボタンが押されたことをユーザーに知らせています。

アプリ開発者がしてしまう間違いの1つに、アプリの要素を小さく作りすぎることがあります。それでは、要素がユーザーの指に完全に隠れてしまいます。結果として、ユーザーはアプリとインタラクションできているのか、それともミスタップしてしまったのか、あやふやなままインタラクションが終わってしまうのです。

ご想像の通り、そうなると行ったり来たりする動作が増えて不満が溜まり、悪いユーザー体験を生み出してしまうのです。AppleやMicrosoftなどのモバイルOSの製作者たちがアプリのもっとも良いボタンサイズに関するガイドラインを公開しています。それによれば、インタラクション要素は1辺9mm以上の正方形、または135PPIディスプレイで48 × 48 pixelよりも大きいサイズに設定する必要があるとしています。これらの設定を無視してアプリを公開するとユーサビリティが台無しになり、人気も得られず成功できなくなってしまうかもしれません。

一般的に、開発者はいつでもプラットフォームの基準を順守する必要があります。顧客が基準と異なる形式を求めている場合でさえ、開発者はそれに反対する必要があるのです。Kneen氏は、プラットフォームの基準に従わないと常に「悪い事例」になると述べています。また、彼は以下のように続けます。

プラットフォームのUI基準に従うのが1番です。そうすれば素早くイニシアチブを取れるアプリを作ることができます。なぜならユーザーはそのUXに慣れているからです。

人間の指とタッチスクリーンデバイスとのインタラクションについてさらに知りたい方は、こちらをご覧ください。

注意深く進める

デジタル分野での仕事において、変わらないものはありません。すべてのアプリの機能を変更して改善できることは、モバイルアプリのプロにとって大きな強みです。しかしながら、開発者たちが開発を始める前に何を実現したいのかについて、無頓着になって見逃して良いということではありません。

どれほど単純で明らかなものであったとしても、いくつかの間違いのせいで何ヶ月もの努力が水の泡になってしまうかもしれません。問題は、ほとんどのアプリ開発者たちがよくわかっているはずなのに、期限に間に合わせたり予算内に収めたりするせいで、手を抜こうとしてしまうことです。その結果、より時間と費用がかかる道のりを進むことになってしまいます。孔子はかつてこのように言いました。「用心深い人はめったに間違いをおかさない。」アプリの開発において、これほど大切なことはないでしょう。