データビフォアデザイン

データビフォアデザイン は何をしますか？

データのビューの良し悪しを決める三つの要素は、マークアップを書く前にすべて決まっています。それは、ビューがサポートする意思決定、フィールドに実際に入っているもの、そしてユーザーが望む複数のレイアウトのうちどれかです。これらのいずれかを省略すると、見た目は完成しているが間違っているビューができあがります。

いつ使用するか

• 自分が作成していないレコードに対するカード、パネル、テーブル、ダッシュボード、詳細ビュー
• ステークホルダーが「Xを表示して」と言い、Xがカラム名である場合
• フィールドを要約、切り詰め、バッジ表示、ソート、色付け、カウントしようとしている場合
• 同じ情報を2つの方法でレイアウトする選択をしている場合

データが自分自身のフィクスチャである場合や、ビューがすでに出力した単一の値である場合はスキップします。

投稿、共有、またはレポートに含まれる予定のチャートやテーブルも、自分が作成していないレコードを表示する場合は、ここから始まります。データが確定したら、practical-charts がその読みやすさをカバーします。見出しのタイトル、正直な軸、1つのハイライトされた系列、画像内のソースなどです。

ステップ0: 意思決定に名前をつける

データに触れる前に一文を書きます。「これを見ている人は、___を決断している。」 もし一文を完成できないなら、あなたはデータダンプを作成しており、レイアウトの問題には答えがありません。

• すべてのフィールドは、その意思決定を変えることでその場所を得ます。 興味深いが意思決定に中立的なデータは、カードではなく詳細ビューに属します。
• 優先度は意思決定の重みに従い、クエリの都合には従いません。 最も取得しやすいフィールドが、最も大きなフォントサイズに値するフィールドであるとは限りません。
• ステークホルダーがカラム名を挙げた場合、それは彼らが欲しいデータを教えたのであり、意思決定を教えたわけではありません。その値に応じて彼らが何を異なるようにするかを尋ねてください。

ステップ1: フィールドをプロファイリングしてからデザインする

デザインの前にクエリを実行します。ビューが表示するすべてのフィールドに対して：

チェック項目	なぜデザインが変わるか
NULLでない数	すべての行でNULLのフィールドはカードを必要としません — バグレポートが必要です
ユニーク値	4つの値はチップセット。4000は検索ボックス
長さ: 最小 / 平均 / p95 / 最大	平均はあふれを隠します — コンテナサイズはp95に合わせ、テール部分を意図的に決定します
レコード間のカバレッジ	レコードの1.6%で発火するカードは、まれな例外を伴う空の状態です
親ごとのカーディナリティ	1人あたり1つのメモは段落。20は独自のアフォーダンスを持つリスト
日付の存在	日付を持たないフィールドの鮮度を表示することはできません
語彙	8つの異なる表現を持つ自由テキストは、レンダリングではなく正規化が必要です
比較対象が存在するか	裸の数字は読めません — 以下を参照

デザインを提案する前に、数値で見つけたことを述べてください。

画面上のすべての数字には、比較対象が必要です

52 notes は読者に何も伝えません。多いかどうか判断できないからです。52 notes (中央値 4) は発見です。カウント、合計、またはスコアを表示する前に、その比較対象 — 中央値、目標、前期間、またはセットの残り — を見つけ、一緒に表示してください。比較対象が存在しない場合、それはその数字を画面に表示すべきでないという証拠です。

退化したケースは、決して変動しない数字です。すべてのレコードに当てはまるカウントは、発見として読まれ、ノイズになります。

ステップ2: オプションをモックしてから構築する

カード形状のものについては、実際のレコードから複数の静的なモックを作成し、ユーザーに選ばせてください。その後でのみ構築します。

• 各オプションが何を最適化し、何を犠牲にするかを一文で述べてください
• モックは使い捨てのHTMLであり、コンポーネントではありません — ワイヤリングしないでください

6つの状態をモックし、1つだけではない

ビューが取りうるすべての状態を、それぞれ実際のレコードからデザインします：

状態	描画元
理想	典型的なレコード — あなたが選んだものではなく、中央値のレコード
空	フィールドに何もないレコード、および レコードがまったくない真新しいアカウント
部分	一部のフィールドが埋まり、一部が埋まっていない — 実際のデータではこれが一般的であり、例外ではない
ローディング	データが到着する前に領域を占有するもの、データのサイズで
エラー	フェッチに失敗した、または値が不正でレンダリングできない
完了	ビューが提供するアクションが実際に発生したことを確認するもの

次にストレスケース

ボリュームの極端（最もビジー、典型的、空）だけが唯一の極端ではありません。ストレスケースとは、存在し、整形式で、苦痛を伴うデータです。フィールドがうまく処理できない名前、ステータスが陽気なバッジを間違ったものにするレコード、要約がまだカウントしている削除済みアカウントの人物。このビューを最も恥ずかしくするレコードを1つ選び、レンダリングしてください。

1ページに複数のカード: すべてのカードに1つのキー

読者は最初のカードで色の意味を学習し、それ以降のすべてのカードにそれを適用します。したがって、複数のカードがあるページでカードを描画する前に、ページ全体で1つのカテゴリテーブルを書き留めてください。正規の名前、固定の順序、各カテゴリに1つの色。すべてのカード、凡例、ツールチップがそれを使用します。

• 1つのカテゴリに1つの色。1つの色に1つのカテゴリ。 色は、そのカテゴリが存在しないカードでも、そのカテゴリに属します。他の何かにそれを使用すると、元のカテゴリを決して表示しないカードでも、読者に2つが同じものだと伝えます。
• カテゴリごとに1つの名前。 あるカードで「グローバルヘルス＆開発」、次のカードで「グローバル開発＆ヘルス」では、読者はそれらが2つのカテゴリなのか疑問に思います。
• 同じレコードをカットするカードには1つの分類法。 カードが独自のバケットを追加する前に、それがページにすでにあるカテゴリにマージされるかどうかを確認してください。カードが本当に細かい分割を必要とする場合、新しい色ではなく、親の色の色合いをサブカテゴリに与えてください。
• 本当に異なるカテゴリには未使用の色、および内訳が異なることを示すサブタイトルを付けます。ページが別のカテゴリにすでに与えた色を決して再利用しないでください。
• すべての凡例で同じ順序、「その他」は常に最後で、常に同じニュートラルグレー。

完了条件 ページ全体の（ラベル、色）ペアをリストアップすると、1対1のマッピングになること。レンダリングされたスクリーンショットではなく、マークアップまたはスタイルシートで色の値をgrepしてください。

データから導かれるレンダリングルール

• 空の状態は仕事をする。 「まだメモはありません」は行き止まりです。なぜ空なのか、何がそれを埋めるのかを述べてください。初日にユーザーが出会う空の状態はオンボーディングであり、設計する価値があります。
• テーブル内の数字: 右揃え、表形式の数字（font-variant-numeric: tabular-nums）、列全体で1つの精度、各セルで繰り返すのではなくヘッダーに単位。practical-chartsのルール13に残りがあります：グリッドなし、着色されたキー行、インラインバー。
• デフォルトのソートは設計上の決定です。 レコードが主キー順に到着することは、ソートがないことです。

よくある間違い

間違い	結果
スキーマからデザインする	カラムは存在するが、データは存在しない
意思決定を指定せずに構築する	すべてが等しい重みを持つ。なぜなら、何も大きくなる理由がないから
最も簡単なフィールドに最も優先度を与える	レイアウトはジョブではなくスキーマを記述する
比較対象なしで数字を表示する	読者はそれが良いかどうか判断できず、見るのをやめる
常に真であるものをカウントする	決して変動しないカウントは発見として読まれ、ノイズになる
データを見る前に書かれた計画を信頼する	データがサポートするものではなく、計画が命名したものを構築する
理想の状態のみをモックする	何も持たない、または半分しか持たないレコードでデザインが崩壊する
ボリュームの極端のみをテストする	ビューは最大のレコードを生き残り、普通のレコードで誰かを辱める
最初に説明されたため1つのオプションを構築する	ユーザーは決して示されなかったものを選択できない
カードごとに色とラベルを選ぶ	同じ青が1ページで2つのことを意味し、読者は存在しないリンクを描く

非自明な部分の出典

• 意思決定ファースト、意思決定の重みによる優先度 — Stephen Few, Information Dashboard Design
• 数字には比較対象が必要 — Few 再び、コンテキストが数字に意味を与えるものとして
• 6つの状態 — Scott HurffのUIスタック
• ストレスケース — Eric Meyer & Sara Wachter-Boettcher, Design for Real Life