mickzijdel/data-before-design

Daten vor dem Design

Drei Dinge entscheiden, ob eine Datenansicht gut ist, und alle drei sind geklärt, bevor Sie Markup schreiben: welche Entscheidung die Ansicht unterstützt, was tatsächlich im Feld steckt und welches der mehreren Layouts die Person möchte. Wenn eines davon fehlt, entsteht eine Ansicht, die fertig aussieht und falsch ist.

Wann verwenden

• Jede Karte, Tabelle, jedes Dashboard oder Detailansicht über Datensätze, die Sie nicht selbst erstellt haben
• Ein Stakeholder sagt "Zeig mir X" und X ist ein Spaltenname
• Sie sind dabei, ein Feld zusammenzufassen, zu kürzen, mit Badge zu versehen, zu sortieren, einzufärben oder zu zählen
• Sie wählen zwischen zwei Möglichkeiten, dieselbe Information anzuordnen

Überspringen, wenn die Daten Ihr eigener Testdaten sind oder die Ansicht ein einzelner Wert ist, den Sie bereits ausgegeben haben.

Ein Diagramm oder eine Tabelle, das/die veröffentlicht, geteilt oder in einen Bericht aufgenommen wird, beginnt hier trotzdem, wenn es Datensätze zeigt, die Sie nicht selbst erstellt haben. Sobald die Daten festgelegt sind, behandelt practical-charts, wie es gelesen wird: der Haupttitel, ehrliche Achsen, eine hervorgehobene Serie, die Quelle im Bild.

Schritt 0: Die Entscheidung benennen

Schreiben Sie einen Satz, bevor Sie die Daten anfassen: "Jemand, der dies ansieht, entscheidet über ___." Wenn Sie den Satz nicht beenden können, bauen Sie einen Daten-Wurf, und die Layout-Frage hat keine Antwort.

• Jedes Feld verdient seinen Platz, indem es diese Entscheidung verändert. Interessant aber entscheidungsneutral gehört in die Detailansicht, nicht auf die Karte.
• Prominenz folgt dem Entscheidungsgewicht, nicht der Abfragebequemlichkeit. Das Feld, das am einfachsten abzurufen war, ist nicht das Feld, das die größte Schrift verdient.
• Ein Stakeholder, der eine Spalte nennt, hat Ihnen die Daten genannt, die er will, nicht die Entscheidung. Fragen Sie, was er anders machen würde, abhängig vom Wert.

Schritt 1: Das Feld profilieren, dann designen

Abfragen vor dem Design. Für jedes Feld, das die Ansicht zeigen wird:

Prüfung	Warum es das Design ändert
Nicht-Null-Anzahl	Ein Feld, das in jeder Zeile NULL ist, braucht keine Karte – es braucht einen Fehlerbericht
Anzahl unterschiedlicher Werte	Vier Werte sind eine Chip-Gruppe; viertausend sind ein Suchfeld
Länge: Min / Mittelwert / p95 / Max	Der Mittelwert versteckt den Überlauf – dimensionieren Sie den Container auf p95 und entscheiden Sie bewusst, was der Ausreißer tut
Abdeckung über Datensätze hinweg	Eine Karte, die für 1,6 % der Datensätze ausgelöst wird, ist ein leerer Zustand mit einer seltenen Ausnahme
Kardinalität pro Elternteil	Eine Notiz pro Person ist ein Absatz; zwanzig sind eine Liste mit eigenen Interaktionsmöglichkeiten
Datumsangabe vorhanden	Sie können die Veraltung eines Feldes nicht anzeigen, wenn es kein Datum trägt
Vokabular	Freitext mit acht verschiedenen Formulierungen für "Haus" normalisieren, nicht rendern
Ein Vergleichswert existiert	Eine bloße Zahl ist unlesbar – siehe unten

Geben Sie an, was Sie gefunden haben, bevor Sie das Design vorschlagen, in Zahlen.

Jede Zahl auf dem Bildschirm braucht etwas, mit dem sie verglichen werden kann

52 Notizen sagt dem Leser nichts: Er kann nicht erkennen, ob es viel ist. 52 Notizen (Median 4) ist eine Erkenntnis. Bevor Sie eine Anzahl, Summe oder Punktzahl anzeigen, finden Sie ihren Vergleichswert – einen Median, ein Ziel, den vorherigen Zeitraum oder den Rest der Menge – und zeigen Sie sie zusammen an. Wenn kein Vergleichswert existiert, ist das ein Beleg dafür, dass die Zahl nicht auf dem Bildschirm sein sollte.

Der Extremfall ist eine Zahl, die nie variiert: Eine Anzahl, die für jeden Datensatz zutrifft, wird als Erkenntnis gelesen und ist Rauschen.

Schritt 2: Die Optionen mocken, dann bauen

Erstellen Sie für jede kartenförmige Ansicht mehrere statische Mockups aus echten Datensätzen und lassen Sie die Person wählen. Bauen Sie erst danach.

• Sagen Sie in einem Satz, wofür jede Option optimiert und was sie kostet
• Mockups sind Wegwerf-HTML, keine Komponente – verbinden Sie sie nicht

Sechs Zustände mocken, nicht einen

Gestalten Sie jeden Zustand, den die Ansicht annehmen kann, jeden aus einem echten Datensatz:

Zustand	Zeichnen von
Ideal	Der typische Datensatz – der im Median, nicht der, den Sie ausgesucht haben
Leer	Ein Datensatz mit nichts im Feld, und ein brandneues Konto ganz ohne Datensätze
Teilweise	Einige Felder gefüllt, andere nicht – in echten Daten ist das der Normalfall, nicht die Ausnahme
Laden	Was den Platz einnimmt, bevor die Daten ankommen, in der Größe, die die Daten haben werden
Fehler	Die Abfrage ist fehlgeschlagen, oder der Wert ist fehlerhaft und kann nicht gerendert werden
Erledigt	Was bestätigt, dass eine Aktion, die die Ansicht anbietet, tatsächlich stattgefunden hat

Und dann der Stressfall

Volumenextreme (am stärksten ausgelastet, typisch, leer) sind nicht die einzigen Extreme. Ein Stressfall sind Daten, die vorhanden, wohlgeformt und schmerzhaft sind: der Name, den das Feld verstümmelt, der Datensatz, dessen Status einen fröhlichen Badge falsch macht, die Person, deren gelöschtes Konto die Zusammenfassung immer noch zählt. Wählen Sie den einen Datensatz aus, der diese Ansicht am meisten in Verlegenheit bringen würde, und rendern Sie ihn.

Mehrere Karten auf einer Seite: Ein Schlüssel für alle

Ein Leser lernt die Bedeutung einer Farbe auf der ersten Karte und wendet sie auf jede weitere Karte an. Bevor Sie also Karten auf einer Seite mit mehreren zeichnen, schreiben Sie eine Kategorietabelle für die ganze Seite auf: den kanonischen Namen, eine feste Reihenfolge und eine Farbe für jede Kategorie. Jede Karte, Legende und QuickInfo verwendet sie.

• Eine Kategorie, eine Farbe; eine Farbe, eine Kategorie. Eine Farbe gehört zu ihrer Kategorie, auch auf Karten, auf denen diese Kategorie fehlt. Wenn Sie sie für etwas anderes verwenden, selbst auf einer Karte, die das Original nie zeigt, sagt das dem Leser, die beiden seien dasselbe.
• Ein Name pro Kategorie. „Global Health & Development“ auf einer Karte und „Global Dev & Health“ auf der nächsten lässt den Leser fragen, ob es zwei Kategorien sind.
• Eine Taxonomie, wo die Karten dieselben Datensätze schneiden. Bevor eine Karte ihren eigenen Eimer hinzufügt, prüfen Sie, ob er in eine Kategorie zusammenfällt, die die Seite bereits hat. Wenn eine Karte wirklich eine feinere Aufteilung benötigt, geben Sie den Unterkategorien Schattierungen der Elternfarbe, nicht neue Farben.
• Kategorien, die wirklich anders sind, bekommen ungenutzte Farben, plus einen Untertitel, der besagt, dass die Aufteilung anders ist. Verwenden Sie niemals eine Farbe wieder, die die Seite bereits einer anderen Kategorie gegeben hat.
• Gleiche Reihenfolge in jeder Legende, wobei „Other“ immer zuletzt kommt und immer dasselbe neutrale Grau.

Fertig, wenn das Auflisten jedes (Label, Farbe)-Paares auf der Seite eine Eins-zu-eins-Zuordnung ergibt. Grepen Sie im Markup oder Stylesheet nach den Farbwerten, nicht nach dem gerenderten Screenshot.

Rendering-Regeln, die aus den Daten folgen

• Der leere Zustand leistet Arbeit. „Noch keine Notizen“ ist eine Sackgasse. Sagen Sie, warum es leer ist und was es füllt. Ein leerer Zustand, den ein Benutzer am ersten Tag sieht, ist Onboarding und es lohnt sich, ihn zu gestalten.
• Zahlen in einer Tabelle: rechtsbündig, Tabellenziffern (font-variant-numeric: tabular-nums), eine Genauigkeit für die ganze Spalte, Einheiten in der Kopfzeile statt in jeder Zelle wiederholt. practical-charts Regel 13 enthält den Rest: kein Raster, eine getönte Schlüsselzeile, Balken in der Zelle.
• Die Standardsortierung ist eine Designentscheidung. Datensätze in Primärschlüssel-Reihenfolge anzuordnen ist das Fehlen einer solchen.

Häufige Fehler

Fehler	Was passiert
Vom Schema aus designen	Die Spalte existiert, die Daten nicht
Bauen ohne benannte Entscheidung	Alles bekommt gleiches Gewicht, weil nichts einen Grund hat, größer zu sein
Das einfachste Feld am prominentesten machen	Das Layout beschreibt das Schema, nicht die Aufgabe
Eine Zahl zeigen, ohne Vergleichswert	Der Leser kann nicht erkennen, ob sie gut ist, und hört auf zu schauen
Etwas zählen, das immer wahr ist	Eine Anzahl, die nie variiert, wird als Erkenntnis gelesen und ist Rauschen
Einem Plan vertrauen, der geschrieben wurde, bevor die Daten gesehen wurden	Sie bauen das Ding, das der Plan nannte, nicht das, was die Daten unterstützen
Nur den idealen Zustand mocken	Das Design bricht bei dem Datensatz zusammen, der nichts oder nur halb etwas hat
Nur Volumenextreme testen	Die Ansicht überlebt den größten Datensatz und demütigt jemanden bei einem gewöhnlichen
Eine Option bauen, weil sie zuerst beschrieben wurde	Die Person kann nicht wählen, was ihr nie gezeigt wurde
Farben und Labels Karte für Karte auswählen	Dasselbe Blau bedeutet zwei Dinge auf einer Seite, und der Leser zieht eine Verbindung, die nicht da ist

Woher die nicht offensichtlichen Teile kommen

• Entscheidungsorientiert, und Prominenz nach Entscheidungsgewicht – Stephen Few, Information Dashboard Design
• Eine Zahl braucht einen Vergleichswert – Few wieder, zum Kontext als das, was eine Zahl bedeutungsvoll macht
• Die sechs Zustände – Scott Hurff's UI Stack
• Stressfälle – Eric Meyer & Sara Wachter-Boettcher, Design for Real Life