sansserif.

Design is a process.
Not a preference.

How I run product design. It starts with a question, not a canvas: what are we doing this for, and how will we know it worked. From there it’s evidence-led and built with the team, never alone, down to a screen I sign off because it does what we set out to do.

Selected work

obseed

Designed the website, navigation, filters, onboarding and error states.

IBMiX, Heineken

Designed one ordering platform that bends to each market’s rules.

Finanzcheck

Made people’s credit readable in one app, validated in beta.

Covestro

Made how a coating feels explorable on a screen.

The operating model

  1. Frame the why

    Start with the why.

    A hypothesis, problem statement or goal, fixed before anything starts, so scope can’t creep and the target can’t shift.

    Goal

    The outcome. The why.

    KPI

    How we know we got there.

  2. Find the pain

    Find where it hurts.

    Talk to the business, read the data and the research, talk to users. Evaluate what the current approach really does, not what it claims to.

  3. Scope with the team

    Cut it to what’s needed.

    Align with developers and POs on a manageable scope, research, a small refactor, or bringing a dated flow up to standard.

    researchrefactorUX fixredesign

  4. Put it on the board

    Plan it, don’t react.

    Tasks defined, scope estimated, work assigned. The roadmap and sprints stay predefined, so nothing new can torpedo them mid-flight.

  5. Build, never in silos

    Bring everyone along.

    UX leads the alignment, but stakeholders, PO and developers stay updated. Findings are shared as they land, the team brought along for them.

    UXPODev

  6. Hand over

    Hand it over clean.

    Once the journey or screen is done, it goes to the developers with the context they need to build it exactly as intended.

    designbuild

  7. Design QA, sign off

    Built equals intended.

    After the technical QA, I check the build against intent. Does it behave, look and feel as designed? I sign off only when it does.

    intended
    built ✓

  8. To the backlog

    Nothing gets lost.

    Out-of-scope findings and follow-ups go to the backlog. I triage them with the PO, so effort is spent when it’s needed, not when it’s wanted.

The system

Only real once it ships in code.

I’ve run one of these: the Scout24 system, steered through the team. A style guide is the visual half. A design system is that, plus the coded half developers own, aligned so the two never drift. Defined in Figma, built with engineering, and only then productive. Four parts hold it together.

Tokens, not swatchesthe shared source

Color, type and spacing live as named variables, shared between Figma and code. Design and build read the same values, so they can’t quietly drift apart.

Governed, like a teamthe contribution model

Who owns it, how a component earns its way in, how it versions. A system without rules rots into a folder of one-offs. The same idea as a constitution for a team.

Accessible in the componentnot a later pass

Contrast, focus states and target sizes ship inside the component, not bolted on at the end. If the base is accessible, everything built on it inherits it.

Built with engineeringor it isn’t real

Design defines the system; developers make it live in code. One without the other is a picture of a system, not a system. Productive means both halves exist and match.

Currently available.

Product ownership and user experience leadership. Evidence based. Across banking, fintech, SaaS and more.

Let’s talk