あやね
UXの競合分析では、同じユーザーの作業を複数の製品で比較します。まずチームが決めたいことを明確にし、条件をそろえて操作をたどり、各画面で分かりやすい点と迷う点を記録します。目的は見栄えのよいスクリーンショットを集めることではなく、理由を説明できるデザイン案につなげることです。
たとえば、ECサイトの返品手続きを改善したい場合を考えます。顧客が返品できる条件を理解し、対象の商品を選び、その後の流れを把握できるかが重要です。PixsoのUXデザインワークスペースでは、比較した操作の流れと提案する画面を並べ、変更点についてチームで話し合えます。
競合を並べる前に、何を決めたいかを定める
「競合を理解する」だけでは、調べる範囲が広すぎます。「返品申請を送信する前の、どこで返品条件を説明するかを決める」なら、チームが検討すべき内容が具体的になります。調査を終える判断もしやすくなります。検索、ポイント制度、トップページのアニメーションまで比較しても、この問いには答えられません。
最初に、顧客が置かれている状況を書き出します。この例では、シャツを2枚購入した人が1枚を手元に残し、サイズの合わないもう1枚を返品したいと考えています。注文確認メールがあり、スマートフォンを使い、代金が返金されるのか、次回の買い物に使うストアクレジットになるのかを知りたい状況です。比較するすべての製品で、この条件をそろえます。
最初のサイトを開く前に、目指す結果も定めます。顧客が返品対象の商品を特定し、明示された費用を理解し、返金方法を把握し、申請が実際に送信されたかを判断できることが必要です。多くの画面を進めることではなく、適切な結果に迷わず到達できることを目指します。
判断に役立つ比較対象を選ぶ
同じような作業と利用者を持つ製品を選び、その一部に参考になる仕組みがあれば、隣接する分野も加えます。たとえば、レンタルサービスの商品状態の説明や、小売サイトの返金時期の案内が役立つかもしれません。直接の競合でなくても、検討中の判断に結び付く例は比較対象になります。
実際の操作を調べられる範囲に絞りましょう。12サイトのトップページを急いで集めるより、3つの流れを丁寧にたどるほうが役立ちます。自社の現在の流れも同じ条件で比較すれば、その強みや制約を思い込みで済ませずに確認できます。
結果に影響する端末、ログイン状態、地域、注文状況、返品の可否などをそろえます。アクセスできない箇所があれば、その条件も記録します。実際に購入しないと返品方法が表示されないサイトで、確認できなかった画面は「不明」です。画面を開けないことだけを理由に、使いやすさを低く評価しないようにします。
競合の公開ポリシーは画面を理解する手がかりになりますが、そのまま自社の要件にはなりません。手数料、返品期間、返金方法は、自社の製品担当者や運用担当者に確認する必要があります。他社の文言を借りると、自社では提供できない対応を約束してしまうおそれがあります。
専門家によるレビューとユーザーテストを区別する
Nielsen Norman Groupは、競合レビューと競合のユーザビリティテストを区別しています（英語）。レビューでは、実務者が画面を調べ、長所や問題になりそうな点を見いだします。テストでは、参加者に課題を実行してもらい、その行動を根拠にします。どちらも設計に役立ちますが、分かることは異なります。
レビューで確認できるのは、たとえば「返金の説明は商品を選択した後に初めて表示される」という事実です。顧客の行動やほかの根拠を確認せずに、「顧客はたいていこの説明を見落とす」とは言えません。まず観察した事実を書き、そのうえで懸念を示します。設計上の妥当な判断を、確認していない調査結果にすり替えないためです。
テストでは、画面のラベルを教えるのではなく、達成したいことを伝えます。「返品を開き、返金を選んでください」より、「サイズの合わないシャツを返し、お金がどのように戻るかを知りたいと思っています」という伝え方が適しています。同じ参加者が複数の製品を試す場合は、最後の製品だけが課題への慣れによって有利にならないよう、試す順番を変えます。
申請が確定する場面まで、作業全体を記録する
すべてのマウス操作ではなく、顧客の理解が変わる場面を記録します。返品の例なら、入口を見つける、注文を特定する、商品を選ぶ、返品条件を理解する、返金や交換を選ぶ、申請を送信する、という場面です。送信後の確認も欠かせません。下書きを保存しただけなのか、返品申請が受け付けられたのかを区別できる必要があります。
観察内容は、該当する画面と、その画面が表示された条件のそばに残します。たとえば「商品選択画面では、商品名の下に返品期限が表示される。返金方法は次の画面まで表示されない」と短く記録できます。作業用のファイルには、参照URL、画面を確認した日、必要なアカウントの条件も添えます。
次の表は、観察内容から設計上の問いを導くための架空の比較例です。
| 見せ方 | 顧客に見える内容 | 自社の設計で考えること |
|---|---|---|
| ポリシーを先に示す | 注文を特定する前に、返品ポリシーの全文が表示される | 購入していない商品の条件まで読み解かせず、必要な条件を伝えられるか |
| 商品を先に示す | 返品できる商品とできない商品が、その理由とともに表示される | 申請に時間をかける前に、選べない理由を理解できるか |
| 返金・交換を先に選ばせる | 適用される条件を見る前に、返金や交換の選択肢が表示される | 先に期待を持たせ、後の画面でその選択を取り消させることにならないか |
総合的な勝者を決める必要はありません。商品を先に示す流れでは返品の可否が分かりやすくても、返金時期の説明が不十分かもしれません。両方を残しましょう。一つの星評価にまとめると、改善できる点が見えなくなります。
違いが役立つ理由を説明する
「こちらの流れのほうがすっきりしている」は好みの表明です。「選べない商品の横に理由があるので、その選択肢を理解するためにポリシーを開かずに済む」なら、どのように役立つかを説明できます。必要な情報、その配置、支える判断を具体的に示しましょう。
手順の数を比べるときは、各手順の意味が同じかも確認します。短い流れが重要な条件を隠していることも、長い流れが単純な判断を不要なページへ分散させていることもあります。画面が切り替わるたびに、必要な情報が増えるのか、判断が求められるのか、既知の内容を繰り返しているだけなのかを見ます。
利点だけでなく、その設計が生む負担も考えます。各商品の横にポリシーをすべて載せると、注文点数が多い場合に一覧を見渡しにくくなります。すべてをリンク先へ隠すと、例外条件を後から知って驚くかもしれません。商品のそばには返品可否の短い説明を置き、詳しい条件へ進めるようにする方法が考えられます。
複数の製品が同じパターンを使っていても、それは調べる価値があるパターンというだけで、効果の証明ではありません。同じ慣習や制約、未解決の問題を共有している可能性もあります。採用するかは、自社の利用者と作業に合うかで判断します。
比較結果を、レビューできる画面に変える
ECサイトの例では、購入した商品、返品の可否、次にできる操作の3つをまとめた商品選択画面を提案します。返金時期の説明は最終送信より前に置きます。最後の操作も、「続ける」ではなく「返品を申請する」のように結果が分かる表現にします。
Pixsoで現在の流れと提案する流れを並べます。両方で注文内容と商品名をそろえると、変更した情報に集中して比較できます。返品可否の行のそばには、「選択前に理由を伝える。詳しいポリシーにも、商品の文脈を失わずに進める」といった設計意図を短く添えます。
検討したいことが順番や申請の確定に関わるなら、画面をつないでプロトタイプにします。レビュー担当者には、1点を返品し、選べる対応方法を説明し、どの時点で申請が確定するかを答えてもらいます。返品条件の説明に気付けるかだけを確かめたい段階なら、多くの操作を作る前に、該当画面に絞ったレビューでも検討できます。
分かったことに応じて提案を絞り込みます。返品の可否は理解できても、返金時期が分からないなら、商品一覧を再び作り直す必要はありません。送信前に必要な説明へ焦点を移します。UXリサーチの結果をデザイン判断につなげる方法では、観察した行動から具体的な判断を導く手順を解説しています。
チームが動ける提案として共有する
最終的な提案は、「返品できない理由を各商品の横に表示し、送信前に返金方法を示す」のように具体的にします。その後に、最も重要な観察内容、提案画面、まだ決まっていない製品上の課題を示します。この例では、実装前に運用担当者が返金時期の文言を確認する必要があります。
詳しい画面記録は後から確認できるように残し、話し合いでは決めたいことから伝えます。会議を終えるときには、どの変更を検討するのか、何が改善すると考えるのか、どんな根拠があればその提案を支持・見直しできるのかが共有されている状態を目指します。
競合分析は、設計上の判断につながってこそ役立ちます。一つの作業を起点に重要な場面を比べ、その結果を自社の使いやすさの改善へつなげましょう。
