Kanban-Board Styling-Muster mit Tailwind CSS
AI generated
</>
tw
Tailwind CSS · UI-Komponenten · Utility-First · Design Patterns
Kanban-Board Styling-Muster mit Tailwind CSS
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.

17 Min. Lesezeit Kanban-Board · Drag-and-drop · WIP-Limits · Responsive Tailwind CSS v4 · Alpine.js

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 });
    }
  };
}

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.

11. FAQ: Kanban-Board Styling

1Ideale Spaltenbreite?
Etwa 300 Pixel als feste Breite verhindert optisches Zusammenschrumpfen.
2Horizontales vs. vertikales Scrollen?
Container overflow-x-auto, jede Spalte overflow-y-auto mit fester Höhe.
3Library für Drag-and-drop nötig?
Nein, native HTML5-Events reichen mit Alpine.js-Direktiven aus.
4Drop-Position anzeigen?
Platzhalter-Zeile während dragover an voraussichtlicher Position.
5WIP-Limit visuell darstellen?
Bruch im Header plus farbiger Rahmen bei Überschreitung.
6Drag-and-drop auf Touch?
Eingeschränkt, Tipp-Menü mit Zielspalten als zuverlässigere Alternative.
7Informationen auf einer Karte?
Titel, Prioritäts-Indikator, Labels als Pills, Avatar der zugewiesenen Person.
8Tabelle statt Kanban?
Bei häufigem Filtern, Sortieren oder vielen Datenfeldern pro Eintrag.
9Scrollbar stylen ohne verstecken?
Eigene ::-webkit-scrollbar-Regeln oder Tailwind-Scrollbar-Plugin.
10Farbcodierung im Header?
Ja, nach Prozessphase, hilft beim schnellen Erfassen des Status.