Design
The RoundTrip design system defines how the product looks, feels, and communicates — from color palette and typography through to component patterns and interaction conventions. This section is the primary reference for anyone building UI, creating marketing materials, or contributing to the visual identity of RoundTrip.
Design Philosophy
RoundTrip is built for dispatchers and technicians who work fast, under pressure, in real operational environments. The UI reflects that reality. The design language is inspired by command center and dispatch operations — think air traffic control, not consumer social apps.
This means:
- Information density over whitespace — dispatchers need to see a lot at once, not scroll through cards
- Clear hierarchy — urgent things look urgent, completed things recede
- Dark navy panels with bright blue action color — high contrast, easy to scan under any lighting
- Monospace ticket numbers and IDs — data that needs to be read precisely is always set in JetBrains Mono
- Semantic color discipline — amber means warning, green means success, red means danger — always, everywhere, without exception
The design is not decorative. Every visual decision has a functional reason. When in doubt, ask whether a design choice makes the dispatcher's job faster or clearer — if it doesn't, it shouldn't be there.
What's in This Section
| Page | Audience | What It Covers |
|---|---|---|
| Design System | Developers, Marketing | Color palette, typography, component patterns, CSS variables, icons |
| Brand | Developers, Marketing | Logo variants, brand colors, font usage rules, brand voice |
| Brand Guidelines ↗ | All | Full visual identity reference — logo usage, color, type, UI components |
| Brand Concept Exploration ↗ | All | The three original name and identity concepts explored before selecting RoundTrip |
Audiences
Developers
The design system is your primary reference when building UI. Before implementing any new component or page:
- Check the Design System for existing patterns — do not reinvent components that already exist (
MetaRow,SurfacePanel,SectionHeader,StatusBadge,PriorityBadge) - Use the CSS variables — never hardcode hex values in component files
- Use Tailwind utility classes where possible; fall back to CSS variables for brand-specific values
- Ticket numbers, IDs, and timestamps always use JetBrains Mono
- Status colors are semantic and fixed — do not reuse amber for non-warning contexts
Marketing
The brand section is your primary reference when creating any external-facing material:
- The wordmark is always Barlow Condensed 700, uppercase — never set in any other font
- Sky
#7EC8E3is a logo accent color only — it does not appear in the product UI outside the wordmark - The gradient (
135deg #0F2D44 → #1D6FA4 → #2A8EC4) is for hero sections and brand moments — not UI chrome - When in doubt, reference the Brand Guidelines
Technology
| Concern | Tool | Notes |
|---|---|---|
| Styling | Tailwind CSS v4 | Utility-first. CSS variables for brand tokens. |
| Icons | Phosphor Icons (@phosphor-icons/react) | Consistent icon set across the product |
| Fonts | Google Fonts | DM Sans, Inter, JetBrains Mono, Barlow Condensed |
| Component library | React components in src/components/ | Shared components — always check here before building new |
| Component explorer | Storybook (planned) | See Storybook Roadmap below |
Key Design Decisions
These decisions are intentional and should not be revisited without a strong reason. They are documented here so new developers and designers understand the "why" before proposing changes.
Navy sidebar + light content area
The dark navy sidebar (#0F2D44) gives the dispatch UI its command-center feel and provides high contrast for navigation items. The light content area (#F4F7FA) keeps data tables readable. This split is intentional — don't invert it.
Blue as the single primary action color
#1D6FA4 is the only primary action color. CTAs, links, active states, and interactive elements all use it. Using multiple colors for primary actions creates visual noise and confusion about what is clickable.
Priority as left-border accent on rows Priority indicators on ticket rows use a colored left border rather than just a badge — Urgent gets a red left border, High gets amber. This allows priority to be communicated at the row level without a badge consuming column space.
Semantic colors are fixed Amber = warning/high priority. Green = success/completed. Red = destructive/urgent. These associations are set across every component and must never be reused for other meanings. A user who has learned these associations cannot be surprised by a green destructive action.
Ticket numbers always in JetBrains Mono Ticket numbers, IDs, and timestamps are information that needs to be read precisely and compared character-by-character. Monospace makes this easier and gives these elements a distinct visual register that separates them from prose.
Storybook Roadmap
Storybook is planned as the component explorer for RoundTrip — a live, browsable reference of every component in the design system with its variants, props, and usage examples.
Why Storybook?
- Developers can see all existing components before building new ones — reducing duplication
- Designers (current or future) have a living reference that stays in sync with the codebase
- Marketing can reference accurate component examples when producing materials
- New developers can learn the design system interactively
Planned setup:
- Storybook hosted as a static site, likely at
storybook.roundtrips.appor as a section of the ops site - Protected by Cloudflare Access (same as this site) — internal only
- Stories written alongside components — one story file per component
- Integrated into the ADO pipeline to auto-deploy on merge to
main
Current state: Not yet implemented. This is a planned milestone for when the component library reaches sufficient maturity to justify the investment. In the meantime, the Design System page serves as the manual reference.
Contributing to the Design System
When you build a new component that other parts of the app could reuse:
- Place it in
src/components/with a clear, descriptive name - Use CSS variables and Tailwind — no hardcoded colors
- Document its props and usage with a JSDoc comment
- Add it to the Design System page
- When Storybook is in place, write a story for it
When you discover a component being rebuilt somewhere it already exists — raise it in the team channel and consolidate to the shared version.