A Kanban card represents one piece of work moving across a board, and it's easy to treat as a simple sticky-note that just needs a title. What information it actually carries has real consequences for how well the board serves its purpose.
The core information a card needs
A clear, specific description. Vague titles force anyone glancing at the board to already know the context, defeating the purpose of a shared visual system.
Size or complexity indication, helping assess at a glance whether current work-in-progress represents a reasonable load or a concerning pile-up.
Priority or urgency signal, especially in Kanban's continuous-flow model, where knowing which in-progress item is most urgent versus which can wait is essential.
Ownership, whether individual or deliberately unassigned in collaborative setups, either is legitimate, but it should be a deliberate choice, not an accidental gap.
Date information: when the item entered its current state, at minimum. This is what enables cycle-time tracking, one of Kanban's most valuable diagnostic tools.
What sophisticated cards sometimes add
Blocked status, visually distinct from normal in-progress work, so blocked items don't quietly blend in and get forgotten.
Item type or class of service, distinguishing standard work from urgent expedited items; different classes often warrant genuinely different handling.
Linked dependencies, easy to lose without an explicit link, and expensive to lose given how often dependency blindness causes late-discovered delays.
The trade-off to manage deliberately
A card can carry too much information as easily as too little. Cards crowded with every possible field become hard to scan quickly, defeating the point of a system meant to be understood in seconds. Teams that periodically ask whether every field is still earning its place tend to end up with more useful boards than teams that never revisit the format.