データ操作大画面（データ視覚化大画面要件の開発で見落とされがちな重要なステップ）

データ視覚化の大画面要件の開発で見落とされがちな重要なステップ

編集者注：プロダクトマネージャーやUIデザイナーが大規模なデータ可視化画面のニーズを満たすとき、ビジネスシナリオを明確にすることで指標を決定できるでしょうか？これら 2 つのステップはどのように導き出され、接続されるのでしょうか?指標は水面上の氷山の目に見える部分のようなものですが、水面下の隠れたが重要なサポート部分はまだ漠然としていてぼんやりしています。この記事の著者はこれを分析し、皆さんと共有しました。

既存の需要開発ステップの問題点:

製品マネージャーと UI デザイナーが大規模なデータ視覚化画面のニーズを満たす場合、次のような会話がよく行われます。

一部のプロダクト マネージャーは非常に細心の注意を払いますが、彼らが出力するデモは非常に詳細で、チャートの種類や操作手順も含まれています。しかし、全体的には開発手順は同じです。

何か質問のある方はいらっしゃいますか？なぜビジネスシナリオを明確にすることで主要指標を決定できるのでしょうか?これら 2 つのステップはどのように導き出され、接続されるのでしょうか?

指標は水面上の氷山の目に見える部分のようなものですが、水面下の隠れたが重要なサポート部分はまだ漠然としていてぼんやりしています。

氷山の水面下の部分の探査が今日の議題です。

情報を調べていくうちに、私の疑問はようやく解消されました。私に大きなインスピレーションを与えてくれた「政府可視化設計体験 - ストーリーライン」（元のアドレスは記事の最後にあります）の経験を共有してくれた王良良に感謝します。

この体験は、行政業務の大画面可視化の体験に焦点を当て、シナリオに基づいて複数のストーリーラインを抽出します。ストーリー ラインは、現在のシナリオ内のさまざまな指標を結び付ける目に見えない糸として機能します。

大画面のテーマは政府関係（私たちはネットワーク情報セキュリティ業界です）と多少異なりますが、大画面設計の根底にあるロジックと分析方法は普遍的です。

実際、「ストーリー」という概念は、データ視覚化の分野では珍しい用語ではありません。 Cole Nussbaumer Knaflic 著の「Storytelling with Data」という視覚化デザインに関する本があります。

物語を聞くのが嫌いな人はいないでしょう。良いストーリーは、聴衆に共感を与え、インスピレーションとモチベーションを与えます。ストーリーの価値は大画面のデザインにも適用でき、視聴者がデータを理解し、その美しさと力を感じることを可能にします。大画面のデザイナーは、ストーリーを使用して大画面のコンテンツ（インジケーター）を整理することもできます。

物語を伝えたいのであれば、まず誰に物語を伝えるのかを明確にし、それから物語をどのように伝えるかを決める必要があります。

データ可視化大画面需要開発のシナリオでは、表示コンテンツの種類を決定する前に、まず大画面の表示またはレポートの対象を明確にする必要があります。

B サイド製品は、「ユーザー」と「顧客」という 2 つの概念を対象としています。さらに、分類には他の次元もあります。組織の内部構造に応じて、リーダーシップ、管理、執行およびその他の階層関係、および並列部門などに分けることができます。建設と総請負の関係に応じて、オブジェクトは当事者 A、当事者 B、当事者 C などに分割できます。各特定のユーザーを分析する場合、複数の座標軸の情報を含む全体の座標系でそのユーザーがどこに位置しているかを考慮する必要があります。

異なる座標点のユーザーには、中核的な関心事に関して共通点と相違点の両方があります。ユーザーや顧客に注意を払うことを重視する場合、実際には彼らの中核的な利益に配慮することを意味します。

私は、ストーリー スクリプトの基本的なフレームワークとして、2 つの普遍的なテンプレートを抽出しました。

これは両方のストーリーボードの基礎となるフレームワークであり、ページ レイアウトが水平か垂直かを決定するものではないことに注意してください。

当社の事業はすべてネットワーク情報セキュリティの分野であるため、表示されるコンセプトもこの分野の拡張に基づいています。

3.2.1 連続ストーリー

シナリオ: 重要な資産に重大な脅威をもたらす脆弱性を修復し、セキュリティ インシデントに対応し、インテリジェンスを調査し、影響を受ける資産を保護するなど。

シナリオ: 日常的なセキュリティ運用作業計画の実行を測定および改善し、管理の成熟度を高めます。

シナリオ: ネットワーク セキュリティの分野の多くの用語には、「ライフ サイクル」に似た概念があります。 「始まり」と「終わり」の間には複数の「段階」があります。以下は脆弱性管理プロセスの国家標準定義です。

3.2.2 ツリー型ストーリーライン

シナリオ: 複数の次元でデータを分析し、リーダーシップの意思決定に信頼性の高いデータ サポートを提供します。

シナリオ: 作業結果を上位部署または施工部署（当事者 A）に報告します。

シナリオ: 監視データの集計分析を通じて攻撃の傾向を提示し、予測します。

3.2.3 ネスティングとシャトル

シリアル型でもツリー型でも、フレームワークが高度に抽象化された後のミニマリスト形式です。実際の状況では、大きな画面内に 2 つのフォームがネストされたり、複数の大きな画面が組み合わされてより詳細なストーリーが伝えられたりすることがよくありますが、これはフレームワークの主要な構造には影響しません。

これは大画面要件の開発プロセスにおける小さなステップに過ぎませんが、分析方法には二重ダイヤモンド モデル全体も含まれていることにお気づきでしょうか。最初のダイヤモンドは問題の探索 + 焦点を合わせるために使用され、2 番目のダイヤモンドは発散 + 解決策の明確化に使用され、発散 - 収束 - 再び発散 - 再び収束の法則に従います。

ダブルダイヤモンドモデルは、知らないうちに盲目になる可能性のある単一スレッド思考の罠を回避し、慎重な検討を前提として最善の解決策が検討され出力されることを保証する普遍的なフレームワークです。

類似の問題を効率的に解決するための方法論をまとめようとしますが、その方法論は本質的に万能なものではありません。証拠に基づく思考で、より多くのシナリオで繰り返し検証し、修正する必要があります。

今日の共有は議論を刺激することを目的としており、誰でも議論に参加できます。

参照:

政府視覚化デザイン体験 - ストーリーライン

「データで物語を語る」 コール・ナスバウマー・クナフリック著

著者：杜暁都、公開アカウント：一日中勉強室にいることができる

この記事はもともと、Everyone is a Product Manager で @能呆書房一一天 によって公開されました。許可なく複製することは禁止します。

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです