ShiftIt — Brand Book

Version 1.0 — 2026-06-16. The single source of truth for ShiftIt’s verbal and visual identity. Authored during the autonomous run; design decisions and how to revert them are logged in the repo’s notes/autonomous-decision-log.adoc (D7—​D12).

ShiftIt is a workforce- and shift-scheduling SaaS built for the German / DACH market, with its reference use case in event-medical services (Eventsanitäter / event EMS). It serves three audiences from one product: planners/dispatchers (admin), field staff (employees), and event organisers (customers).

This document defines who we are, how we sound, and how we look — and it maps every visual decision onto the design tokens that actually drive the UI (frontend/style/tailwind.css), so the brand and the code never drift apart.

1. Brand strategy

1.1 Positioning

ShiftIt gets the right person to the right place at the right time — calmly, even when the plan changes at 2 a.m.

We sit in a market full of competent but visually interchangeable corporate-blue scheduling tools (Shyftplan, Papershift, Shiftbase, gastromatic). Our reference domain — event medical cover — raises the stakes: a missed shift isn’t a staffing inconvenience, it’s a gap in safety cover. That gives ShiftIt a sharper personality than generic workforce SaaS: operational calm under real-world pressure.

1.2 Brand personality

Trait What it means for us What we are not

Dependable

Predictable, transparent, no surprises. State is always visible.

Not flashy or "delightful" for its own sake.

Calm

A composed, low-noise interface that reduces operator stress.

Not sterile or cold.

Precise

Times, wages, and counts are exact and legible (tabular figures).

Not pedantic or jargon-heavy.

Field-ready

Works on a phone in a car park at night; high contrast, big targets.

Not desktop-only or fragile.

German-grounded

DSGVO-first, "Made in Germany" data residency, bilingual (DE/EN).

Not a US tool with a German translation bolted on.

1.3 Brand pillars (what every feature should reinforce)

  1. Clarity over cleverness — the schedule is legible at a glance.

  2. Trust by default — privacy, data residency, and auditability are features, not fine print.

  3. Calm under change — re-planning, swaps, and call-offs feel handled, not chaotic.

2. Voice & tone

ShiftIt speaks like a competent dispatcher: clear, brief, human, never panicked. We are bilingual — German is the primary market voice, English the secondary — and copy is written, not machine-translated.

2.1 Principles

  • Plain and direct. "Shift published. 4 staff notified." not "Your shift publication request has been successfully processed."

  • Active and present. "Claim this slot," "Assign Mara," "Record payout."

  • Quantified. Prefer concrete numbers: "2 of 5 slots filled," "€18.50/h," "Closes in 3 h."

  • Calm in failure. Errors state what happened, why, and the next step — no blame, no exclamation marks. "Couldn’t save — the role still has 3 qualified staff. Remove them first, or keep the role."

  • Respectful of the field. Short labels, no walls of text; assume the reader is busy and possibly on a phone.

2.2 German register

  • Use the formal Sie for customer-facing and admin surfaces; field-staff surfaces may use the warmer du per tenant preference (configurable later — default Sie).

  • Use correct domain terms: Schicht, Dienst, Qualifikation, Einsatzort, Sanitäter:in. Avoid anglicisms where a clean German term exists.

2.3 Microcopy do / don’t

Don’t Do

"Oops! Something went wrong 😬"

"Couldn’t load shifts. Retry."

"Are you sure you want to do this?"

"Delete this role? 3 staff are qualified for it — they’ll lose the qualification."

"Submission received successfully!!!"

"Request received. We’ll confirm by email."

3. Logo & wordmark

3.1 The mark

The ShiftIt mark is a rounded "shift tile" with a forward double-chevron — a slot on the schedule, moving forward. The tile is hi-vis amber (safety gear), the chevron signal teal (calm/operational). The pairing reads instantly as "operations + safety."

Implemented as an inline, dependency-free SVG component at frontend/src/ui/logo.rs so it scales crisply from a 20 px sidebar mark to a favicon without raster assets. Brand colours are hard-coded into the mark (a logo must be colour-stable across light/dark themes); the surrounding wordmark inherits currentColor.

┌──────────┐
│  ▸▸      │   amber tile · teal chevrons
└──────────┘  ShiftIt   ← wordmark: Inter, semibold, tight tracking

3.2 Wordmark

  • Typeface: Inter, weight 600 (semibold), letter-spacing: -0.02em (tracking-tight).

  • Casing: ShiftIt — one word, internal capital I. Never "Shiftit", "SHIFTIT", or "Shift It".

  • Clear space: keep at least the height of the mark’s corner radius clear on all sides.

3.3 Don’ts

  • Don’t recolour the mark outside the brand teal/amber pair.

  • Don’t add drop shadows, gradients, or outlines to the wordmark.

  • Don’t stretch, rotate, or skew the mark.

  • Don’t place the mark on a low-contrast background; on busy imagery, put it on the deep-teal surface.

4. Colour

OKLch throughout (perceptually uniform → predictable contrast). The palette is teal-led (the healthcare/operations sweet spot — ~62 % of healthcare UIs use teal/blue for "clean, stable, professional"), with hi-vis amber as the energetic accent and red reserved exclusively for destructive/emergency semantics. Neutrals carry a faint cool tint so the product reads as designed, never default-gray.

4.1 Core brand colours

Token Role Light (OKLch) ~Hex

Signal Teal --primary

Primary actions, links, active nav, focus ring

0.52 0.10 207

#0c7c8b

Teal Deep --sidenav

Navigation surface, brand backdrop

0.27 0.04 215

#163b43

Hi-Vis Amber (mark / accent)

Logo tile, energetic highlights, --warning family

0.74 0.15 75

#e8920c

Ink --foreground

Body text

0.21 0.015 220

#1b242a

Cloud --background

App background

0.99 0.004 207

#fbfdfd

4.2 Semantic tokens (drive the UI)

All UI colour flows through these — components reference semantic names (bg-primary, text-muted-foreground, bg-success), never raw colours. Full values live in frontend/style/tailwind.css :root (light) and .dark (dark).

Group Tokens Meaning

Surface

background · card · popover · surface · muted

Page, raised, and recessed surfaces

Text

foreground · muted-foreground · *-foreground

On-surface text, paired for contrast

Brand action

primary · primary-foreground · primary-light/dark · ring

Buttons, links, focus

Secondary

secondary · accent

Chips, hover/selected backgrounds

Navigation

sidenav + sidenav-foreground/primary/accent/border/ring

The deep-teal nav column

Status — success

success(+-foreground/-light/-dark)

Confirmed, filled, paid (green ~150°)

Status — warning

warning(+…)

Attention, deadlines, partial (amber ~75°)

Status — info

info(+…)

Neutral notices (blue ~235°)

Status — destructive

destructive(+…)

Delete, error, emergency (red ~27°) — reserved

4.3 Status colour discipline

  • Red is never decorative. It means destroy/error/urgent only. This keeps it meaningful in an emergency-adjacent product.

  • Amber = "needs attention, not yet wrong" — closing deadlines, partial fills. Amber uses dark on-colour text (--warning-foreground is ink), because hi-vis amber + white fails contrast.

  • Green = settled — filled slots, recorded payouts, confirmations.

  • Teal ≠ status. Teal is the brand/action colour; don’t use it to signal state, or it collides with info.

4.4 Accessibility

  • Body text and on-primary/on-status text meet WCAG AA (≥4.5:1); large text and UI affordances meet ≥3:1. Verify any new pairing.

  • The deep-teal sidebar uses near-white foreground (AA) and a brighter teal (sidenav-primary) for active/focus emphasis.

  • The focus ring is brand teal and always visible — never remove focus outlines.

  • Never encode meaning in colour alone: pair status colour with an icon and/or text label.

5. Typography

Role Family Notes

UI / sans

Inter → system-ui, -apple-system, 'Segoe UI', Roboto, …

Neutral, dense, excellent umlaut/diacritic support.

Numeric / mono

JetBrains Mono → ui-monospace, SFMono-Regular, Menlo, Consolas

Times, wages, IDs — use font-mono + tabular-nums so figures align in tables.

DSGVO note — do NOT load fonts from the Google Fonts CDN. Embedding fonts from Google’s servers transmits visitor IPs to Google and has been ruled a GDPR violation in German courts. Inter and JetBrains Mono must be self-hosted (bundled via Trunk) or left to the system stack. The current build relies on the system fallback; self-hosting Inter is a tracked follow-up (see decision log D11).

Scale & rhythm (Tailwind defaults, applied consistently):

  • Page title text-2xl font-semibold tracking-tight; section text-lg font-semibold; body text-sm; meta/labels text-xs text-muted-foreground.

  • Headings use tracking-tight (−0.02em); body is default tracking.

  • Use tabular figures for any aligned numeric column (schedules, wage tables, counters).

6. Layout, shape & motion

  • Radius: base --radius: 0.625rem (10px); sm/md/lg/xl derived. Rounded but not pill-soft — competent, not toy-like.

  • Density: comfortable but information-dense. The schedule is the hero; chrome stays quiet. Generous tap targets (≥40px) for field use.

  • Elevation: flat surfaces + hairline borders (--border) over heavy shadows. Popovers/sheets get a soft shadow only to establish layering.

  • Motion: functional and fast (150—​200ms). Transitions clarify state changes (drawer slide, toast); we don’t animate for spectacle.

  • The deep-teal nav is the brand’s persistent signature — a calm dark rail framing bright, legible content.

7. Iconography & imagery

  • Icons: single-stroke, 2px, rounded caps/joins, 24px grid (the existing inline-SVG style in sidebar.rs). Match stroke weight to Inter’s weight.

  • Status icons always accompany status colour (✔ filled, ! attention, ✕ error/destroy, ℹ info).

  • Imagery: if/when used, prefer authentic operational photography (real crews, real venues) over stock "smiling office" clichés; keep a cool, calm grade consistent with the teal palette.

8. Implementation map

Brand element Lives in

Colour tokens (light + dark)

frontend/style/tailwind.css — :root, .dark, @theme inline

Font stack + mono token

frontend/style/tailwind.css — --font-sans, --font-mono

Logo / wordmark

frontend/src/ui/logo.rs (<Logo/>), used in frontend/src/ui/sidebar.rs

Theme colour / metadata

frontend/index.html

Semantic usage in components

frontend/src/ui/* + feature surfaces — always semantic tokens

Rule of thumb for contributors: never hard-code a colour in a component. If you need a colour the tokens don’t express, add a semantic token here and in tailwind.css first, then use it. The brand stays consistent because the tokens are the only dial.