Product UX Principles

This page is where the brand, palette, type, and layout turn into behaviour. It covers how each BugPort surface should feel in use — dashboard, plugin, docs, and marketing — plus accessibility, content and tone, and the three state patterns (empty, error, loading) with concrete example copy.

The unifying principle: BugPort is a calm operations console. The interface stays out of the way so the evidence and the next action are obvious.

BY SURFACE

Dashboard UX

The dashboard is operational. It should feel like a steady console, not a marketing page.

White cards on cream. Content lives on white cards over the cream canvas; the contrast carries the hierarchy.
Aubergine for the active nav. Iris Mid #730394 marks the active nav item and the single primary action — nothing else.
Body-sm tables. Bug lists, logs, and dense rows use 14px body-sm so more fits without crowding.
Lavender for grouping only. Lavender Wash backs grouped filters and passive summaries — never primary content or primary actions.
Mono for logs and network. Console output, network rows, and response bodies render in IBM Plex Mono so exact technical data is unmistakable.
Evidence-first bug detail. The bug detail view foregrounds the evidence — screenshot, annotations, console, network, page context — with status and severity close at hand. The reader should reach the evidence before any chrome.

Plugin UX

The browser extension plugin is compact and task-first.

Compact panel. A narrow 320–420px single column; every element earns its space.
Capture preview above submit. The reporter sees the captured screenshot and annotations before the submit action, so they confirm what they are sending.
Quota-aware warnings — storage, not seats. When a workspace nears its storage limit, the plugin surfaces a calm warning framed around storage (e.g. "Workspace storage is almost full"). Never seats, never per-user.
Advanced settings collapsed. Network detail level and session replay stay collapsed by default so the common path stays simple.

Docs UX

These docs are a reference surface — and a live example of the system.

Clear hierarchy and scannable structure. Strong H1 lead, logical H2 sections, short paragraphs, and lists over walls of text.
Diagrams where flow matters. Mermaid diagrams for flows and architecture instead of long prose.
Framed screenshots. Product screenshots on white 16px-radius cards with an iris-edge keyline — exactly as defined in Visual Identity.
This very site is the reference. Cream-leaning light default, plum-deep navbar, lavender component surfaces, the aubergine Iris ramp on links and primary controls.

Marketing UX

Marketing is the one place BugPort raises its voice — editorially, never with hype.

Editorial layout. Generous spacing, display type used once per section, one idea per band.
Product-led screenshots. Real framed product imagery — never stock photography or mock devices.
Dark storytelling bands. One or two Plum Deep #481a54 inverse bands for narrative or milestone moments, with strong white text.
Storage-based pricing cards. Pricing presents the storage tiers (Free 1 GB, Starter 25 GB, Team 100 GB, Growth 500 GB, Scale 1 TB) with unlimited team members stated plainly on every plan. No seat math anywhere.

Accessibility

Contrast on cream and white. Body text uses Eggplant Ink, Midnight Plum, or Graphite; muted text bottoms out at Steel #696969. Don't use Iris Mid for small body on cream without contrast testing.
Visible focus states. Every interactive element shows a clear focus ring (Iris Edge / Violet Glow) in both themes — never remove focus outlines.
Strong inverse text. On plum inverse bands, text is strong white; muted inverse text uses Iris Edge, never mid-grey.
Don't rely on colour alone. Status uses a label or icon alongside its state colour, so meaning survives for colour-blind users.

Content and tone

Plain, product-operator language. Specific nouns, active verbs, no filler.
No assistant voice. BugPort copy never says "I", "let me", or "I'll help" — it is a tool, not a persona.
No seat framing. Limits and upgrades are about workspace storage, never seats or per-member cost.
One primary action per view. Don't crowd a screen with competing calls to action.

✓ Do

"No bugs yet — capture your first report from the browser plugin."
"Workspace storage is almost full. Add storage to keep capturing."
"Capture failed. Check your connection and try again."
"Open project", "Capture bug", "Create issue from bug".

✕ Don't

"Oops! I couldn't find any bugs — let me help you get started!"
"You've used all your seats. Upgrade to add more users."
"Supercharge your debugging with our magical capture engine."
Two aubergine buttons competing in the same panel.

State patterns

Empty, error, and loading states are designed, not default. Each follows a calm, predictable pattern.

Empty state

One title, one sentence, one action — optionally a quiet ghost frame. Example: title "No bugs yet", sentence "Capture your first report from the browser plugin or widget.", action "Install the plugin". Calm, encouraging, never an error tone.

Error state

Plain statement of what happened plus a recovery path. Use rose-red destructive colour only for genuinely dangerous or irreversible actions, not for ordinary validation. Example: "Capture failed. Check your connection and try again." Validation errors read as guidance, not alarms.

Loading state

Calm and layout-stable. Reserve space so content does not jump when it arrives; prefer quiet skeletons over spinners on data-dense views. No flashing, no jitter — stability reads as trust.

💡

A good test for any state: does it tell the operator exactly what happened and exactly what to do next, in one calm sentence? If yes, it is on-brand. If it scolds, hypes, or mentions seats, it is not.