Tag / status tag

Problem Context

• Objects have a small number of categories, states, phases, freshness markers, priorities, counts, or progress labels users need while scanning.
• The label can be expressed in one to three words or a short date without becoming the object's title or full explanation.
• Users need to compare many objects quickly, such as rows in a table, cards in a queue, files in a list, dashboard widgets, or task-list entries.
• Some labels are neutral categories while others are semantic statuses with success, information, warning, or error meaning.
• The system can keep status text, color, sorting, filtering, and detailed object state consistent as records change.

Selection Rules

• Choose tag when the label is compact, read-only, attached to a visible object, and useful for scanning or comparison.
• Use status tag when the label reports the object's current state, condition, progress, urgency, or outcome.
• Use neutral category tags when the label groups objects by type, topic, source, ownership, or freshness without status meaning.
• Use filter chips when the tag represents an active query condition that users can remove or clear.
• Use chip selection when tags are selectable values in an input or preference flow.
• Use inline message when users need explanatory copy, a local action, a warning reason, or recovery guidance near the object.
• Use alert or notification banner when a page-level or task-level condition needs broader context than a compact object label.
• Use a table column, metadata line, or details panel when many tags would crowd every object.
• Do not use tags as links, buttons, toggles, menu triggers, or replacement headings.
• Do not use color-only status; the text and context must still communicate the state.

Required States

• Neutral category tag attached to a row, card, heading, or object summary.
• Status tag with success, information, warning, and error meanings expressed by text plus visual treatment.
• No-tag state where the absence of a tag has a clear implied meaning or is replaced by plain metadata.
• Multiple-tag state with a controlled maximum and wrapping behavior that does not hide title, owner, or actions.
• Dynamic status-update state where the visible tag text changes with the object and non-urgent updates are announced appropriately.
• Overflow or long-label state where copy is shortened, moved to metadata, or explained elsewhere rather than wrapping into a tall badge.
• Misuse state where clickable, removable, filter, or message behavior is routed to another pattern.

Interaction Contract

• A read-only tag does not receive focus, show hover affordance, expose pressed or selected state, or claim click behavior.
• The tag's accessible text matches the visible label and includes status context when color or iconography adds semantic meaning.
• The surrounding object makes clear what the tag applies to, such as the current row, card, heading, task, file, claim, or notification.
• Tag updates are driven by canonical object state, not by local decoration copied from stale text.
• If users can remove, select, filter by, or open details from the label, implement the appropriate chip, button, menu, link, or disclosure pattern instead.
• Semantic tag colors use the same meaning across product areas and do not conflict with alerts, warnings, or destructive actions.
• Tags remain secondary to the object title and primary action so scanning helps decision-making without stealing task focus.

Implementation Checklist

• Define the object property, status lifecycle, allowed values, owner system, and update timing before adding a tag.
• Limit labels to one to three words where possible and standardize vocabulary for equivalent states.
• Choose neutral category styling or semantic status styling from meaning, not decorative variety.
• Place tags consistently near the object identity or in a dedicated status column, not randomly across cards or rows.
• Set a maximum visible tag count and an overflow rule before rendering user-generated or imported metadata.
• Check contrast, zoom, text resizing, long translated labels, sentence case, screen-reader text, and mobile wrapping.
• Verify that tag values match filter facets, detail pages, notifications, sorting, exports, and backend state.
• Usability-test layouts where tags appear near buttons so users do not confuse labels with controls.

Common Generated-UI Mistakes

• Making a static tag look clickable or focusable.
• Using tag as the primary title of an object.
• Using vague labels such as New, Hot, or Priority without explaining what they mean in the object's context.
• Mixing neutral category tags and semantic status tags with the same colors.
• Showing many metadata tags when a table column, details panel, or filter would be easier to scan.
• Letting cached status tags drift from the object's current workflow state.
• Using a tag where users need an inline message, alert, validation error, or recovery action.

Critique Questions

• What exact object property does this tag expose, and who owns its truth?
• Is the tag neutral metadata or semantic status, and are color meanings consistent?
• Can users understand the tag without clicking it or relying on color alone?
• Would a filter chip, selectable chip, table column, inline message, alert, or heading be more accurate?
• How many tags can appear before the object becomes harder to scan?
• What happens when the status changes, becomes stale, or differs from the detail page?