オーダートラッカーのタイムラインは時系列である必要がありますか？
「人生は逆にしか理解できません。しかしそれは前向きに生きなければならない。」 - SørenKierkegaard
Eコマースオーダートラッカーで、「イベント」のリストがある場合（たとえば、注文が出され、配送のために配送され、配信された）-一番上のイベントは過去の最も遠いイベントですか、それとも未来の最も遠いイベントですか？
私は年代順に傾いているので、
注文済み
配送のために注文する
【配信失敗】
[注文が再スケジュールされました]
配達済み
これは、Facebook、Twitterなど、一番上の最新のイベントを更新するほとんどのWebサイトに反します。
そのパターンに一致する必要がある、または一致してはならない説得力のある理由はありますか？
時系列順は、ストーリーを伝える有限量のデータに適しています。時系列の逆順は、時間の経過とともに有用性を失う（潜在的に）無限量のデータに役立ちます。
たとえば、Facebookでは、各postが新しい順に表示されるため、履歴をスクロールして戻りますが、各投稿内ではcommentsが古い順に実行されるため、会話を簡単にフォローできます。
したがって、オーダートラッカーはおそらくlistの注文を新しい順に表示する必要があります。これにより、ユーザーは最初に最新の注文を簡単に見つけることができ、その一方でeventsが表示される場合があります。ユーザーは注文の進行状況を簡単に理解して追跡できます。最初に有用な情報も提示したい場合は、最新のステータスを提供するイベントのリストの前にトップレベルの要素を検討することができます。
現在の状態[配信済み]
注文履歴
置いた
配送中
戻ってきた
配送中
お届け
私が取り組んだ最新の製品にもこの問題があり、私たちが先に進めた製品の最も重要な領域であり、動作を調査するためにかなりの数のユーザーインタビューがありました。ユーザーは最初のアイテムが最も遠いものになると期待していたという結論に達しました（10対面のユーザーインタビュー、およびさまざまな年齢層とドメインから選択された200以上のオンライン）。 1つの方法の方が良いとは言えませんが、この情報をあなたと共有して、あなた自身の結論を導き出すことができます。この行動パターンは、それを使用する大規模なソーシャルプラットフォームの影響を強く受けていると思います。
エンドポイントクライアントタイムラインの2週間のインタビュー期間の終わりに、最終的な結論を説明するために、調査結果の要約といくつかの統計的詳細を提示します。最後に、16〜56歳の237人のユーザーを対象にインタビューを行い、次のように6つの異なるグループに分類しました。
- グループアルファ：25歳から40歳までの78人の被験者、優れたコンピュータ知識、製品との過去の相互作用
- グループベータ：16歳から25歳までの26名の被験者、優れたコンピュータ知識、製品との過去の相互作用
- グループガンマ：40歳から56歳までの25人の被験者、基本レベルのコンピューター知識、製品との過去の相互作用
- グループデルタ：25歳から40歳までの54人の被験者、コンピューターに関する知識が豊富で、製品との過去のやり取りがない
- グループイプシロン：16歳から25歳までの33人の対象者、コンピューターに関する十分な知識があり、製品との過去の相互作用がない
- ゼータグループ：40歳から56歳までの21人の被験者、基本的なコンピューター知識、製品との過去の相互作用なし
私たちの主な目標は、タイムライン領域にアプローチする新しい方法が消費者の利益を追加しているかどうか、および問題を時系列でアプローチする必要があるかどうかを判断することでした。情報のクラスターで問題をグループ化することも、対処された問題の1つでした。
利用可能な製品のデモは、ここからXおよびYで呼び出されます。Xは時系列の製品であり、Yは逆の時系列の製品です。どちらもグループ化機能がアクティブになっています。
以下は、顧客プールの時系列/逆時系列の製品選択の結果です（読みやすくするためにデータを円グラフで表しています。Xはオレンジ、Yは青、無関係は緑です）。それらのほとんどは、タイムラインの逆時系列バージョンをより明確で読みやすいものとして選択します。各カテゴリの結果は次の画像になります。
画像のサイズが異なるため申し訳ありませんが、PDFから簡単な切り抜きをいくつか作成しました。これは私が共有することを許可されている情報の一部であり、会社の再統合のために私ができない統計データです。私は自分の母国語からできる限り情報を翻訳しようとし、機密情報を取り除きましたが、Rushで作成したので、文法の誤りがあるかもしれません。これがお役に立てば幸いです。
使いやすさに関しては、無視したり逸脱したりしてはならないパターンがいくつかあることに注意してください。
注文状況に関して最も一般的に使用されるパターンは、リストの一番上のアイテムが過去で最も遠いものであるパターンです。これは、フローが有限であるためです（注文から始まり、注文の受け取りで終わります）。情報を表示する他の方法を使用すると、ユーザーを混乱させる可能性のある破壊的なパターンが作成されます（ユーザーが人生で初めてオンラインで何かを注文していないという事実を考えると）。
詳しくは、UXパターンに関するこの記事をご覧ください。 （uxmagの記事「UXパターンを使用しない場合の価格」を検索してください）。リストを表示するために反対の方法を使用すること（トップイベントが将来最も遠いイベント）は、それほど良いアイデアではないことがわかります。
あなたの考えを使うことをお勧めします。
さらに具体的には、注文に関する宅配会社のフローを見てください（これは最もよく使用されるパターンを表しています）。
- 最初にAWB追跡番号が与えられます。
- 注文を追跡するには、会社のWebサイトにアクセスし、そのAWBを使用して注文ステータスを検索するだけです。
- 検索ボタンを押すと、更新のリストが表示されます。
- あなたが見るリストは、過去の最も遠いイベントをトップアイテムとして示しています（下の画像を参照）。
さらに理解しやすくするために、水平に展開されたタイムラインとしてフローを設計および表示できます。このようなもの：
上の画像は、注文状況を次のように示しています。1.注文済み// 2.支払いが受理されました// 3.宅配業者に引き渡された商品// 4.宅配便の預金中の商品// 5.配送中の商品// 6.商品配達済み
どちらの方法でも、過去のイベントの中で最も遠いイベントがタイムラインとして表示されます。これが私があなたが持っているアイデアを使用することをお勧めする理由であり、これらのケースではフローが完全に異なり、それが有限のもの。
これがあなたの質問に答えることを願っています。
常にユーザーとして、私の注文を追跡するための私の興味/理由はそれの現在のステータスであり、そのため私は常に逆の年代順で行きます。したがって、注文を追跡するユーザーにとっては、注文/出荷された日時などではなく、注文の現在のステータスを知ることです。
お役に立てれば。
配信追跡システムは事前定義されたプロセスに従います。このプロセスには、明確な開始と終了、および各ステップの状態が異なるいくつかの中間ステップがあります。
FacebookとTwitterは大きく異なります。最新のアイテムが最初に整理された連続ストリームを表示します。開始や終了はなく、事前定義されたステップや状態もありません。
したがって、FacebookとTwitterは、インスピレーションとして使用するのに適した比較例ではないでしょう。リンゴとオレンジ。
したがって、プロセスの各ステージを最初に開始し、最後に最後に表示することは、プロセスがどのように機能するかの典型的なメンタルモデルに従うため、理にかなっています。このプロセスのメンタルモデルに影響を与えることなく、プロセスステップを垂直方向または水平方向に整理できます。現在のステージを強調表示し、各ステップのさまざまな状態を視覚的に示します。完了、現在、未完了など.
私はユーザーが実際に両方のオプションを提供する必要があると思います。なぜなら、追跡アプリが行うことに対してユーザーが持つ可能性がある2つの異なる動作/期待に適合するからです。
最初のインスタンス（理想的なシナリオ）では、ユーザーは注文を出し、すべてが順調に進んでいるため、何かがメールで到着する時期を知りたいだけです。ですから、郵便物がいつ届くのかをいつ知っているのでしょうか。この場合、他の詳細は問題ではなく、おそらく配信または配信済みアイテムのみを確認できるようにフィルターオプションを配置することもできるため、日付の逆順が適切です。
代わりのシナリオは、何かが本来のように届いていないため、注文の履歴を調べて、特定の時点で滞留している時間を確認して、遅延の責任者/組織を追跡できるようにすることです。 。この場合、すでに完了しているステップとその所要時間を把握するために、時系列の順序が必要です。
ただし、常に独自の方法でアプリを使用するユーザーがいるため、両方のオプションを提供する必要があると思います。理想的なまたは最も頻度の高いユースケースのデフォルトオプションと、それ以下の代替オプションを提供する必要があると思いますありそうなシナリオ。