How I work

A note on paper, before the methods

Every project I've shipped started on paper. There's something magical about scratching a pen on a page and drawing letters that helps me unblur what's about to be created and connect with the matter more profoundly than I can on a screen.

Staring at Figma or asking my agent of choice is a new way of doing this, useful in its own right, but the contact with paper and the feeling that I'm in control can never be replaced. Twenty years in and the first hour of any project is still pen on paper — the questions I want answered, the people I think I'm designing for, the shape of the thing I'm about to build. The screen comes second.

I mention it because the rest of this page is about methods and tools, and methods without that earlier private thinking step are just frameworks dressed up as work.

1. Diagnose the business and the product system

Before the pixels, the question is what behavior matters. I spend the first month of every engagement listening — to the CEO, to engineering, to support tickets, to users when I can get them — and writing down what I hear in plain language. By week four I usually have a one-page diagnosis: what works, what's blocked, where design has the most leverage, and what should happen next.

The output isn't a recommendation deck. It's a shared map. A team that agrees on the diagnosis can disagree productively about the solution. A team that hasn't aligned on the diagnosis will argue about the solution forever.

This is also where I work out what notto do. That part comes from two places — deep solitary thinking of my own, often on paper, and pressure-testing with the team. Subtracting scope is harder than adding it; most teams I've joined had a roadmap full of things nobody could honestly say belonged.

The earliest example I'm proud of is the GVC cashier rebuild — two workshops in Tarifa with the cross-brand team, a shared diagnosis that the real bottleneck was first-deposit failure rate, and a redesign that ended up doing 4x average deposit value across fifteen brands without anyone touching the marketing budget.

2. Shape the smallest thing that teaches us something

Big bets are cheaper when the first iteration earns the right to the next one. I treat each early build as a deliberate test of an assumption, not a delivery.

The named method I use here is hypothesis-driven design — four-line statements (We believe that… For… We will… We'll know this is true when…) that turn assumptions into testable claims a cross-functional team can argue with productively. I learned the discipline the hard way at Fretello, applied it through the SellerCrowd contribution-engine rebuild, and it still does most of the heavy lifting on day-one of every new engagement. The full case study covers the method, the conditions where I'd validate quantitatively versus qualitatively, and a worked example from the Fretello iOS notifications prompt.

The four-line shape matters because it forces a commitment. “We believe X” is harder to wriggle out of than “we should think about X.” When the bet fails, the four lines are also the cleanest post-mortem you can run — which line was wrong?

3. Design the system, not just the screen

Loops, incentives, pricing, community, data — the screen is the visible end of the system. If the system is broken, no amount of pixel craft will fix the product. If the system is right, even a rough screen can carry the experience.

SellerCrowd is the engagement where this principle did the most visible work. When I joined, the community was flat — contributions had plateaued and the standard product instinct was “redesign the contribution form.” The actual lever was the system around the form: who gets recognised, when, for what; how the recognition compounds into status; how status feeds back into more contributions. Five years on, the contribution engine drives a 65x lift in monthly contributions (360 → 23,770) and 3x MRR ($111K → $356K) on flat headcount.

This is also where I push back hardest when a stakeholder asks for a “redesign.” Often the screen is fine. The system around it isn't.

4. Prototype fast with AI

Claude Code, prompt specs, eval loops. Shipping has become a new way of thinking. The cost of finding out whether an idea is good has collapsed.

The portfolio you're reading is itself a worked example. Building in 2026 walks through the eight weeks of evening sessions that shipped this site, the chatbot in my voice, the lead qualifier that scores each conversation, and the digest that emails me only the leads worth my time. Two-thirds of the work was deciding what to ship, not how to ship it. The bottleneck was never the code.

What this changes for the operating model: prototyping is no longer a separate phase reserved for the things engineering can afford to spike. It's a tool I reach for inside design conversations, mid-meeting. “What if it looked like this?” is now answered in twenty minutes, not three sprints.

What it doesn't change: the judgment about which prototype to build. That's still the senior IC's job. Models are fast and literal; they need someone in the room who knows what the team is actually trying to learn.

5. Ship, measure, adjust

The work isn't finished when it's pretty. It's finished when the numbers move.

The named method I lean on here is SUM, the single usability metric — a way to compare two designs on one standardised score that combines task completion, time on task, and satisfaction. Cheap, fast, objective evidence that doesn't depend on engineering instrumentation. The full case study walks through how I used it at Fretello in early 2019 to pick between two Learn Path concepts (The Path vs The Birdseye), and the combined design that eventually shipped to production.

SUM is one tool inside a broader habit: ship the thing, watch the metric, and be willing to revert. The version of any product I've shipped that I'm proudest of is rarely the version I drew first. It's the second or third pass after the first one told me something I didn't expect.

A note on workshops

I run workshops a lot. They're how I diagnose, how I shape, and how I land team alignment on what to do next. The point of the workshop, every time, is to end with commitments — not with vague alignment, not with a nice deck, not with a “we should follow up on this.”

My favourite book on the topic is Gamestorming. It was there before Design Sprints and it will be there after Design Sprints — the canonical reference for facilitators who want to design their own structure for their own problem. I borrow a few exercises from the Sprint canon when they fit, but I almost never run a Sprint by the book. The right workshop is the one I custom-craft for the team in the room, using Gamestorming's recipes as building blocks.

The single most useful facilitation move I know is voice-leveling. Unlocking a team is often as simple as giving everyone equal time to speak. That means controlling the loud voices — the most senior person, the most opinionated person, the most extroverted person — and giving the quieter ones room to share their thinking before anyone else gets to react. The first time you do this in a team that's used to one person dominating, the energy shift is unmistakable. People who haven't spoken in three weeks suddenly produce the most useful insight of the session.

The Tarifa workshops at GVC, the Barcelona Learn Path workshop at Fretello, and the contribution-engine workshops at SellerCrowd were all built this way: a custom structure, Gamestorming-derived exercises, and ruthless voice-leveling. All three produced commitments the team kept.