Hendrik Cammann · UX Engineer & Design Systems

I design the experience .
I design the system that ships it .

Nine years of UX architecture and design-systems practice. I define the structure that gives product teams direction, and the infrastructure that keeps them consistent at scale.

Showcase Download Resume
Based
Ulm, Germany
Practice
UX Engineer · DS Lead
UX experience
9+ years · Senior
DS lead
6+ years · Senior

§ 01 - Position

Where UX decisions and systems thinking compound.

At Elektrobit I defined the UX architecture for infotainment products and unified the design system across product lines. At TEAM23 I shaped product experiences for five enterprise clients and built the shared infrastructure behind them.

— Operator, not vendor.

§ 02 - How I navigate

Five moves the work has taught me.

  1. Stakeholder Clarity.

    — Translating complexity into clarity for every audience

  2. Project Ownership.

    — End-to-end accountability, from kickoff to delivery

  3. Problem Framing.

    — Finding the right question before jumping to answers

  4. Resilience.

    — Staying effective when scope, constraints or strategy shifts

  5. Systems Thinking.

    — Designing for the whole, not just the current screen

§ - Earned from stakeholder briefs

A working principle.

A stakeholder once asked me to 'just make the navigation simpler.' The problem wasn't the nav - three unrelated features had been forced into one flow. We untangled the structure, and the navigation fixed itself. Most problems are just symptoms. You won't find the root issue unless you start digging.

— Most problems are symptoms.

§ 03 - Craft

UX process.

I map functional clusters and information architecture before anyone opens Figma - because structure problems don't fix themselves downstream.

Design starts in the solution space, not the pixel.

Understand.

— Solution space & functional clusters

  • I look for the overlap before I look for the answer - when users and business align cleanly, you're not looking hard enough
  • I cluster by decision moment, not by feature list - what the brief calls one feature usually contains three different decisions users actually care about
  • I scope before I draw - every Figma file started before scoping is a Figma file that gets rebuilt

Structure.

— UX architecture & navigation

  • Most navigation problems aren't navigation problems - three unrelated features forced into one flow can't be fixed with a better menu
  • Crosslinks live where the same data answers different questions; I find them by listening for “wait — that's also where I…”
  • The architecture has to outlive the brief - if the IA collapses when one product team changes priority, it wasn't structure, it was scaffolding

Deliver.

— Wireframes, testing & iteration

  • Wireframes commit. They're concrete enough for engineering to estimate and concrete enough to be wrong about - both matter
  • I design what gets tested and decide what the results mean for the architecture; researchers run the sessions
  • When testing surfaces a problem, the fix lives at the level the problem lives - modal failures go back to wireframes, structural failures go back to flows
See the full UX process

Side A · UX

People, patterns, care.

I design the UX architecture that turns ambiguity into direction, so teams ship the right thing. Scale without structure becomes noise.

— humanity

Side B · Systems

Tokens, governance, scale.

I build the infrastructure that lets product teams stay consistent without slowing down. Structure without scale stays fragile.

— systematisation

§ 04 - Craft

Design systems.

I build the infrastructure that lets teams move fast without breaking consistency - tokens, components, governance, and the tooling that ties them together.

A design system is infrastructure, not a side project.

Foundation.

— Token architecture & design DNA

  • Primitive tokens hold values. Semantic tokens hold intent. Component tokens hold overrides. The cascade only works if each tier respects the others
  • Naming is design - `--color-border-critical` survives a rebrand; `--cherry-500` doesn’t
  • The token system is the smallest part of the work and the part everything else depends on

Assets.

— Design kit, component library & playground

  • A component library is parts; a design system is the rules for assembling them
  • Parity between Figma and code isn't a nice-to-have - it's where the system lives or dies for adopters
  • I'd rather ship five components I'd defend than fifteen that need rules to be safe

Distribute.

— Documentation, guidelines & governance

  • Documentation turns the system into other people's tool.
  • I write the no's down. A list of what didn't make it into the system, with one-line reasons, prevents the same conversation from repeating every quarter
  • A system one person maintains is a bottleneck; the contribution model decides whether you're building infrastructure or running a help desk
Explore the design system

§ 06 - How I think

A typical daily dilemma.

A product team needs a date range picker for a reporting feature shipping in 3 weeks. What do you do?

Custom components bypass the system and create drift.

Risk

Build it custom for their use case.

Fast for them — but now there are two date pickers when the next team asks. Custom components bypass the system and create drift.

Trade-off

Add it to the system backlog and make them wait.

Proper governance, but 3 weeks is tight. They’ll build it custom anyway. A rigid process that ignores timelines loses trust.

Best

Check if it can be composed from existing primitives.

The system has a calendar, a popover, and an input. Composing them covers 80% of the need — and stays in the system.

Explore more dilemmas in the playground

Live tokens.

§ 05 — Inspector

Tokens decide every colour, space, and shadow on this page. The inspector docks to the right of the viewport and lets you rewire any token in place — changes apply across the portfolio and persist on your machine.

§ Next chapter

The showcase,begins here.

That's one dilemma in the system. Three deep-dives follow - how a design system earns adoption, how a UX process survives real constraints, where the line moves when AI joins the team.

Go to showcase

— One dilemma down, three deep-dives ahead.