Platform UI

Components

Platform component guidance for buttons, forms, cards, tables, navigation, and status badges.

StatusDraft
Last updated2026-06-13
PurposeGuide use of core product components including buttons, forms, cards, tables, navigation, and status badges.
UseWhen designing or reviewing product components.
When deciding whether a screen needs a button, form, table, card, navigation pattern, or status badge.

Summary

Opries components should support repeated operational work with clear actions, stable structures, accessible labels, and visible status. Components should help users decide what to do next.

Buttons

VariantUseCopy pattern
PrimaryMain page action"Add document", "Submit report"
SecondarySupporting action"Preview", "Export CSV"
DestructiveIrreversible or serious action"Delete record", "Reject approval"
GhostToolbar and row actionsIcon plus accessible label

Forms

Forms should show required fields, owner, due date, evidence requirements, and save state. Use inline validation for field-level issues and a summary alert for submission blockers.

For complex forms, group fields by task rather than database structure. Use helper text, examples, and review summaries where users need to learn what evidence or wording is expected.

Cards

Use cards for repeated records, summary tiles, and contained tools. Do not place dashboard page sections inside decorative cards when a table, toolbar, or full-width section is clearer.

Tables

Tables are a primary product surface. Include stable columns, clear status labels, visible owners, due dates, last updated dates, and row-level actions. Filters should be persistent and shareable when possible.

Navigation

Primary sections should map to real work areas: Dashboard, Projects, Documents, Obligations, Members, Reports, Settings. Avoid clever labels inside the product.

Status Badges

StateColourMeaning
CurrentSuccessApproved and up to date
DraftNeutralNot submitted or not final
Review dueWarningAction needed soon
OverdueDangerRequired action has passed
ArchivedMutedRetained for record history

Status badges must include visible text and should not rely on colour alone. Where space allows, pair the badge with owner, due date, or next-action text.

Checks

  • Does the component support a real user task?
  • Is the label concrete and action-oriented?
  • Does the component work without relying on colour alone?
  • Is the structure stable enough for repeated operational use?