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.

At altitude

The work behind the screens.

As Head of Product Design at FinanceScout24, a Scout24 vertical on a 3.2-million-user network, I hired and built the design team and line-managed it.

Six designers and a freelancer pool. Together with the other verticals I set up a product-designer career track across Scout24. I managed the design system and the relaunch of the platform.

The team

Six designers and a freelancer pool, hired, line-managed, and grown through a career track.

The operating model

An intake and triage so the team’s time went where it mattered. A hundred requests became one prioritised line.

The design system

The design system and the platform relaunch, both managed across the team.

What outlived it

The intake, the testing pipeline and the review cadence outlived the engagement.

“A valuable leader, recognised by leadership, peers and customers alike.” Director of Product, Scout24 Schweiz
Read the full Scout24 story

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. Five 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.

One template, every caseand honest by default

Every case below is shown the same way: problem, approach, exploration, the system, then a built screen. Each shows its real system, or none. Nothing invented to look finished.

Selected work

obseed

Product and experience design: athlete research, roadmap and the core flows.

IBMiX, Heineken

Product and experience design on a pan-European B2B commerce platform.

StepStone

Product and experience design: one-page checkout and pricing for the job marketplace.

Case in progress

Finanzcheck

Credit-management app: research, design system and an interactive prototype.

Covestro

Visual design: a system that turns the feel of a coating into a digital selection experience, with the presented prototype.

Evidence-based design.

A clear goal, the data to back the call, and a build I sign off against what we set out to do. That’s design I’ll stand behind.

Let’s talk