コンバージョンが増えるようにアプリを設計する

  • 開発
  • デザイン
  • 収益

Google では、ユーザーをコンバージョンに導く要因を明らかにするために、包括的なユーザー エクスペリエンス調査を実施しました。この調査では、e コマース、保険、旅行、料理のデリバリー、チケット販売およびチケット サービス、会計管理など、さまざまな業種を対象とした各種アプリを使用しました。使いやすく有益で適切なコンテンツを提供するアプリを開発するため、調査結果から得られたおすすめの方法をご確認ください。

  • アプリの有用性をわかりやすく表示しましょう。ユーザーのニーズに明確に対処し、行動を促すフレーズを目立つように配置します。アプリの主な機能や新機能を状況に応じて強調することで、ユーザーに興味や関心を持ってもらうきっかけを作ります。

    適切な例

    「Rent」(借りる)、「Buy」(買う)、「Sell」(売る)は、行動を促すフレーズとして明確で適切です。

    不適切な例

    「Try it now」(今すぐ試す)は、具体的な行動が示されておらず曖昧なフレーズです。

  • 直感的にわかるようにメニューを整理し、分類しましょう。メニューの分類はわかりやすく区別し、内容が重複しないようにします。また、ユーザーのメンタルモデルと一致する分類にする必要があります。目的の項目を何度検索しても見つからなかったユーザーが最後の手段としてメニューに戻ってきた場合は特に、こうした分類が重要です。

    適切な例

    商品の分類が明確で、迷うことがありません。

    不適切な例

    「Men's Footwear」(男性用シューズ)と「Hiking」(ハイキング)のように、商品の内容が重複する分類にしてはいけません。

  • 1 つ前の手順に簡単に戻れるようにしましょう。こまめに移動できるナビゲーション コントロール(適切な戻るボタンなど)を配置すると、ユーザーのコンバージョンを促進する効果があります。ユーザーがいつでも 1 つ前の手順に戻れるようにすれば、ホーム画面に戻って最初からやり直す必要がなくなり、ユーザーの不満を解消できます。

    適切な例

    戻るボタンをタップすると、ユーザーの期待どおりフローの 1 つ前の手順に戻ります。

    不適切な例

    戻るボタンをタップしてフローの最初に戻ってしまうと、ユーザーの混乱を招きます。

  • ユーザー自身で簡単に場所を変更できるようにしましょう。Google Places API を使用して現在地を自動検出できるようにしておくと、ユーザーにとって時間の節約になります。ただし、現在地付近にない店舗や場所を探せるようにすることも必要です。

    適切な例

    ユーザーが場所を選択できるコントロールが用意されています。

    不適切な例

    ユーザーが場所を変更できる方法が用意されていません。

  • モバイルアプリとモバイルウェブ間をスムーズに遷移できるようにしましょう。Chrome のカスタムタブは、モバイルアプリとモバイルウェブという 2 つのプラットフォームで共通のデザインやレイアウトを提供することで、アプリとウェブ コンテンツ間をシームレスに遷移できる機能です。また、カスタムタブを使った場合は遷移が高速に処理されるため、他の対処方法と比べても十分メリットがあります。

    適切な例

    アプリからサイトへの遷移がスムーズに行われます。デザインに一貫性があり、表示速度も最適化されています。

    不適切な例

    アプリとサイトでデザインや操作方法が変わっています。

  • マテリアル デザインの検索パターンに関するガイドを参考にして、検索欄を目立つように表示しましょう。アプリでは常設型検索ウィジェット アプリバーを使用することをおすすめします。ユーザーがいつでも簡単に、検索するコンテンツを見つけられるようにするためです。

    適切な例

    検索欄が開いているので簡単に見つかります。

    不適切な例

    検索機能がメニュー項目の 1 つとなっていて、検索欄が開いていません。

  • 効果的な検索インデックスを使用しましょう。ユーザーは、アプリ内検索が Google 検索と同じように機能することを期待しています。綴りの自動修正、語根の認識、予測テキスト、入力途中での検索候補の表示など、便利な入力補助機能を利用すれば、検索時間を短縮したり入力ミスを減らしたりできるので、ユーザーはコンバージョンまでの操作をスムーズに進められます。検索インターフェースの作成カスタム検索候補の追加最近の検索クエリに基づく検索候補の追加についての説明をご覧ください。

    適切な例

    インデックスの定義が適切だとユーザーは検索がしやすくなり、有効な結果が得られます。

    不適切な例

    検索インデックスが不適切だと、検索しづらい印象を与えます。

  • フィルタや並べ替えの設定を用意して、ユーザーが検索結果を絞り込んで整理できるようにしましょう。

    適切な例

    有効なフィルタや並べ替えの手段が提供されているので、検索結果を絞り込むことができます。

    不適切な例

    フィルタや並べ替えの設定がない、または表示されていないと、ユーザーは多数の商品を見比べなければなりません。

  • ユーザーの時間と労力を節約できるように、過去の検索内容や購入情報を表示しましょう。特に、ユーザーが頻繁に使用するアプリでは検索や購入が繰り返し行われるため、こうした機能が重要です。

    適切な例

    ユーザーは以前に使用した検索キーワードを選択して、再び使用できます。

    不適切な例

    以前と同じ商品を検索する場合でも、あらためてキーワードを入力する必要があります。

商品のレビューと比較

  • ユーザー レビューの並べ替えや絞り込みに対応して、商品に関する「リアルな感想」が伝わるようにしましょう。ユーザー レビューは、購入判断を左右する重要な要素です。購入を検討しているユーザーにとっては、レビュー件数が多いと信頼度が増します。最新のレビュー、最も肯定的なレビュー、最も否定的なレビューを閲覧できるようにして、ユーザーが共通のテーマを見つけられるようにします。商品を購入したユーザーからの確認済みレビューも掲載すると効果的です。

    適切な例

    ユーザー レビューのフィルタと並べ替えができるようになっています。

    不適切な例

    ユーザー レビューのフィルタの設定がない、または表示されていません。

  • 価格比較機能を有効にして、ユーザーが関心を持っている商品を簡単に比較したうえで購入判断を下せるようにします。この機能がないと、ユーザーは、比較のためにとりあえず商品をカートに入れておいたり、後でもう一度チェックすべき商品を覚えておいたりしなくてはなりません。

    適切な例

    ユーザーは比較ツールを使ってそれぞれの項目を直接比較できます。

    不適切な例

    ユーザーは比較したい項目を覚えておかなければなりません。

支払い方法

  • ユーザーの要望に応じて、サードパーティによる支払い方法を複数用意しましょう(PayPal、Google Pay など)。また、購入手続きの際は別のフォームに入力しないで済むようにして、セキュリティ上の安心感を高めましょう。

    適切な例

    ユーザーが選択して管理できる複数の支払い方法が用意されています。

    不適切な例

    ユーザーが利用できる支払い方法が 1 つしかありません。

  • 支払い方法の編集や追加が簡単にできるようにしましょう。たとえば、カード番号を入力するためのキーボードのテンキーを表示したり、クレジット カードのスキャン機能を追加したりします。複数のカードを追加できるようにして、それらを切り替える機能も用意します。

    適切な例

    ユーザーは、すでに保存されている支払い方法を編集したり、新しく追加したりできます。

    不適切な例

    支払い方法を編集したり新しく追加したりできる機能が用意されていません。

登録

  • ユーザーに登録を要求する前にどのようなメリットがあるかわかりやすく紹介し、本当に必要な場合に限り登録してもらうようにしましょう。すぐにサービスを受けられる(たとえば、自動車の修理や食べ物のデリバリーを注文する)場合を除いて、個人情報を事前に提供するよう要求するアプリは、ユーザーに途中で放棄されてしまいます。ブランド認知度が低いアプリや価値提案が明確でないアプリが最初から登録を求めようとする場合は、さらにハードルが高くなります。コンバージョンの時点でゲスト購入ができるようにすることを検討してください。

    適切な例

    ユーザーに個人情報の入力を求めることなく、魅力的なサービスを先に紹介しています。

    不適切な例

    先に登録を要求することは、アプリの利用にとって大きな障壁となります。

  • 「アカウントへのログイン(サインイン)」と「アカウントの登録(サインアップ)」の違いを明確にしましょう。ユーザーが新しくアカウントを登録しようとするときに誤って操作することがないようにします。

    適切な例

    インターフェースがシンプルで、行動を促すフレーズも明瞭です。

    不適切な例

    行動を促すフレーズが紛らわしいため、ユーザーが間違える可能性があります。

  • 手軽なパスワード認証を実装しましょう。Android 向けログイン、Smart Lockログインのヒントといった Google ID プラットフォームのツールを使用して、認証の際に必要な手順を減らすことをおすすめします。また、指紋認証のような認証技術を使用することもできます。

    適切な例

    指紋認証によるログインのように効率的な方法を採用し、スムーズに認証できるようにしています。

    不適切な例

    テキストベースの認証では、認証エラーになることがよくあります。

フォームとデータ入力

  • ユーザーが使いやすいフォームを作成しましょうマテリアル デザイン ガイドラインのテキスト欄についての説明をご覧ください。また、Places API などのツールを利用すると、オートコンプリート サービスを提供できます。フォームはユーザーが情報を入力する方法に対応していることが必要です。限られた方法でしか入力できない画面ではなく、複数の入力形式を解釈できる画面を設計してください。また、フォームの入力欄がキーボードなどのインターフェース要素にさえぎられて見えなくならないようにしましょう。入力が終わった欄は自動的に画面の上の方に移動するようにします。

    適切な例

    自由な書式で情報を入力できる入力欄が用意されていて、入力が完了すると次の欄が上がってきます。

    不適切な例

    入力するデータの書式が固定されていて(電話番号の入力欄が 3 つに分かれている)、次の欄がキーボードで隠れています。

  • フォームに入力ミスがあったらすぐに伝えましょう。情報が正しく入力された入力欄や、確認できた入力欄についても、ユーザーがわかるようにその旨を表示しましょう。処理がスムーズでフローが中断されないことを確認するために、入力テストを行います。

    適切な例

    データが入力されるとすぐに、状況に応じて対応可能なエラー メッセージが表示されます。

    不適切な例

    フォームの送信前に入力内容が検証されていません。また、表示されたメッセージではエラーの状況や対応方法がわかりません。

  • 入力する情報に適したキーボードを表示しましょう。そうすれば、ユーザーはキーボードを切り替えなくて済みます。アプリ全体でも常にこうしたキーボードを実装します。

    適切な例

    数字を入力する必要がある欄では自動的に数字キーボードが表示されます。

    不適切な例

    数字を入力できるようにするために、キーボードの数字キーをタップする必要があります。

  • ユーザーがフォーム内を簡単に移動できるように、状況に応じて便利な情報をフォームに表示しましょう。たとえば、スケジュールを入力するときに月単位のカレンダーを表示すれば、スマートフォンのカレンダーをチェックするためにアプリを離れる必要がなくなります。これは、ユーザーが別の操作を行うことに気を取られるリスクを防ぐことにもなります。

    適切な例

    データ入力時にカレンダー ウィジェットのような便利な機能を利用でき、情報が簡潔に説明されています。

    不適切な例

    適切なデータ入力機能が用意されていません。また、入力のヒントになるようなヘルプテキストが表示されていません。

使いやすさとわかりやすさ

  • ユーザーが使う言葉を選び文章に関するマテリアル デザイン ガイドラインに沿って文を作りましょう。一般的に理解されている用語やフレーズを使用し、ブランド固有の用語は使用しないようにします。ユーザーを混乱させる可能性があるためです。

    適切な例

    「Buy」(買う)、「Rent」(借りる)、「Sell」(売る)など、明確な用語を使用し、混乱を避けるために不要な専門用語は使用していません。

    不適切な例

    「Roost」(居住)、「Migrate」(移住)、「Fly」(借家)など、あまり一般的でない用語はユーザーを混乱させる可能性があり、情報の見つけやすさやわかりやすさを低下させます。

  • わかりやすい視覚的情報を提示するためにテキストラベルやアイコンの凡例を活用しましょう。メニュー、カート、アカウント、店舗検索などのアイコンや、フィルタや並べ替えといった操作に対するアイコンは、誰もが共通して理解できるわけではありません。ラベルが付いているアイコンの方が、使用される可能性が高くなります。また、凡例により視覚的な分類が用意されているアプリの方が、ユーザーにとってわかりやすくなると言えます。

    おすすめの方法: テキストやアイコンには、android:drawableLeft 属性を指定した Button クラスを使用できます。詳細については、デベロッパー ガイドをご覧ください。また、アイコンやボタンにラベルや説明を追加する場合は、アプリにユーザー補助機能を実装することをおすすめします。

    適切な例

    アイコンにラベルが付いているので、意味が伝わりやすく、いつでも理解してもらえます。

    不適切な例

    ラベルのないアイコンは誤解されることが多く、混乱を招く可能性があります。

  • 重要なアクションが発生したときには、視覚的フィードバックを使用して反応しましょう。ユーザーがカートに商品を追加したり注文を送信したりしたときにフィードバックがないと、そのアクションが処理されたかどうか不審に思う可能性があります。

    適切な例

    視覚的に明確なフィードバック(ここでは、確認のためのトースト)を表示することで、アクションが処理されたことを保証しています。

    不適切な例

    カートに商品を追加したなどのアクションの後に視覚的フィードバックが表示されないため、ユーザーはそのアクションが処理されたかどうか疑念を抱くことになります。

  • ユーザーが画像を見るときに自分でズームレベルを調整できるようにしましょう。また、拡大率は固定しないことをおすすめします。ユーザーが商品の特定の部分しか見られない、画像の一部が画面に表示されないなどの問題が起きる可能性があるためです。

    適切な例

    拡大する部分とズームレベルをユーザーが調節できます。

    不適切な例

    ズーム機能が特定のレベルと位置に制限されているため、ユーザーの不満につながります。

  • アクセス権限の要求は適切な状況で表示しましょう。アプリの機能をフルに利用するために必要であれば、ユーザーがアクセス権限を許可する可能性が高まります。

    適切な例

    位置情報を必要とする状況で(ここでは店舗の場所検索をリクエストした直後)、ユーザーに位置情報へのアクセス許可を求めています。

    不適切な例

    ユーザーの状況や現在の操作に関係なく、位置情報へのアクセス許可を求めています。