Field Note: Warum ich Daten strukturiere, bevor ich Oberflächen baue

Ich beginne nicht mit dem Bildschirm

Ich frage zuerst: Welche Entitäten gibt es und wie hängen sie zusammen? Erst danach frage ich, wie eine Seite aussehen soll. Diese Reihenfolge ist für mich kein theoretischer Umweg. Sie hilft mir, ein digitales System so zu bauen, dass seine Oberfläche nicht mehr verspricht, als die Daten dahinter tatsächlich hergeben.

Der erste Impuls ist oft ein sichtbarer: eine Startseite, eine Suche, ein Filter oder ein Vergleich. Das ist verständlich. An einer Oberfläche lässt sich schnell zeigen, was ein Produkt ungefähr können soll. Aber sobald ich genauer hinschaue, merke ich, dass die interessanteren Fragen darunter liegen. Was ist hier eigentlich ein eigenständiges Ding? Was gehört zu etwas anderem? Welche Beziehung muss das System kennen, damit eine gewünschte Ansicht überhaupt zuverlässig entstehen kann?

Eine Krankenkasse ist nicht dasselbe wie eine Leistung. Eine Pflanze ist nicht dasselbe wie ein Problem, das an ihr auftreten kann. Ein Ausflugsziel ist nicht einfach nur ein Eintrag in einer Liste. Wenn ich diese Dinge zuerst als Seiten oder Karten denke, übernehme ich unbemerkt schon Entscheidungen über ihre Struktur. Später werden diese Entscheidungen sichtbar: in Filtern, Verknüpfungen, Formularen und in der Frage, ob sich Inhalte sinnvoll wiederverwenden lassen.

Die Oberfläche ist eine Ansicht, nicht das Modell

Eine Oberfläche zeigt einen Ausschnitt aus einem System. Sie kann Daten ordnen, zusammenfassen und zugänglich machen. Sie sollte aber nicht die einzige Stelle sein, an der die Bedeutung dieser Daten festgelegt wird.

Wenn ich zum Beispiel eine Vergleichsansicht entwerfe, muss ich vorher verstehen, was verglichen wird und welche Merkmale dafür relevant sind. Bei einer Suche stellt sich die Frage, welche Eigenschaften sich als Filter eignen und welche Begriffe nur redaktionelle Beschreibungen sind. Bei einer Detailseite muss klar sein, welche Information zum dargestellten Objekt gehört und welche aus einer Beziehung zu anderen Objekten entsteht.

Ohne ein solches Modell können Seiten trotzdem entstehen. Sie sehen vielleicht sogar überzeugend aus. Aber die Struktur bleibt oft in der Darstellung versteckt. Inhalte werden mehrfach gepflegt, Beziehungen sind schwer zu erkennen, und jede neue Ansicht braucht zusätzliche Sonderregeln. Die Oberfläche wirkt dann wie ein fertiges Produkt, während das System darunter noch aus einzelnen Seitentypen und Ausnahmen besteht.

Was ich zuerst prüfe: Welche Dinge müssen im System eigenständig existieren, welche Merkmale gehören zu ihnen, und welche Beziehungen müssen auch außerhalb einer einzelnen Seite verständlich bleiben?

Was sich in konkreten Datenwelten zeigt

Bei Wendewerk stehen Krankenkassen und Leistungen im Mittelpunkt. Das sind unterschiedliche Arten von Dingen, die miteinander in Beziehung stehen. Wenn ich sie gedanklich zu einer einzigen großen Seite zusammenziehe, wird es schwieriger, die Struktur dahinter zu verstehen. Ein Modell macht dagegen sichtbar, was jeweils eigenständig gepflegt wird und wie daraus verschiedene Ansichten entstehen können.

Bei Garten 1x1 stehen Pflanzen und Probleme unter anderem als unterschiedliche Inhaltstypen nebeneinander. Diese Trennung ist nicht bloß eine technische Ordnung. Sie beschreibt, dass ein Pflanzenprofil und ein Problem verschiedene Aufgaben im System haben. Eine Oberfläche kann sie später verbinden, aber sie muss nicht so tun, als wären sie dasselbe Objekt.

Bei erlebe-nrw geht es um Ausflugsziele. Auch hier ist der einzelne Datensatz nicht automatisch schon eine gute Seite. Erst die Struktur und die Beziehungen, die das System kennt, schaffen eine Grundlage für unterschiedliche Zugänge zu den Zielen. Die Oberfläche kann darauf aufbauen, ohne die Bedeutung jedes Eintrags allein über sein Layout festzulegen.

Diese Beispiele sind verschieden, aber die Frage am Anfang ist ähnlich: Was bildet das System ab? Sobald ich darauf eine brauchbare Antwort habe, kann ich über Darstellung sprechen, ohne sie mit der zugrunde liegenden Struktur zu verwechseln.

Modellieren heißt auch, Grenzen zu setzen

Daten vor Oberflächen zu setzen bedeutet für mich nicht, vorab jedes denkbare Feld und jede spätere Funktion festzulegen. Ein Modell kann auch zu groß werden. Wenn ich alle möglichen Sonderfälle vorsorglich einbaue, wird die Struktur schwerer, ohne dass dadurch automatisch mehr Klarheit entsteht.

Ich versuche deshalb, vom tatsächlichen Zweck des Systems auszugehen. Welche Dinge müssen unterscheidbar sein? Welche Beziehungen braucht eine konkrete Aufgabe? Welche Information muss eigenständig gepflegt werden? Und welche Ansicht soll später daraus entstehen? Die Fragen gehören zusammen, aber ich stelle sie nicht alle gleichzeitig. Erst brauche ich ein Verständnis der Datenwelt, dann kann ich beurteilen, welche Darstellungen sinnvoll sind.

Dabei hilft mir auch, zwischen einer Eigenschaft und einer Beziehung zu unterscheiden. Eine Beschreibung, die zu einem einzelnen Objekt gehört, ist etwas anderes als ein Verweis auf ein anderes Objekt. Das klingt einfach, aber in der Umsetzung kann diese Entscheidung darüber bestimmen, ob Informationen konsistent bleiben und an mehreren Stellen verwendet werden können. Ich muss dafür nicht jedes Modell maximal abstrahieren. Ich muss aber wissen, welche Bedeutung eine Struktur im Alltag des Systems hat.

Eine Sache hat sich bei mir verändert: Ich behandle das Datenmodell nicht mehr als technische Vorarbeit, die erledigt sein muss, bevor das eigentliche Design beginnt. Es ist Teil des Designs. Es bestimmt mit, welche Fragen eine Oberfläche stellen kann, welche Antworten sie geben darf und welche Änderungen später möglich bleiben.

Von der Struktur zur Darstellung

Wenn die Entitäten und ihre Beziehungen klarer sind, wird die Arbeit an der Oberfläche konkreter. Dann kann ich fragen, welche Informationen zuerst sichtbar sein sollen, welche Nutzeraufgabe eine Seite unterstützt und welche Wege durch die Inhalte sinnvoll sind. Das Layout folgt nicht mechanisch aus dem Datenmodell. Aber es muss sich an dem orientieren, was das System über seine Inhalte tatsächlich weiß.

Diese Reihenfolge verhindert nicht jede spätere Änderung. Sie macht Änderungen aber verständlicher. Wenn eine neue Ansicht gebraucht wird, kann ich prüfen, ob die vorhandenen Daten dafür ausreichen oder ob das Modell selbst angepasst werden muss. Wenn etwas nur in einer bestimmten Darstellung funktioniert, werde ich darauf aufmerksam, bevor ich diese Darstellung mit weiteren Ausnahmen absichere.

Ich möchte damit keine starre Trennung zwischen Gestaltung und Technik behaupten. Für mich hängen beide von Anfang an zusammen. Die Oberfläche hilft, Anforderungen sichtbar zu machen; das Modell hilft, ihre Bedeutung zu klären. Entscheidend ist, dass ich nicht zu früh so tue, als wäre ein hübscher Bildschirm schon ein belastbares System.

Meine Faustregel: Erst kläre ich, welche Dinge das System kennt und wie sie zusammenhängen. Dann gestalte ich die Ansichten, die Menschen brauchen, um mit diesen Dingen sinnvoll zu arbeiten.

Weiterführend

• Content-Modell entwickeln: Von Seiten zu strukturierten Inhalten
• Warum gute SEO mit Datenmodellierung beginnt
• Wendewerk: Plattform für Krankenkassen- und Leistungsdaten