--- title: Kanban Board slug: kanban-board kind: pattern summary: Work shown as columns of cards, one column per stage, moved by dragging — the shape of the whole process visible at once, at the cost of everything a table is good at. problem: >- A team needs to see where every piece of work is and shift things between stages. A table shows the records but not the distribution, so nobody notices that one stage is holding thirty items until it becomes an incident. family: [scan, workflow] data_shape: [collection] principles: [orientation, surface-dont-bury] interaction: [direct-manipulation, scanning] density: low complexity: medium status: stable visibility: public use_when: - Work moves through a small number of named stages — ideally three to six. - Where things are stuck is a question the team asks regularly. - Moving an item between stages is a normal, frequent action. - Everything in flight fits on one screen, roughly under a hundred items. avoid_when: - There are hundreds of items. A board becomes unreadable long before a table does. - People need to compare items on a number — a board has no columns to align. - There are more than about seven stages, where horizontal scrolling hides half the process. - Only one person works the queue. A queue is more efficient than a board. alternatives: - slug: dense-operational-table when: People compare and sort more than they move things between stages. - slug: review-queue when: One person works items one at a time and throughput matters more than overview. - slug: grouped-list when: You want the same grouping benefit without giving up alignment and sorting. ask_leo: | Build a kanban board for this workflow. - One column per stage, in process order, using the stage names the team says out loud. - Show a count on every column heading, and let a column show a limit when the team has agreed one. - Keep cards small — the identifier, the title, the owner, and at most one more fact. A board's value is the overview, and big cards destroy it. - Dragging a card to another column moves it and persists immediately. Show the drop target clearly while dragging. - Every drag must also be possible without a mouse: a move action on the card that picks the target stage from a list. - Show the age of a card in its current column, at least for the ones that have been there a long time. Stuck work is the main thing a board should reveal. - If a column can exceed about twenty cards, scroll it independently and keep the heading and count fixed. related: - title: Linear Workflow url: /patterns/linear-workflow summary: The topology underneath — get the stages right before drawing columns. - title: Dense Operational Table url: /patterns/dense-operational-table summary: What a board gives up — alignment, sorting and comparison. --- ## Anatomy ``` To do (4) In progress (7) Blocked (3) Done (12) ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ JOB-118 │ │ JOB-102 │ │ JOB-097 │ │ JOB-091 │ │ Framing │ │ Wiring │ │ Glazing │ │ Strip out│ │ Dana │ │ Sam · 9d │◀ aged │ Priya·14d│ │ Sam │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ … … … … ↑ the count is the point: 7 in progress, 3 blocked — visible without reading a card ``` - **Counts on headings.** The distribution is the information; the cards are detail. - **Small cards.** Four facts maximum. A board of large cards is a card list with extra scrolling. - **Age on cards that have aged.** Without it, a card parked for three weeks looks the same as one that arrived this morning. - **A keyboard path for every drag.** Drag-and-drop as the only mechanism excludes people and breaks on touch. ## Why it works It makes **distribution** preattentive. You do not read a board, you look at it: one tall column is a bottleneck, and you see it before you have read a single card. No table conveys that in under a second. It also makes moving work physical. Dragging a card is direct manipulation — the thing you are looking at is the thing you are changing — which is the [consistency](/patterns/consistency) principle at its most literal, and it is why boards feel good to use in a way status dropdowns do not. ## What you give up A board has **no columns**, in the table sense, so it has nothing to align. That means no sorting, no comparison across a metric, and no scanning a value down a list. Amounts, dates and durations all become text on cards, readable one at a time. That is a genuine trade, not a flaw — but it means a board is the wrong default for anything where the question is "which is largest / oldest / most expensive". Many teams adopt a board for its overview and then discover they have lost the list they actually worked from. Offering both views over the same data is usually the right answer. ## Getting it wrong - **Cards that grew.** Six fields and a description per card, so four cards fill the screen and the overview is gone. - **Too many columns.** Past about seven, the process scrolls sideways and can never be seen at once — which was the entire reason to build a board. - **A Done column that grows forever**, eventually dominating the board with finished work. Archive it, or cap it to a recent window. - **No age indicator**, so the board shows where things are but never that they are stuck. - **Drag-only.** Unusable by keyboard, awkward on touch, and impossible on a long column where the target is off-screen. ## Exemplars **Trello** defined the pattern and demonstrates its limit just as clearly: it is excellent at fifty cards and unusable at five hundred. **Linear** offers board and list over identical data and lets people switch, which is the mature answer — the board is a *view*, not the model. **Jira's board with explicit work-in-progress limits** shows the original manufacturing idea intact: the column count is not decoration, it is a constraint the team agreed to, and the board enforces it. The extractable rule: **a board is a view for seeing distribution, not a container for work.** The moment it becomes the only way to see the data, you have traded away sorting and comparison for a picture.