Back to compare picker

Kanban board vs Table vs Calendar view vs List view

Choose Kanban board when the main task is to visualize work in progress across workflow states and move cards as their status changes.

Decision dimensions

Dimension Kanban boardTableCalendar viewList view
UI or UX UI + UX - Workflow-state board for cards moving through columnsUI + UX - Semantic row-and-column data comparison surfaceUI + UX - Date and time grid for scheduled events, availability, and conflictsUI + UX - Vertical object-summary browsing surface
UI guidance Render workflow columns with visible names, status mapping, card counts, WIP limits, overloaded states, empty columns, and cards that show title, owner, priority, age, due date, blocked state, and enough metadata to understand the work.Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.Render a calendar view around a visible date range, mode switcher, today marker, weekday or time-axis labels, timezone, selected date, and event blocks with start, end, title, status, and all-day or timed placement.Render a labelled vertical list where each row has a strong primary label, concise supporting text, metadata, status, optional leading media, and row-scoped actions with clear hit targets.
UX guidance Use Kanban board when teams pull work through a shared workflow and need to see WIP pressure, bottlenecks, blocked items, stale cards, and status changes at a glance.Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.Use calendar view when users need to understand or manage scheduled items by their position in time: date, weekday, duration, overlap, availability, recurrence, or resource assignment.Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.
Good UI A product board shows Backlog, Ready, In progress, Review, and Done columns with card counts, WIP limits, blocked badges, owners, due dates, and visible over-limit styling in Review.A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.A clinic schedule shows June 2026 week view, today marker, timezone, business hours, all-day staff training, timed appointments, room labels, overlap warning, and a More link for crowded days.A ticket list row shows TCK-2048 Database backup failed, a one-line incident summary, Critical status, owner, updated time, selected state, and a labelled More actions menu.
Bad UI A board has columns named Important, Maybe, Later, and Random with no workflow meaning, no status mapping, and cards that never change state.A div layout looks like columns but has no caption, table semantics, or header associations.A decorative month grid contains colored dots with no event titles, no timezone, no overflow count, and no selected-day detail.A list row shows columns of owner, amount, due date, and status but no headers or column sort state.
Good UX A developer moves a card from In progress to Review, sees the status update, receives an over-limit warning, and can undo or help clear the bottleneck instead of pulling more work.A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.A dispatcher switches from month to week, opens Wednesday, sees three overlapping room bookings, chooses an available slot, and receives conflict-aware feedback before saving.A user filters tickets to Critical, selects two rows, opens the details panel for one ticket, then clears the filter and the selected count and active ticket remain understandable.
Bad UX A user drags a card to Done but the underlying status remains In progress, so reports and automations disagree with the board.Filtering the table removes selected rows without explaining why or offering a clear-filter path.A user taps +3 more in a crowded date cell but the calendar navigates away instead of showing the hidden events for that day.A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.
Best fit Work progresses through visible stages and the team uses the board to decide what to pull next.Records share comparable attributes that users need to scan in aligned columns.Users need to scan or manage scheduled events across dates, days, weeks, months, or resources.Users need to scan and act on a collection of objects using compact summaries.
Avoid when Columns are arbitrary categories with no workflow meaning.The content is layout, not data.Users only need to select one date for a form field.Users need to compare many records across shared attributes.
Required state Default board state with columns, card counts, WIP limits, visible filters, selected board, and at least one card per active workflow stage.Default table state with caption, visible headers, row values, and result count or context.Default calendar state with visible range, view mode, timezone, today marker, selected date, and event count.Default list state with label or heading, row count or context, visible row summaries, and primary row identity.
Accessibility burden Expose board name, active filters, sorting, grouping, column count, column names, card counts, and WIP limits as text.Use native table semantics for tabular data rather than div-only rows.Expose date navigation, mode switch, visible range, selected date, today, timezone, and event count as text.Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.
Common misuse Using Kanban columns as decorative categories rather than workflow states.Using table markup to create page columns or layout spacing.Using calendar view as a decorative month card for unscheduled content.Using list view as a table without column headers or column-state feedback.

Kanban board

UI or UX
UI + UX - Workflow-state board for cards moving through columns
UI guidance
Render workflow columns with visible names, status mapping, card counts, WIP limits, overloaded states, empty columns, and cards that show title, owner, priority, age, due date, blocked state, and enough metadata to understand the work.
UX guidance
Use Kanban board when teams pull work through a shared workflow and need to see WIP pressure, bottlenecks, blocked items, stale cards, and status changes at a glance.
Good UI
A product board shows Backlog, Ready, In progress, Review, and Done columns with card counts, WIP limits, blocked badges, owners, due dates, and visible over-limit styling in Review.
Bad UI
A board has columns named Important, Maybe, Later, and Random with no workflow meaning, no status mapping, and cards that never change state.
Good UX
A developer moves a card from In progress to Review, sees the status update, receives an over-limit warning, and can undo or help clear the bottleneck instead of pulling more work.
Bad UX
A user drags a card to Done but the underlying status remains In progress, so reports and automations disagree with the board.
Best fit
Work progresses through visible stages and the team uses the board to decide what to pull next.
Avoid when
Columns are arbitrary categories with no workflow meaning.
Required state
Default board state with columns, card counts, WIP limits, visible filters, selected board, and at least one card per active workflow stage.
Accessibility burden
Expose board name, active filters, sorting, grouping, column count, column names, card counts, and WIP limits as text.
Common misuse
Using Kanban columns as decorative categories rather than workflow states.

Table

UI or UX
UI + UX - Semantic row-and-column data comparison surface
UI guidance
Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance
Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI
A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI
A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX
A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX
Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit
Records share comparable attributes that users need to scan in aligned columns.
Avoid when
The content is layout, not data.
Required state
Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden
Use native table semantics for tabular data rather than div-only rows.
Common misuse
Using table markup to create page columns or layout spacing.

Calendar view

UI or UX
UI + UX - Date and time grid for scheduled events, availability, and conflicts
UI guidance
Render a calendar view around a visible date range, mode switcher, today marker, weekday or time-axis labels, timezone, selected date, and event blocks with start, end, title, status, and all-day or timed placement.
UX guidance
Use calendar view when users need to understand or manage scheduled items by their position in time: date, weekday, duration, overlap, availability, recurrence, or resource assignment.
Good UI
A clinic schedule shows June 2026 week view, today marker, timezone, business hours, all-day staff training, timed appointments, room labels, overlap warning, and a More link for crowded days.
Bad UI
A decorative month grid contains colored dots with no event titles, no timezone, no overflow count, and no selected-day detail.
Good UX
A dispatcher switches from month to week, opens Wednesday, sees three overlapping room bookings, chooses an available slot, and receives conflict-aware feedback before saving.
Bad UX
A user taps +3 more in a crowded date cell but the calendar navigates away instead of showing the hidden events for that day.
Best fit
Users need to scan or manage scheduled events across dates, days, weeks, months, or resources.
Avoid when
Users only need to select one date for a form field.
Required state
Default calendar state with visible range, view mode, timezone, today marker, selected date, and event count.
Accessibility burden
Expose date navigation, mode switch, visible range, selected date, today, timezone, and event count as text.
Common misuse
Using calendar view as a decorative month card for unscheduled content.

List view

UI or UX
UI + UX - Vertical object-summary browsing surface
UI guidance
Render a labelled vertical list where each row has a strong primary label, concise supporting text, metadata, status, optional leading media, and row-scoped actions with clear hit targets.
UX guidance
Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.
Good UI
A ticket list row shows TCK-2048 Database backup failed, a one-line incident summary, Critical status, owner, updated time, selected state, and a labelled More actions menu.
Bad UI
A list row shows columns of owner, amount, due date, and status but no headers or column sort state.
Good UX
A user filters tickets to Critical, selects two rows, opens the details panel for one ticket, then clears the filter and the selected count and active ticket remain understandable.
Bad UX
A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.
Best fit
Users need to scan and act on a collection of objects using compact summaries.
Avoid when
Users need to compare many records across shared attributes.
Required state
Default list state with label or heading, row count or context, visible row summaries, and primary row identity.
Accessibility burden
Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.
Common misuse
Using list view as a table without column headers or column-state feedback.
Decision rules
  • Choose Kanban board when the main task is to visualize work in progress across workflow states and move cards as their status changes.
  • Choose table when users need column comparison, sorting, row-level scanning, export, or dense structured data more than workflow movement.
  • Choose calendar view when the primary organizing axis is date, duration, availability, overlap, or schedule placement rather than workflow status.
  • Choose list view when users need a compact vertical queue of objects and do not need multiple workflow columns visible at once.
  • A Kanban board should expose column names, status mapping, card counts, WIP limits, overloaded columns, blocked cards, assignees, priority, due dates, and card details before users rely on it for flow decisions.
  • Dragging a card between columns should update the card's status field, show the destination state, and offer an accessible non-drag alternative.
  • Use swimlanes or grouping when teams need to separate work by owner, priority, workstream, service class, or slice, but avoid hiding WIP pressure in collapsed groups.
  • Use explicit blocked, stale, aging, dependency, or ready-to-pull indicators when work is not flowing even though a column has space.
  • Do not use Kanban board for arbitrary categories, mood boards, or dashboards where column movement has no workflow meaning.
  • When sorting is active, manual card ordering can become unavailable or misleading; disclose the ordering rule and keep move-to-column behavior clear.
Inspect live examples
Failure modes
  • Columns are decorative categories and moving a card does not change workflow status.
  • A WIP limit is exceeded but the board does not highlight the overloaded column or explain what action is needed.
  • Cards can only be moved by pointer drag, leaving keyboard and assistive-technology users without a status-change path.
  • Filters hide cards while column counts still imply the full board is visible.
  • Blocked or stale cards look the same as active work, so bottlenecks stay hidden.
  • Done, blocked, or canceled statuses are mapped to the wrong column and completion reporting becomes misleading.