すべてのユーザーのデータを「最も重要」にするにはどうすればよいですか？
従業員向けの内部ウェブサイトを作成しています。 [この背景が漠然としていて、申し訳ありませんが、これは一般公開されているWebサイトではありません。]このサイトは、複雑な関係とユーザー入力値の数千のさまざまなエンティティで構成される大量のデータを追跡します。
私たちのユーザーは多くの異なる部門から来ており、意思決定をしたり、自分の仕事を実行したりするために、それぞれが少し異なる方法でデータを見る必要があります。多くの場合、このデータは1つの部門で入力され、別の部門で読み取られる必要があります。
現在、最も一般的なオブジェクトの検索や最上位のオブジェクトの概要ページ（オブジェクトに含まれるオブジェクトの詳細を含む）など、探しているデータを見つける方法がいくつかあります。この要約ページは、タブに分かれていますが、非常に情報が豊富です。
また、現在は論争の的となっています。最近、数人の人々が、さまざまな要約に追加する情報をさらに要求しました。彼らが求めているデータはすべてシステムに存在しますが、問題のあるタブとデータを見つけるには、子オブジェクトの2つの層をドリルダウンする必要があります。
トップレベルで詳細を提示するメリット（および埋没した詳細の時間と労力を節約するメリット）は理解していますが、概要ページには限られたスペースがあり、すべての部門が重要であると考えるすべての詳細を表示する場合は、要約ではなくなり、すべてのオブジェクト全体になります。
データモデルをフラット化せずに、各部門が気にするデータに簡単にアクセスできるようにするにはどうすればよいですか（そして、すべての人にとってそれを悪化させます）？
撃ち落とされたいくつかの可能性（ただし、再考される可能性があります）：
- 概要をユーザーがカスタマイズ可能なテーブルとして表示できるため、ユーザーはどの列であるかを決定できます。ただし、リクエストの一部は、添付されたドキュメントをダウンロードしたり、掘り下げることなく子オブジェクトを表示したりする機能などを処理します。これらの場合、テーブルは役に立ちません。さらに、表示可能な列のリストは非常に膨大です。
- 各部門に固有のページと、部門ごとに調整されたデータのビューを提供できます。ただし、私たちの開発チームは小さすぎ、現在のバックログを考えると、これほど多くの追加作業を完了することは不可能です。また、一部の人々は複数の部門に所属しているため、どのビューを取得するかを決定することは簡単ではありません。
- データモデルをスクラップしたり、これらのさまざまなリクエストに対応できるように再加工したり、エンティティの関係を変更したりすることもできますが、開発チームは小さすぎます。
編集：
オプション2は多くのサポートを得ているようですが、それは理解できます。問題は、必要以上の作業をせずに必要なビューのカスタマイズを作成する方法が見当たらないことです。
たとえば、データは非常に厳密な階層です。通常、ツリー内の各ノードには2つのブランチがあり、さらに2つ以上のブランチがあり、以下同様に4〜5レベルです。
ある部門では、顧客とその注文履歴の簡単な概要を確認できるようにしたいと考えています。別の部門が、1人の顧客がこれまでに注文したすべてのウィジェットのシリアル番号をすべて表示できるようにしたいと考えています。結合する必要のあるデータベーステーブルの数と種類を含む階層をトラバースするには、かなりの時間がかかるため、どちらもすぐには使用できません。
現在のページは、これらの2つの極端な状況の折衷案であり、ユーザーは読み込み時間をそれほど犠牲にすることなく、可能な限り多くの詳細を取得しますが、ウィジェットの詳細の一部についてまだ調査する必要があります。要約を必要とする部門をスキミングするには遅すぎるし、困難であり、詳細を必要とする部門をドリルダウンするには時間がかかりすぎます。
データモデルには時々小さな変更があり、オプション2は新しいノードまたはブランチタイプが導入されたときに追加の2〜5ページを維持することを意味します。同様に、データにウィンドウを提供するカスタムAPIを維持します。 （モデルに関するこれらの問題が、オプション3がリストにある理由です。）
オプション2を使用する場合、高速で実行でき、保守が簡単で、使用/カスタマイズが簡単なものを探していると思います。しかし、たぶん私は3つのうち2つに落ち着かなければならないでしょうか？
これは、ユーザー調査が貴重な情報であり、実際にさまざまなユーザーグループとディスカッションを行って、ユーザーが探している正確な情報とは何か、ユーザーが細かいところまで掘り下げたいケースを確認する必要がある場合だと思います。データの。私の経験では、一般に、ユーザーは通常すべてにアクセスしたいが、通常は必要に応じてドリルダウンするオプションを備えた統合ビューを探していることがわかりました。
したがって、私の提案は次のようにすることです
- 潜在的なデータソースのリストと、画面に表示できる情報を確立する
- ユーザーグループとそれらのユーザーグループの主要な関係者のリストを確立する
- それらの利害関係者とのディスカッションで、何が見たいかについて定義し、何が最も重要であり、何が二次レベルで表面化できるかという点で優先順位を付けるように依頼します。
- データを表示する方法と、ユーザーがドリルダウンできるようにする方法に関して、ダッシュボード設計のベストプラクティスを見てください。
ここにあなたが始めるためのいくつかのリソースがあります
2番目のリンクについては、これらの質問を注意深く検討することをお勧めします。これらの質問は、焦点を明確にし、ユーザーへのコンテンツ提供の開始点を確立するのに役立ちます。
どのデータを表示すべきか
ダッシュボードにアクセスする特定のユーザーの主な理由は何ですか？ユーザーは特定のイベントまたは状況に決定を下したり、反応したりしていますか？
ユーザーがダッシュボードにアクセスするきっかけは何ですか？ユーザーにダッシュボードを表示するように促すのは何ですか？就業日の開始時にユーザーが定期的に確認する情報はありますか？または、システム生成の電子メールアラートに応答して、ユーザーはダッシュボードに移動しますか？
ユーザーがダッシュボードにアクセスする頻度はどれくらいですか？週に1回または1日に数回ですか？ユーザーが評価しようとしているのは何ですか？ダッシュボードはどのようにしているかなどの質問に答えますか？もしそうなら、その質問を完了してください：どのように私たちは何をしていますか？
ユーザーはどのような重要な決定を行う必要がありますか？たとえば、ダッシュボードはリソースの再割り当てについてユーザーに通知しますか？もしそうなら、それはユーザーが情報に基づいた決定をするのを助けるために利用できる最も重要な情報を作る必要があります。
ユーザーに警告する必要がある条件はありますか？たとえば、産業用制御ダッシュボードは、重要なパラメータが範囲外であることをユーザーに警告する場合があります。これは、車のダッシュボードのガスゲージまたはエンジン温度ゲージに似ています。これは、定量的な状態をユーザーに通知するだけでなく、タンク内のガスの量が少ないか、エンジン温度が高すぎる場合にユーザーに警告します。
ここですべての答えに同意します。
オプション2に基づいて検討できる別のオプションを追加したいと思います。
モジュラーコンテンツ/データブロックを構築します。
課題は割り当てられたカスタムダッシュボードの作成にあると思われるので、これをユーザーが指示することはできませんか？
まず、すべてのコンテンツへのユニバーサルアクセスを提供し、各ユーザーがダッシュボードに表示したいコンテンツを「お気に入り」にする方法を作成することをお勧めします。
私はOmnitureのようなAnalytics Suitesでこの作品を見てきましたが、多様なオーディエンスが直面している課題を考えると最も理にかなっています。
また、開発チームにとってもはるかに管理しやすくなります。
オプション2は正しい方法のようです。
2.各部門に固有のページと、部門に合わせたデータのビューを提供できます。ただし、私たちの開発チームは小さすぎ、現在のバックログを考えると、これほど多くの追加作業を完了することは不可能です。また、一部の人々は複数の部門に所属しているため、どのビューを取得するかを決定することは簡単ではありません。
あなたのウェブサイトはそれらに最も意味のあるフォーマットでユーザーにデータを提示するべきです。開発チームが小さすぎることは理解していますが、オプション3で説明されているようにデータモデルを廃棄するのにどれほどのコストがかかるか想像できません。
作業量を軽減する1つの方法は、各部門を定義し、カスタマイズされたビューに優先順位を付けることです。次に、時間と優先順位に応じて、それぞれに連絡します。 1つまたは2つを完了した後、得られたフィードバックは、経営陣が他の部門のカスタマイズされたビューにより高い優先順位を割り当てるように促す場合があります。
また、ユーザーがログインしている場合は、ユーザーがWebサイトにアクセスしたときに部門を決定し、関連するデータのみを提示することをお勧めします（まだ行っていない場合）。複数の部門に属している場合は、複数のビュー（タブ/選択肢）が表示されます。
開発チームにAJAXロードとサブコンテンツのUIへの「ロールダウン」をロードするよう依頼するのは理にかなっていますか？(most-frequently requested * most-politically visible)。チームは、1つの小さな機能を提供するAPIサービスを構築します。
Tiny-APIアプローチは、エンジニアリングが圧倒されて拒否されないようにします。
サブコンテンツの優先順位付けにより、開始する場所を選択できます
UI AJAXの読み込みにより、巧妙な迂回を有効にしてドリルダウンを有効にしながら、混乱を防ぎます。
開発チームは、プロジェクトとスプリントの間に空き時間があるため、このような小さな追加を迅速かつ迅速に提供できます。人々は気分が良くなり、より生産的に見えます。
ボーナスポイント：ユーザーにCookieを送信し、ユーザーが使用するサブコンテンツを[最も多く]記録/カウントし、情報をセッションに添付して、ページの最初のロードAJAXがプリフェッチできるようにします。彼らが通常ドリルダウンするものです。あなたはそれを自動拡張することさえできます...