Card Layouts and Visual Styles
Card layouts control what people see on a project board before opening a ticket. Visual styles control how each field is presented. Together, they make a board fit its operating purpose.
Use compact cards for high-volume triage. Use richer cards for delivery reviews where the team needs context without opening every ticket.
Card Fields
Board cards can show built-in ticket fields and project custom fields.
Common built-in fields include:
- Issue key.
- Issue type.
- Project.
- Title.
- Status.
- Epic.
- Assignee.
- Priority.
- Progress.
- Due date.
- Labels.
- Estimate.
- Updated date.
Custom fields appear with the cf. prefix in configuration but show their readable field name on the card.
Layout Grid
Card layouts use a grid. A block chooses a field and where it appears on the card. You can change position, width, and height to emphasize the information that matters most.
Use the largest area for the field people read first, usually title or customer context. Keep metadata such as key, type, priority, and due date compact.
Good layout practices:
- Put the title near the top.
- Keep owner, due date, priority, and status easy to scan.
- Group related custom fields together.
- Avoid showing fields that are usually empty.
- Use different layouts for different boards when the review question changes.
Visual Styles
Visual styles make field values easier to scan. Available styles depend on field type.
| Field type | Common styles |
|---|---|
| Progress | Bar, number, or bar plus number. |
| Priority | Compact value or badge. |
| Status, type, select fields | Badge or text. |
| User fields | Pill or name. |
| Date and datetime | Short or muted. |
| Labels, multi-select, checkboxes | Chips or comma text. |
| Text and number | Plain, labeled, or muted. |
Choose styles for scanning, not decoration. A triage board may benefit from badges and chips. A leadership board may need muted supporting fields with progress emphasized.
Built-In and Custom Fields
Built-in fields are available on all projects. Custom fields are available only on the project that defines them.
If a board layout references an archived or missing custom field, review the layout before using the board for operational decisions. The board may no longer show the information reviewers expect.
Custom-field card blocks depend on the project's custom-field schema. Moving a ticket to another project clears custom-field values, and copying a board concept to another project requires matching fields.
Design Cards for the Board Purpose
Different boards should answer different questions:
| Board purpose | Useful card fields |
|---|---|
| Standup | Assignee, status, progress, blocker, due date. |
| Triage | Customer, severity, priority, labels, age. |
| QA review | Reviewer, status, due date, affected area, environment. |
| Roadmap execution | Epic, progress, owner, target date, risk indicator. |
| Leadership review | Owner, priority, due date, progress, customer tier. |
Do not make every card show every field. Dense cards slow review and make urgent details harder to see.
Maintain Layouts
Review card layouts when:
- A custom field is added, archived, or renamed.
- A board's purpose changes.
- Reviewers keep opening tickets for the same missing context.
- A workflow status or transition changes.
- A leadership or customer-facing review needs a simpler view.
Card layout is part of operating design. Keep it intentional, short, and aligned with how the board is used.