Spalten, Karten und Drag-and-drop-Feedback
Ein gutes Kanban-Board lebt von klaren Spaltengrenzen, gut lesbaren Karten und sichtbarem Feedback während des Ziehens. Mit Tailwind CSS für Layout und Zustände sowie Alpine.js für Drag-and-drop-Interaktion entsteht ein Board, das auch bei vielen Karten und Spalten übersichtlich bleibt.
Inhaltsverzeichnis
- 1. Warum ein Kanban-Board eigene Styling-Regeln braucht
- 2. Grundstruktur: Spalten und Karten-Layout
- 3. Karten-Design: Priorität, Labels, Avatare
- 4. Horizontales Scrollen der Spalten
- 5. Drag-and-drop visuelles Feedback
- 6. Spalten-Header mit Zähler und Farbe
- 7. Responsive Verhalten: mobile Alternativen
- 8. WIP-Limits visuell darstellen
- 9. Kanban-Board vs. Listen- und Tabellenansicht
- 10. Zusammenfassung
- 11. FAQ
1. Warum ein Kanban-Board eigene Styling-Regeln braucht
Ein Kanban-Board unterscheidet sich strukturell von den meisten anderen Layout-Mustern, weil es zwei Achsen gleichzeitig verwaltet: die horizontale Abfolge der Spalten als Prozessschritte und die vertikale Stapelung der Karten innerhalb jeder Spalte. Diese Doppelstruktur bringt eigene Herausforderungen mit sich, etwa horizontales Scrollen bei vielen Spalten, während gleichzeitig jede einzelne Spalte vertikal scrollbar bleiben muss, ohne dass die gesamte Seite mitscrollt.
Ein zweiter Unterschied zu klassischen Listen-Layouts: Karten in einem Kanban-Board werden aktiv zwischen Spalten verschoben, was direktes visuelles Feedback während des Ziehens erfordert. Ohne dieses Feedback wirkt das Board technisch funktional, aber nicht greifbar. Die folgenden Abschnitte bauen ein vollständiges Kanban-Board auf, von der Grundstruktur über Karten-Design bis zu WIP-Limits.
2. Grundstruktur: Spalten und Karten-Layout
Die Grundstruktur eines Kanban-Boards ist ein Flex-Container mit overflow-x-auto, in dem jede Spalte ein eigenes Flex-Item mit fester Mindestbreite ist. Diese feste Breite verhindert, dass Spalten bei wenigen Karten zusammenschrumpfen und das Board optisch instabil wirken lassen. Innerhalb jeder Spalte sorgt overflow-y-auto mit einer maximalen Höhe dafür, dass viele Karten in einer Spalte scrollen, ohne die Höhe des gesamten Boards zu beeinflussen.
Für ein Kanban-Board mit typischerweise drei bis sechs Spalten reicht eine feste Breite von etwa 300 Pixeln pro Spalte aus, kombiniert mit gap-4 zwischen den Spalten für gleichmäßigen Abstand. Wichtig ist, dass der Spalten-Container selbst keine feste Höhe erhält, sondern sich an den verfügbaren Viewport-Platz anpasst, meist über h-[calc(100vh-Xpx)] abzüglich Header und Navigation.
<!-- Kanban board base structure: horizontal columns, vertical card scroll -->
<div class="flex gap-4 overflow-x-auto pb-4">
<div class="flex w-[300px] flex-shrink-0 flex-col rounded-2xl bg-slate-100 p-3">
<div class="mb-3 flex items-center justify-between px-1">
<h3 class="text-sm font-bold text-slate-700">Backlog</h3>
<span class="rounded-full bg-slate-200 px-2 py-0.5 text-xs font-semibold text-slate-600">8</span>
</div>
<div class="flex flex-col gap-2 overflow-y-auto" style="max-height: calc(100vh - 220px);">
<!-- Cards rendered here -->
</div>
</div>
<div class="flex w-[300px] flex-shrink-0 flex-col rounded-2xl bg-slate-100 p-3">
<!-- Next column -->
</div>
</div>
3. Karten-Design: Priorität, Labels, Avatare
Eine Karte im Kanban-Board muss auf kleinem Raum mehrere Informationsebenen gleichzeitig transportieren: Titel, Priorität, thematische Labels und zugewiesene Person. Eine bewährte Hierarchie beginnt mit einem farbigen Priorität-Indikator als schmalem Balken am linken Kartenrand, gefolgt vom Titel in fetter Schrift, darunter Labels als kleine, farbige Pills, und am unteren Kartenrand ein Avatar für die zugewiesene Person.
Diese Schichtung sorgt dafür, dass Nutzer beim schnellen Überfliegen des Kanban-Boards die wichtigste Information zuerst wahrnehmen, die Priorität, ohne den Titel lesen zu müssen. Karten sollten außerdem eine dezente Schattierung und einen sichtbaren Hover-Zustand erhalten, der signalisiert, dass die Karte interaktiv ist, etwa durch eine leichte Erhöhung des Schattens beim Überfahren mit der Maus.
<!-- Kanban card with priority indicator, labels and assignee avatar -->
<div
draggable="true"
class="group relative cursor-grab rounded-xl border border-slate-200 bg-white p-3 shadow-sm hover:shadow-md active:cursor-grabbing"
>
<div class="absolute inset-y-0 left-0 w-1 rounded-l-xl bg-red-500"></div>
<p class="mb-2 pl-2 text-sm font-semibold text-slate-800">Checkout-Bug in Safari fixen</p>
<div class="mb-3 flex flex-wrap gap-1.5 pl-2">
<span class="rounded-full bg-red-100 px-2 py-0.5 text-xs font-semibold text-red-700">Bug</span>
<span class="rounded-full bg-sky-100 px-2 py-0.5 text-xs font-semibold text-sky-700">Frontend</span>
</div>
<div class="flex items-center justify-between pl-2">
<span class="text-xs text-slate-400">#284</span>
<img class="h-6 w-6 rounded-full ring-2 ring-white" src="/media/avatars/jd.webp" alt="Zugewiesen: Julia Decker">
</div>
</div>
4. Horizontales Scrollen der Spalten
Sobald ein Kanban-Board mehr Spalten enthält, als in den sichtbaren Viewport passen, muss horizontales Scrollen zuverlässig funktionieren, ohne die vertikale Seiten-Scrollleiste zu beeinflussen. Der äußere Spalten-Container braucht dafür overflow-x-auto in Kombination mit flex, während der übergeordnete Seiten-Container selbst keine horizontale Überlaufbegrenzung setzen darf, da sonst zwei konkurrierende Scrollbereiche entstehen.
Ein häufiges Detail, das viele Kanban-Board-Implementierungen übersehen: Eine sichtbare, aber unaufdringliche Scrollbar-Gestaltung verbessert die Nutzererfahrung erheblich. Mit den Tailwind-Utilities für scrollbar-thin, ergänzt über ein offizielles Scrollbar-Plugin oder eigene ::-webkit-scrollbar-Regeln, lässt sich die Standard-Scrollbar des Browsers optisch an das restliche Design anpassen, statt sie einfach zu verstecken und Nutzern die Orientierung zu nehmen.
/* Subtle scrollbar styling for the horizontal board container */
.kanban-board::-webkit-scrollbar {
height: 8px;
}
.kanban-board::-webkit-scrollbar-track {
background: theme(colors.slate.100);
border-radius: 9999px;
}
.kanban-board::-webkit-scrollbar-thumb {
background: theme(colors.slate.300);
border-radius: 9999px;
}
.kanban-board::-webkit-scrollbar-thumb:hover {
background: theme(colors.slate.400);
}
/* Column body: vertical scroll, no visible scrollbar bleed into layout */
.kanban-column-body {
overflow-y: auto;
overscroll-behavior: contain;
}
5. Drag-and-drop visuelles Feedback
Die native HTML5-Drag-and-drop-API liefert die Events dragstart, dragover, drop und dragend, die sich direkt mit Alpine.js-Direktiven verdrahten lassen, ohne eine zusätzliche Bibliothek zu benötigen. Für ein überzeugendes Kanban-Board reicht die technische Funktionalität allein aber nicht aus, entscheidend ist das visuelle Feedback während des gesamten Vorgangs: Die gezogene Karte sollte transparenter werden, die Zielspalte sollte einen sichtbaren Rahmen oder Hintergrund erhalten, sobald eine Karte darüber schwebt.
Ein sauberes Muster im Kanban-Board ist, während dragover eine Platzhalter-Zeile an der voraussichtlichen Einfügeposition anzuzeigen, statt die Karte erst beim tatsächlichen Drop springen zu lassen. Das reduziert die kognitive Last für Nutzer erheblich, da die endgültige Position bereits während des Ziehens sichtbar wird, nicht erst danach.
// Alpine.js component wiring native HTML5 drag-and-drop events
function kanbanColumn() {
return {
isDragOver: false,
onDragStart(event, cardId) {
event.dataTransfer.setData('text/plain', cardId);
event.dataTransfer.effectAllowed = 'move';
// Slight delay so the browser can render the drag ghost first
setTimeout(() => event.target.classList.add('opacity-40'), 0);
},
onDragEnd(event) {
event.target.classList.remove('opacity-40');
},
onDragOver(event) {
event.preventDefault();
this.isDragOver = true;
},
onDragLeave() {
this.isDragOver = false;
},
onDrop(event, targetColumnId) {
event.preventDefault();
this.isDragOver = false;
const cardId = event.dataTransfer.getData('text/plain');
this.$dispatch('card-moved', { cardId, targetColumnId });
}
};
}
6. Spalten-Header mit Zähler und Farbe
Der Spalten-Header im Kanban-Board transportiert drei Informationen gleichzeitig: den Namen des Prozessschritts, die Anzahl der enthaltenen Karten, und optional eine Farbcodierung, die anzeigt, ob die Spalte einem Anfangs-, Mittel- oder Endzustand entspricht. Ein blasses Grau für Backlog, ein neutrales Blau für in Bearbeitung und ein sattes Grün für erledigt sind eine bewährte, sofort verständliche Konvention.
Der Zähler im Header eines Kanban-Boards sollte sich automatisch aktualisieren, sobald eine Karte per Drag-and-drop in die Spalte verschoben wird oder sie verlässt. Diese Reaktivität lässt sich in Alpine.js elegant über eine berechnete Eigenschaft lösen, die einfach die Länge des Karten-Arrays der jeweiligen Spalte zurückgibt, statt den Zähler manuell bei jeder Drop-Operation zu inkrementieren oder dekrementieren.
7. Responsive Verhalten: mobile Alternativen
Ein horizontal scrollendes Kanban-Board funktioniert auf Desktop-Bildschirmen gut, wird auf kleinen Mobilgeräten aber schnell unhandlich, besonders in Kombination mit Drag-and-drop, das auf Touch-Geräten ohnehin anders funktioniert als mit der Maus. Eine bewährte Lösung ist, unterhalb eines bestimmten Breakpoints auf eine einspaltige Ansicht mit einem Spalten-Umschalter umzuschalten, bei dem jeweils nur eine Spalte gleichzeitig sichtbar ist.
Für die Kartenverschiebung auf Touch-Geräten empfiehlt sich statt komplexem Drag-and-drop ein einfacheres Muster: Ein Tippen auf die Karte öffnet ein Kontextmenü mit den verfügbaren Zielspalten als Liste. Dieses Muster ist auf dem Touchscreen zuverlässiger als ein Drag-Gestus, der leicht mit dem vertikalen Scrollen der Seite kollidiert, und macht das Kanban-Board auch ohne Maus vollständig bedienbar.
8. WIP-Limits visuell darstellen
Ein WIP-Limit, kurz für Work in Progress, begrenzt die Anzahl der Karten, die gleichzeitig in einer Spalte eines Kanban-Boards erlaubt sind, um Engpässe im Prozess sichtbar zu machen. Visuell lässt sich diese Grenze am effektivsten direkt im Spalten-Header abbilden, etwa als Bruch wie 5 von 3, wobei die Zahl bei Überschreitung in Rot umspringt, statt in der neutralen Standardfarbe zu bleiben.
Zusätzlich zur Zahlenanzeige verstärkt ein farbiger Rahmen um die gesamte Spalte das Signal, sobald das WIP-Limit überschritten wird. Diese doppelte Kodierung über Zahl und Rahmenfarbe stellt sicher, dass die Überschreitung auch bei schnellem Überfliegen des Kanban-Boards ins Auge fällt, ohne dass Nutzer den genauen Zählerwert lesen müssen.
<!-- WIP limit indicator: red border and count when the limit is exceeded -->
<div
class="flex w-[300px] flex-shrink-0 flex-col rounded-2xl p-3"
:class="cards.length > wipLimit ? 'bg-red-50 ring-2 ring-red-300' : 'bg-slate-100'"
>
<div class="mb-3 flex items-center justify-between px-1">
<h3 class="text-sm font-bold text-slate-700">In Bearbeitung</h3>
<span
class="rounded-full px-2 py-0.5 text-xs font-semibold"
:class="cards.length > wipLimit ? 'bg-red-200 text-red-800' : 'bg-slate-200 text-slate-600'"
x-text="`${cards.length} / ${wipLimit}`"
></span>
</div>
</div>
9. Kanban-Board vs. Listen- und Tabellenansicht
Nicht jede Aufgabe profitiert von einem Kanban-Board als visueller Darstellung. Für manche Datenmengen und Nutzungsszenarien sind eine einfache Liste oder eine sortierbare Tabelle die bessere Wahl. Die folgende Tabelle vergleicht die drei Muster anhand konkreter Kriterien.
| Kriterium | Kanban-Board | Liste | Tabelle |
|---|---|---|---|
| Prozessvisualisierung | Sehr gut | Schwach | Mittelmäßig |
| Viele Datenfelder pro Eintrag | Begrenzt durch Kartengröße | Mittelmäßig | Sehr gut |
| Sortieren und Filtern | Aufwendig | Gut | Sehr gut |
| Statuswechsel per Drag-and-drop | Nativ passend | Unüblich | Unüblich |
Ein Kanban-Board eignet sich am besten für Prozesse mit klar definierten Zuständen und überschaubarer Feldanzahl pro Eintrag, etwa Aufgabenverwaltung oder Support-Tickets. Sobald Nutzer regelmäßig nach vielen unterschiedlichen Kriterien filtern oder sortieren müssen, wird eine Tabelle in der Regel effizienter, während eine einfache Liste für sehr lineare, unstrukturierte Aufgaben ausreicht.
Mironsoft
Tailwind CSS Komponenten und Design Systeme
Ein Kanban-Board, das sich wirklich flüssig anfühlt?
Wir bauen Kanban-Boards mit Tailwind CSS und Alpine.js, mit sauberem Drag-and-drop-Feedback, WIP-Limits und einer mobilen Alternative, die auch ohne Maus funktioniert.
Board-Konzept
Spalten, Karten-Layout und Farbsystem für euren Prozess definieren
Drag-and-drop
Native HTML5-API mit Alpine.js verdrahten, inklusive Platzhalter-Feedback
Mobile Anpassung
Touch-taugliche Alternative ohne Drag-Gestus umsetzen
10. Zusammenfassung
Ein durchdachtes Kanban-Board verwaltet zwei Layout-Achsen gleichzeitig, horizontales Scrollen zwischen Spalten und vertikales Scrollen innerhalb jeder Spalte, ohne dass sich beide Bewegungen gegenseitig stören. Karten-Design mit klarer Prioritäts-, Label- und Avatar-Hierarchie macht das Board auf einen Blick lesbar, während native HTML5-Drag-and-drop-Events kombiniert mit Alpine.js für flüssiges visuelles Feedback sorgen.
WIP-Limits mit doppelter Kodierung über Zahl und Rahmenfarbe machen Engpässe sofort sichtbar, und eine bewusste mobile Alternative ohne komplexen Drag-Gestus hält das Kanban-Board auch auf Touch-Geräten vollständig bedienbar. Wer diese Muster konsequent umsetzt, erhält ein Board, das nicht nur technisch funktioniert, sondern sich für Nutzer auch greifbar anfühlt.
Kanban-Board Styling-Muster — Das Wichtigste auf einen Blick
Layout
Feste Spaltenbreite, overflow-x-auto für den Container, overflow-y-auto je Spalte.
Karten
Prioritäts-Balken, Titel, Labels als Pills, Avatar unten rechts als feste Hierarchie.
Drag-and-drop
Native HTML5-Events plus Alpine.js für Transparenz und Zielspalten-Hervorhebung.
WIP-Limits & Mobile
Zahl plus Rahmenfarbe bei Überschreitung, einspaltige Ansicht mit Tipp-Menü auf Touch-Geräten.