Warum die Tabelle das am meisten unterschätzte UI-Muster ist — und wie du Spalten, Filter, Sortierung und Zustände so gestaltest, dass Nutzer:innen auch bei tausenden Zeilen den Überblick behalten
Die meisten Portfolio-Stücke, die Designer:innen herzeigen, sind Landingpages, Onboarding-Screens oder ein schön gerendertes Dashboard mit vier bunten Kacheln. Kaum jemand zeigt eine Tabelle. Dabei ist die Tabelle in fast jedem echten Produkt der Bildschirm, auf dem die Nutzer:innen die meiste Zeit verbringen — die Liste der Kinder in einer Kita-Software, die Übersicht aller Artikel in einem Redaktionssystem, die Buchungen, die Rechnungen, die Teilnehmenden.
Ich habe über Jahre an genau solchen Oberflächen gearbeitet, und die Tabelle ist jedes Mal der Ort, an dem sich entscheidet, ob ein Produkt sich professionell anfühlt oder nach Verwaltungsakt. Ein hübsches Empty State beeindruckt im ersten Screenshot. Eine Tabelle mit dreitausend Zeilen, in der man trotzdem in zwei Sekunden findet, was man sucht, beeindruckt jeden Tag aufs Neue.
Dieser Artikel handelt von dem am meisten unterschätzten UI-Muster im Product Design: der datenlastigen Ansicht. Tabellen, Listen, Filter, Sortierung — und die vielen kleinen Entscheidungen, die darüber bestimmen, ob große Datenmengen beherrschbar bleiben oder in Rauschen ersticken.
Eine Tabelle wirkt trivial. Zeilen, Spalten, fertig — was soll man da gestalten? Genau diese Annahme ist der Grund, warum so viele Tabellen schlecht sind. Sie werden nicht gestaltet, sie werden ausgeschüttet: Das Backend liefert dreiundzwanzig Felder, also stehen dreiundzwanzig Spalten im Interface. Niemand hat entschieden, was davon wichtig ist, weil die Tabelle als Datenausgabe behandelt wurde und nicht als Interface.
Der Denkfehler dahinter ist verständlich. Bei einem Formular oder einem Onboarding-Flow ist offensichtlich, dass jemand etwas gestalten muss. Eine Tabelle sieht aus, als wäre sie schon fertig, sobald die Daten drin sind. Aber eine Tabelle ist kein Datencontainer, sie ist ein Werkzeug zum Entscheiden. Menschen öffnen eine Tabelle nicht, um Daten zu betrachten — sie öffnen sie, um eine bestimmte Zeile zu finden, mehrere Zeilen zu vergleichen oder eine Aktion auf eine Auswahl anzuwenden.
Merksatz: Eine Tabelle ist kein Ausgabeformat, sondern eine Entscheidungshilfe. Wenn du nicht benennen kannst, welche Entscheidung deine Nutzer:innen darin treffen, kannst du sie auch nicht gestalten.
Sobald du das ernst nimmst, ändert sich die erste Frage. Sie lautet nicht mehr „Welche Daten haben wir?", sondern „Was will jemand mit dieser Liste tun?". In der Kita-Software, an der ich gearbeitet habe, war die Antwort fast nie „ich will alle Kinder sehen". Sie war „ich will die drei Kinder finden, deren Beobachtung diese Woche fällig ist". Das ist eine völlig andere Aufgabe — und sie verlangt eine völlig andere Tabelle als eine bloße alphabetische Vollständigkeitsliste.
Die erste und folgenreichste Entscheidung ist, welche Spalten überhaupt in die Tabelle gehören — und in welcher Reihenfolge. Der häufigste Fehler ist Demokratie: Jedes Feld bekommt seine Spalte, alle gleich breit, alle gleich betont. Das Ergebnis ist eine Wand aus gleichwertig aussehenden Informationen, in der das Auge keinen Ankerpunkt findet.
Eine gute Tabelle hat eine klare Spaltenhierarchie:
Diese Priorisierung ist unbequem, weil sie voraussetzt, dass jemand eine Meinung hat. Das Backend hat keine Meinung; es liefert alles gleich gern. Deine Aufgabe als Designer:in ist es, die Meinung zu liefern — und das heißt manchmal, gegen den Reflex zu argumentieren, „lieber alles anzuzeigen, man weiß ja nie". Man weiß es doch: Aus dem tatsächlichen Nutzungsverhalten lässt sich fast immer ablesen, welche drei Spalten die Arbeit tragen.
Beispiel: In einer Publishing-Oberfläche haben wir die Autorenspalte aus der Standardansicht genommen, obwohl das erst Widerstand auslöste. Es stellte sich heraus, dass fast niemand nach Autor sortierte — aber alle nach Status und Änderungsdatum. Die schmalere Tabelle war messbar schneller zu bedienen, und den Autor fand man weiterhin in der Detailansicht.
Wenn die Spalten stehen, entscheidet die Zeile über die Lesbarkeit. Hier machen kleine, fast unsichtbare Regeln den Unterschied zwischen einer Tabelle, die man gern benutzt, und einer, bei der die Augen nach zwei Minuten müde werden.
Zahlen gehören rechtsbündig, Text linksbündig. Das ist keine Geschmacksfrage. Rechtsbündige Zahlen richten die Einer-, Zehner- und Hunderterstellen untereinander aus, sodass man Größenordnungen auf einen Blick vergleichen kann, ohne zu lesen. Eine Spalte mit linksbündigen Beträgen zwingt jede Zeile zu einem eigenen Leseakt. Für Zahlen lohnt sich außerdem eine Schrift mit Tabellenziffern (font-variant-numeric: tabular-nums), damit jede Ziffer gleich breit ist und die Spalten wirklich fluchten.
Dichte ist eine Entscheidung, kein Default. Wie viel Luft eine Zeile bekommt, hängt vom Kontext ab. Eine Analystin, die den ganzen Tag Datensätze vergleicht, will hohe Dichte und viele Zeilen ohne Scrollen. Jemand, der zweimal pro Woche eine Buchung anlegt, ist mit luftigen, gut tippbaren Zeilen besser bedient. Wenn du es beiden recht machen willst, biete eine Umschaltung zwischen „kompakt" und „komfortabel" an — aber setze einen bewussten Standard, statt die Zeilenhöhe dem Zufall zu überlassen.
Zebra-Streifen sind nicht immer die Antwort. Abwechselnd eingefärbte Zeilen helfen dem Auge, die Spur über breite Tabellen zu halten. Bei schmalen Tabellen mit wenigen Spalten erzeugen sie dagegen nur unruhiges Streifenmuster. Eine dezente Trennlinie oder etwas mehr vertikaler Abstand tut es oft besser. Wichtiger als das Muster ist ein klarer Hover-Zustand, der die ganze Zeile hervorhebt: Er ist die Führungslinie, an der man beim Ablesen einer breiten Zeile entlanggleitet.
Sortierung und Filter sind die Werkzeuge, mit denen aus dreitausend Zeilen die drei werden, die gerade zählen. Sie sind das Herzstück jeder ernsthaften Tabelle, und sie sind der Ort, an dem die meisten Interfaces zu viel oder zu wenig tun.
Bei der Sortierung ist die häufigste Schwäche, dass ihr Zustand unsichtbar bleibt. Nutzer:innen klicken auf einen Spaltenkopf, die Zeilen springen um — aber nichts zeigt an, nach welcher Spalte in welche Richtung jetzt sortiert ist. Ein kleines Pfeilsymbol im aktiven Kopf, das seine Richtung anzeigt, kostet fast nichts und beantwortet die Frage „Warum steht das hier oben?" bevor sie entsteht. Ebenso wichtig: ein sinnvoller Standard. Eine Aufgabenliste, die frisch geöffnet nach fälligstem Datum sortiert ist, hat die Arbeit oft schon getan, bevor jemand einen Filter anfasst.
Beim Filtern ist die Kernfrage, wie viel Komplexität du sichtbar machst. Es gibt grob drei Stufen, und der Fehler ist meist, gleich mit der dritten zu starten:
Was immer du baust: Der aktive Filterzustand muss sichtbar bleiben. Nichts frustriert mehr als eine Tabelle, die scheinbar leer ist, weil drei Filter aktiv sind, die man nicht mehr sieht. Zeige gesetzte Filter als entfernbare Chips über der Tabelle, mit einem klaren „Alle zurücksetzen". Die Filter selbst sind übrigens ein kleines Formular — und alles, was gute Formulare in Web und App ausmacht, gilt hier genauso: klare Beschriftungen, sinnvolle Voreinstellungen, nachvollziehbare Zustände.
Sobald Suche ins Spiel kommt, wird die Tabelle zur Ergebnisseite. Eingabefeld, Autocomplete, das Zusammenspiel von Freitextsuche und gesetzten Filtern — das ist ein eigenes, tiefes Thema, das ich in Suchfunktionen für Web und App ausführlicher behandelt habe. Für die Tabelle zählt vor allem: Suche und Filter dürfen sich nicht gegenseitig heimlich aufheben, und das Ergebnis muss immer erklären, warum es so aussieht, wie es aussieht.
Tipp: Formuliere über jeder gefilterten Tabelle einen kurzen Ergebnissatz — „14 von 312 Buchungen, gefiltert nach: offen, August". Dieser eine Satz beantwortet drei Fragen gleichzeitig: Wie viel wird angezeigt, wie viel gibt es insgesamt, und warum sehe ich genau das?
Eine Tabelle hat mehr Zustände, als das Design in Figma meist zeigt. In der Ruheansicht mit einer Handvoll Zeilen sieht jede Tabelle gut aus. Interessant wird es an den Rändern — und die Ränder sind es, an denen Produkte im Alltag scheitern.
Der leere Zustand ist nicht gleich leerer Zustand. Es macht einen großen Unterschied, ob eine Liste leer ist, weil noch nie etwas angelegt wurde, oder weil ein Filter gerade alles wegfiltert. Der erste Fall braucht eine Einladung: erklären, was hier entstehen wird, und den ersten Schritt anbieten. Der zweite Fall braucht das genaue Gegenteil — keine Ermutigung zum Anlegen, sondern den Hinweis „Kein Ergebnis für diese Filter" und einen Knopf, der sie zurücksetzt. Wer beide Fälle in einen einzigen „Nichts gefunden"-Screen wirft, führt die Hälfte der Nutzer:innen in die Irre. Wie viel in diesen leeren Momenten steckt, habe ich in einem eigenen Text über leere Zustände im Product Design beschrieben; in der Tabelle sind sie besonders folgenreich, weil man sie garantiert erreicht.
Der Ladezustand entscheidet über das gefühlte Tempo. Ein Spinner mitten im leeren Raum lässt die Seite kaputt wirken. Ein Skelett, das die kommende Tabellenstruktur andeutet — graue Balken in Zeilenform —, signalisiert „gleich ist es da" und hält das Layout ruhig, sodass beim Erscheinen der Daten nichts springt.
Der volle Zustand ist der, den man am leichtesten vergisst und am sichersten trifft. Was passiert bei zehntausend Zeilen? Hier stehen zwei Muster zur Wahl:
Und einen Zustand vergisst man fast immer im Entwurf: die eine Zeile mit dem viel zu langen Inhalt. Der Name, der doppelt so lang ist wie die Spalte. Die Notiz mit drei Absätzen. Gestalte für den Ausreißer, nicht für den Durchschnitt — mit Umbruch, Kürzung samt vollständigem Tooltip oder einer definierten Maximalbreite. Sonst sprengt eine einzige echte Zeile das Layout, das mit den hübschen Beispieldaten so gut aussah.
Eine Tabelle ist selten nur zum Ansehen da. Meistens will jemand etwas tun: eine Zeile öffnen, mehrere auswählen, einen Status ändern, etwas löschen. Wie du diese Aktionen anbietest, entscheidet über den Rhythmus der täglichen Arbeit.
Für die Einzelaktion gilt: Die häufigste Aktion sollte die niedrigste Hürde haben. Wenn „Öffnen" das ist, was neunzig Prozent der Klicks ausmacht, dann sollte ein Klick auf die Zeile öffnen — nicht ein winziges Icon am rechten Rand. Seltenere Aktionen dürfen in ein Kontextmenü pro Zeile wandern. Ein Sonderfall ist die Inline-Bearbeitung: einen Wert direkt in der Zelle ändern, ohne die Detailseite zu öffnen. Sie ist herrlich schnell und heikel zugleich, weil der Übergang zwischen Anzeigen und Bearbeiten klar sein muss und ein Fehlerzustand mitten in der Tabelle Platz braucht.
Für die Mehrfachauswahl brauchst du drei Dinge, die zusammengehören: Auswahl-Checkboxen pro Zeile, eine Auswahl-alle-Option im Kopf und eine Aktionsleiste, die erscheint, sobald etwas ausgewählt ist. Diese Leiste sollte klar sagen, wie viele Zeilen betroffen sind — „3 ausgewählt" —, bevor jemand auf „Löschen" drückt.
Warnung: Bei destruktiven Aktionen auf eine Auswahl ist die Zahl im Bestätigungsdialog kein Detail, sondern die Sicherung. „3 Buchungen endgültig löschen?" verhindert genau den Fehler, bei dem jemand ein „Alle auswählen" über Seitengrenzen hinweg unterschätzt hat.
Zwei Klassiker, die in der Praxis regelmäßig wehtun: Erstens die Frage, was „Alle auswählen" eigentlich meint — die sichtbare Seite oder den ganzen gefilterten Datensatz? Beides ist legitim, aber es muss ausgesprochen werden, am besten mit einer Zeile wie „Alle 14 auf dieser Seite ausgewählt — stattdessen alle 312 auswählen?". Zweitens der Umgang mit dem Ergebnis: Nach einer Massenaktion muss die Tabelle zeigen, was geschehen ist — was aktualisiert wurde, was fehlschlug — statt kommentarlos neu zu laden.
Der Satz, der die meisten Tabellen ruiniert, lautet: „Auf dem Handy machen wir sie einfach scrollbar." Horizontales Scrollen durch zwölf Spalten auf einem Telefon ist keine responsive Lösung, sondern eine Kapitulation. Es gibt bessere Wege, und welcher passt, hängt davon ab, was Menschen mobil mit den Daten tun.
Der Denkfehler bei responsiven Tabellen ist, das Layout schrumpfen zu wollen, statt die Aufgabe neu zu denken. Die Frage ist nicht „Wie quetsche ich diese Tabelle auf 375 Pixel?", sondern „Was will jemand hier mobil wirklich tun — und wie sieht das Werkzeug dafür aus?".
Es gibt eine gute Nachricht bei Tabellen: HTML hat für sie ein eigenes, semantisch reiches Vokabular. Eine echte <table> mit <th>-Kopfzellen, scope-Attributen und einer <caption> ist für Screenreader-Nutzer:innen ein komfortables Instrument — sie können von Zelle zu Zelle springen und hören dabei immer, in welcher Spalte und Zeile sie sich befinden. Die schlechte Nachricht: Diese Semantik wird routinemäßig weggeworfen, wenn Tabellen aus lauter <div>-Elementen zusammengesetzt werden, weil sich das leichter stylen lässt.
Der erste und wichtigste Schritt ist deshalb der unspektakulärste: echte Tabellen-Semantik verwenden. Wer das ernst nimmt, bekommt einen großen Teil der Barrierefreiheit geschenkt. Darauf bauen die weiteren Punkte auf:
aria-sort auch in die Ausgabe für Screenreader.Das ist kein Sonderaufwand für eine Randgruppe. Eine Tabelle, die man vollständig mit der Tastatur bedienen kann, ist auch für Power-User schneller — und die Klarheit, die Screenreader brauchen, ist dieselbe Klarheit, die allen hilft. Warum sich diese Investition doppelt lohnt, habe ich in Barrierefreiheit im UX-Design grundsätzlicher ausgeführt; in datenlastigen Ansichten wird sie besonders sichtbar, weil hier am meisten Interaktion auf engstem Raum passiert.
Die Tabelle ist der ehrlichste Test für Product Design. Ein Marketing-Screen darf schön und ungefähr sein; eine Tabelle muss funktionieren, jeden Tag, mit echten Daten, in allen ihren Zuständen. Sie belohnt niemanden für gutes Aussehen und bestraft jede Nachlässigkeit sofort.
Die wichtigsten Hebel noch einmal in Kürze:
Wenn du das nächste Mal ein Produkt gestaltest, verbring bewusst mehr Zeit auf dem Bildschirm, den alle jeden Tag benutzen — und weniger auf dem, den nur die Startseite zeigt. Die Tabelle ist selten das Stück, mit dem man ein Portfolio gewinnt. Aber sie ist fast immer das Stück, mit dem man ein Produkt gewinnt.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Der Text wurde mit KI auf Rechtschreibung und Grammatik geprüft. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Zusammenarbeit
Ich übersetze komplexe Anforderungen in klare, nutzerfreundliche Interfaces — von der Konzeption bis zum Developer-Handoff.
Warum die Suche in vielen Produkten unterschätzt wird — und wie du Eingabefeld, Autocomplete, Ergebnisseite, Filter und Empty States so gestaltest, dass Menschen schneller finden, was sie suchen
Warum Typografie in Web und App eine eigene Designdisziplin ist — und wie du Type-Systeme, Hierarchie und Lesbarkeit so aufbaust, dass sie Marke, UX und Performance gleichzeitig stärken
Wie du Formulare in Web- und App-Produkten so gestaltest, dass sie Vertrauen schaffen, Abbrüche reduzieren und barrierefrei funktionieren — vom Input-Feld bis zum Fehlerzustand
Du planst ein digitales Produkt, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.