I almost didn't become a designer

Simon Metacci

I always liked people, and I'd told myself I wasn't the kind who'd spend his life in front of a screen.

Nineteen years later, it turns out the job was never really about the screen. It's about listening to people, understanding what they actually need, and caring enough to get the details right.

The things I liked all along, just pointed at products.

I taught myself front-end before finishing high school and started at one of Sweden's top agencies at eighteen. The first decade was hundreds of e-commerce builds, and every project taught me the same lesson: The problem on the brief is rarely the actual problem.

Somewhere in there I stopped asking how things should look and started asking why we were building them at all, and for whom. The years since have been about moving closer to where decisions get made. Systembolaget taught me how to align competing priorities. Electrolux taught me that showing a better version beats arguing for one.

Simon working with a product team

Today I work embedded with scale-up product teams. Same standups, same arguments, same wins: settling direction, building the systems, prototyping in code, and making sure the design practice I leave behind is stronger than the one I found.

The teams do the growing. I make sure nothing stands in their way.

Areas of expertise
Vision & strategyEnd-to-end product thinkingDesign systemsProduct discoveryPrototyping in codeDesign leadership
Team force multiplierConnecting design to outcomesDesign infrastructureCross-functional alignmentConversion optimisationInformation architecture
Working upstream with ambiguityMentoring senior designersRoadmap prioritisationDesign ops & workflowStakeholder alignmentScaling design quality
What I believe

Six things nineteen years taught me.

The fastest team wins.

Technology ships daily and AI works around the clock. In that world, the lasting advantage is a team with the infrastructure to listen, learn and ship faster than anyone else. Systems handle the repetitive work. People do the inventing.

Growth matters. People matter more.

A product is only as good as the team behind it, and a team is only as good as how it's treated. Customers, teams, partners, owners: the work should be a win for all of them, or it won't hold.

Start where the effect is biggest.

Most roadmaps are full of things that feel urgent and change nothing. I'd rather fix the one thing that moves the number, then sweat the details once the foundation holds. Details matter deeply to me. That's exactly why they come last.

The work people remember wasn't consensus.

Best practice gets you to average. Getting further means experimenting, questioning how things are done, and sometimes standing alone in a decision for a while.

Protect what produces the results.

Chase results while neglecting what creates them, your health, a team, a codebase, and the source eventually runs dry. A sustainable pace outlasts heroic sprints.

Optimism first. Realism second.

Almost anything is possible if you decide it is and break it into small enough steps. I've watched belief move more roadmaps than resources ever did.

Next step

Tell me about you

Just a conversation about you, your product and your team.