（米国）住所入力フィールドの順序を、事前入力機能を優先して変更しても大丈夫ですか？
ユーザーが住所を入力する必要がある国際サイトで作業しています。時間を節約する事前入力機能を優先して、入力フィールドの順序が少し異なるのは理にかなっているのではないかと思います。
これは米国の住所入力フィールドの一般的な形式です：
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
少し異なる順序は、入力フォームUXを改善する可能性があります：
市と州を正しく検出できると仮定しましょうafterユーザーが郵便番号を入力しました（私はsome米国で一意ではない郵便番号を認識しています）。ユーザーが郵便番号入力フィールド（onblur）を離れると、都市と州はほぼ瞬時に事前入力されます。
私の質問は：
入力フィールドの順序を変更した場合、ユーザーエクスペリエンスに本当に悪影響を及ぼしますか？
ユーザーはこのモードで「自動操縦」に行く傾向があるので、よく知られた形式に固執したほうがいいので、ユーザーに考えさせることはお勧めしません。また、入力/選択を速くする前に、値が自動更新されて混乱が生じ、場合によっては2倍の値が入力されることもありました。
さらに、あなたはそれが国際的なサイトであると述べました、それはそれが意味すること：
- ユーザーは最初に国を選択する必要があります
- これを意味のあるものにするためには、ほとんどの国で逆引きサービスが必要です（そして、あなたがそれに信頼できるかどうかはわかりません）
最後に-郵便番号は必須ですか？そうでない場合は、すべてのオプションフィールドを最後まで残すことをお勧めします。
自動入力のアイデアを思いついたので（フォームの入力時間が大幅に短縮されます）、Zipが入力されるまで市/州のフィールドを非表示にしてみてください。
- 自動入力機能で適切な一致が得られない場合は、市/州フィールドを表示し、適切な一致が見つからなかったことを説明します
- 一致する場合は、表示後に都市/州のフィールドにメッセージを正しく入力して表示します。
ダンの提案に同意します。
私の経験に基づいて、私は注文を一度だけ反転しました、そしてそれは仕事が書かれた文書からアドレスを転記することを必要とするユーザーのための内部アプリケーションのためでした。
CSRは通常、電話で住所を取得する必要があり、顧客は特定の順序で住所を言うことを好むため、コールセンターアプリケーションではうまく機能しませんでした。
考慮すべきもう1つの項目は、Zipコードを混同するのが実際に簡単な人もいるということです。 （例：14171 14711）、一方、人々は自分の都市をかなりよく知っています。
ヒューリスティックの観点からは、「市、州、郵便番号+ 5」の最も一般的な形式を使用することをお勧めします。
別のオプションは、前の画面でZipを要求し、次に、住所が表示された画面で、可能な都市のドロップダウンを提供しながら、州とZipを事前入力します。例が直面するハードルの1つは、単一の郵便番号内に複数の都市が存在する可能性があることです。
私は、研究資金を探している教育機関が記入するフォームベースのアプリケーションの設計を必要とする最近のプロジェクトに取り組んでいました。私たちは、おそらく国際的なオーディエンスによって最もよく使われるかもしれないレイアウトの種類について多くのユーザビリティテストを行いました、そして私達は以下に述べるようなラベルを持つことは人々を本当に混乱させることがわかりました：
- 番地-番地は非常に多くの方法で言及できます。例：番地が最初、番地が2番目または番地が最初、アパート名が2番目、地域が3番目
- 郵便番号-郵便番号とはどういう意味ですか。さらに、郵便番号は米国の用語であり、インドなどの国ではピンコードと呼ばれています。そこでラベルテキストも変更しますか？
- アパート番号（これは奇妙に思えるかもしれませんが、ほとんどの人は、これに家番号を入力する必要があるかどうか、これが教育機関の住所にどのように適用できるか、そしてアパート番号が建物の部屋番号になるかどうかがわかりませんでした。）
結局のところ、誰にとっても効果的な最も簡単なソリューションは、ユーザーが必要に応じて入力できるアドレスフィールドにプレーンテキストボックスを用意することでした。
これはあなたが探している解決策ではないことを知っていますが、私たちのケースではうまく機能するシンプルで効果的な解決策です
編集：私はあなたの検証をどのように計画するのか興味がありますか？私は大学院でプロジェクトに取り組み、米国の影響情報（図書館やインターネットセンターの場所）をチリやバンガラデシュなどの場所にマッピングするためのマッピングアプリケーションを作成しました。一貫した調整を行う唯一の方法は、縦軸と横軸のポイントを使用します。私はあなたの質問には答えていませんが、効果的に機能する検証を行う方法は本当にありますか？
代わりに、市/州を郵便番号に対するチェックとして使用して、それらが互いに対応していることを確認します。これは、ユーザーにメールアドレスを2回入力させるようなタイプの目的を果たします-タイプミスを防ぎます。ユーザーの時間を節約しようとしていると思いますが、正確さが最も重要です。 3つすべてが入力された後で検証し、一致しない場合は赤い背景のボックスにフラグを立てます。
データを後で再フォーマットする必要がある場合、またはデータを特定の入力に分離する必要がある場合を除いて、住所フィールドに単一のテキスト領域を使用することをお勧めします。これにより、国際化の問題が解決され、ユーザーが自分の住所に関連するEdgeのケースを、あなたが考慮しなかった可能性がある場合に対応できます。
また、ユーザーが複数の入力間を移動する必要がないため、入力が高速化されます。