そのため、特定の課題に直面しました。それは、住所を追加して編集する機能とは別に、チェックアウト手順での住所管理です。質問には2つの部分があります。
顧客はチェックアウトプロセス中に住所を削除できますか?なぜ? (参考にしてください。)
アドレスの編集と追加はモーダル/ダイアログフォームまたは表示されるフォームwithinページとして表示する必要がありますか?
チェックアウト中にアドレスを削除できることに関して:私はこれを許可します。この見解は、個人的な経験と(これまでのところ)3対1の調査の両方から来ています。1 既存のアドレス管理モジュールの削除を許可するため。なぜ彼らが許可することに決めたのかは言えませんが、私にとっては、多くの人にとって、彼らが許可する唯一の時間アドレスの管理について考えるは、チェックアウトプロセスを通過するときです。
いつか私はさまざまなアドレスをAmazonアカウントに追加しました:時々これらは多かれ少なかれ1回限りのものです(私はギフトとして何かを受け取り、それを受信者に直接配信したい)または別のアドレスとして私のもの(職場の住所、両親の住所など).
今は珍しいかもしれませんが、「アマゾンのアドレス帳を管理してみましょう」とはめったにないので...通知する唯一の時間これらの追加されたアドレス、そして「本当にXXXのアドレスはもう必要ありません」は、別のアドレスを選択するときにアドレス選択ステップを通過するときです注文。その時点で不要になった住所を削除できないのは面倒です。
引っ越しのようなものは例外になります。「連絡先の組織で私の住所を更新してください」モードになり、おそらく積極的に探し出します。詳細を更新する電子商取引サイト。ただし、ほとんどの人にとって家を引っ越すことはおそらく比較的まれなイベントであるため、「ドライブバイ」削除(つまり、チェックアウトプロセス中)は必要な機能だと私は主張します。
アドレスの削除を許可する1つの引数againstは、チェックアウトプロセス(および、ひいてはアドレス選択プロセス)が可能な限り単純で整理されたものであるという格言です。これはおおまかに良いアドバイスですが、アドレスの削除を許可することはしないとは言えません。
newの顧客にとって格言は最も重要です。注意散漫さや複雑さが少ないほど(理論が進むほど)、見込み客を販売に変える可能性が高くなります。ただし、定義により、住所を削除する問題は、すでに「変換」されている既存の顧客にのみ適用されます。それは、戻ってくる顧客の画面を不必要に複雑にすることが「OK」であるという意味ではありませんが、asのように、すべての厳密に不要な機能を削除することに精通する必要はありません。新しいユーザー。
削除オプションの「余分な複雑さ」は最小限です。アドレス帳セレクターを配置するにはさまざまな方法があります(以下の参照を参照するとわかります)。 Edit ボタン;追加する Delete ボタンは大きな違いはありません。
チェックアウト中にを削除できることはおそらく厳密には必要ありません(ほとんどのサイトは明示的な「アドレス帳の管理」機能を提供します) )、ユーザーのメリット(アドレスが目の前にあるときにアドレスを削除できること)は、わずかな複雑さよりも重要であり、チェックアウトプロセスの完了後にサイトに戻る手間を省くことができると私は主張します。
1 (これまでのところ)Webを検索すると、さまざまな「アドレスモジュール」(eコマースサイトにプラグインできるように設計されています)がチェックアウトプロセス中にアドレスを削除する機能にどのように取り組むかについて、次のリストが生成されました。
このページ AmeriCommerceのアドレス帳モジュールについてdoesは、既存のアドレスを削除する機能を提供します(特に、お客様が目にするもの)。
このページ ShopWiredのアドレス帳についても、既存のアドレスを編集および削除する機能があります(最初のスクリーンショットを参照)。
このページ IDカードグループのアドレス帳については、既存のアドレスの編集と削除の両方が可能です(のスクリーンショットを参照)アドレス帳での追加と編集)。
私の個人的な経験と論理に基づいています。
1)最初に入力した住所であるため、初めてのユーザーはチェックアウト時に住所管理を行うオプションがありません。ユーザーがユーザーを返し、より多くのアドレスを使用している場合、彼はすでに忠実であり、このアクションは彼の忠誠心や意見を変えるほど混乱を起こしたり重要ではないので、チェッククット中にアドレスを追加したり変更したりすることを気にしない可能性があります。
2)インラインで行う方がより論理的です。 Ajaxやその他の効果を使って効果的に行うことができます。私はこれに関する明確な参照は見つかりませんでしたが、論理は変わります-ユーザーに同じようなインターフェイスを残し、ポップアップであまり変更しないことが目標です(表示するにはコントラストのある背景が必要です)、特に敏感な部分ではチェックアウトのようなウェブサイトの。
文脈なしでは判断が難しい。チェックアウトプロセス中に、ユーザーが個人情報を確認(および調整)して、すべてが最新であることを確認することを許可します。ただし、データを消去するスタンドアロンオプションを使用すると、ユーザーが誤って削除した情報を再入力しなければならない場合があります。
モーダルは非常に破壊的であり、可能な場合は回避する必要があります。彼らはモーダルを開くことによってのみ発見可能な情報を隠します。この場合、モーダルは彼らを彼らのワークフローから外す可能性があります:単に彼らの住所を入力します。
これに対処するために、ユースケースを見てみましょう:
私はウェブサイト Swiggy を使用して食品を注文しており、過去2年間注文しています。この間、私は2回都市を移動しました。これで、チェックアウトページに、使用していないアドレスが複数あります。以前に保存したアドレスを使用できないので、削除できないのは非常にイライラします。
別の質問であなたの質問に答えましょう:ユーザーがアドレスを削除できないはずの理由がありますか?
2番目の質問に答えるために、モーダルを使用するかどうかは非常に状況に応じて異なります。モーダルは通常、ユーザーをプロセスから削除してサブプロセスに紹介するために使用されます。たとえば、住所フィールドがマップから入力を取得できる場合、Googleマップを開いてその場所にマーカーを追加することは、モーダルの良い候補になります。あなたのシナリオでは、アドレスの追加が「メインプロセス」であるため、モーダルの使用はお勧めしません。
ユーザーは追加のアドレスを追加できる必要がありますが、それはリピーターの顧客/ユーザーの場合であり、リピーターのユーザーは、多くのアドレスからどのアドレスカードホルダー/配信を選択/削除できる必要があります。過去に贈られたアイテムの可能性があります... ebayとuscは、私が複数のアドレスを持ち、そのアイテムに適したものを選択する場所であることを確認してください。どちらのアカウントでもアドレスを削除していません...ユーザーがチェックアウトの途中で変更した場合に別のアドレスを編集または削除して追加するオプションをユーザーに与えても問題はありません。次の展開状態(カードの詳細)の上にある閉じたアコーディオンにあります。彼らは演説に戻って修正を加えるかもしれない。
私はモーダルの使用や新しいウィンドウの読み込みを避け、インライン化は良い習慣として続けますが、ほとんどの場合、フルスクリーンオーバーレイが必要な場合。
他の場所からアクセスできる限り、チェックアウトプロセスで住所の削除機能を使用できます。ユーザーによるチェックアウトの頻度と、ユーザーが購入を繰り返すたびにこれが摩擦を増やすか取り除くかを検討します。
ユーザーがサイトで頻繁に買い物をしていて、チェックアウトプロセス中に完全な住所管理が可能であることを認識している場合、別の場所にいても、最初にショッピング関連のアクティビティに従事する可能性が高くなります。不安を予測することは、摩擦と収益の損失の最も重要な原因であるため、最優先事項でなければなりません。
ユーザーは、住所を更新するために他の場所に移動するよりもショッピングカートを紛失する可能性があると考えている場合、心配しています。この競合はモバイルでは拡大されます。
注文を間違った住所に送った可能性があるとユーザーが心配している場合、それを削除するとエラーの可能性がなくなります。たとえば、出張中に購入し、ホテルの住所を入力したことを知っていたとしても、この住所を保持するインセンティブはありません。アドレスの数が増えると、エラーの可能性がより大きくなります。
不安を回避することは、フォームとモーダルのどちらを使用するかの決定にも影響しますが、この場合の主な懸念は、ユーザーの認知負荷を減らすことです。プロセス全体でコンテキストが同じである場合、チェックアウト中にユーザーに課される認知的負荷が大幅に軽減されるため、モーダルを使用しないことをお勧めします。この決定は、目標(購入)を達成するのに役立つだけでなく、ユーザーを選択的注意モードから解放し、特別なプロモーションや購入後のアクションなど、サイトの他の側面に従事する可能性を高めます。
参照で何を意味するのかわかりません。このテーマについての私の理解は、ユーザーの行動と意思決定プロセスを研究することから得られます。これらのトピックについて作成された研究を探します。