MAD/UX
Let’s talk

How I work.

Nothing here is exotic: understand, define, prototype, refine. The hard part is not skipping steps — most design goes wrong when somebody does.

Problem first

How many designers does it take to change a lightbulb?

I’ve been in way too many meetings where business people, technical people, and sometimes even designers were talking about changing a lightbulb (changing the UI, adding more features), but very few actually asked, “Why a lightbulb?”

The way I read it: the clearer you are about the problem, the easier it is to come up with a solution.

There were too many instances in my own career where I failed to understand the problem at hand and started working on wireframes and mocks, only to discover that I was solving the wrong problem.

Here is what AI actually changed: it compressed the 5 minutes into 5 seconds. Producing solutions is now fast and cheap. Figuring out the right problem to solve is exactly as hard as it was, and that was always the real job.

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem, and 5 minutes thinking about solutions.”

Albert Einstein

Framework

Design thinking.

Three factors shape every product. It is desirable: people want it. It is viable: it makes sense for the business, so it can sustain itself. And it is feasible: it can be built within the expertise, timeline and budget you have.

Design sits where the three overlap. The job is to help you figure out what the product is, or how it can be improved, with all three in mind.

Popularized by David Kelley and Tim Brown of IDEO

Three overlapping circles: user needs (desirable), business goals (viable) and technology (feasible). UX sits where all three overlap. Feasible Technology Desirable User needs Viable Business goals UX

Method

The Elements of User Experience, redefined.

The Elements of User Experience by Jesse James Garrett became a career-defining framework for me. It shaped my thinking as a designer. I have used it for years to design and redesign applications and websites of all kinds, and it has never failed me.

Over time I adjusted it to fit how I actually work. The chart below is my version, and the notes under it explain what changed.

  1. Look and feel

    Surface · How

    • Style guide
    • Universal design principles: color, type, whitespace
    • Mood boards

  2. Interface

    Surface · How

    • Prototypes
    • Mocks / wireframes
    • Universal design principles: layout, proximity, uniform, hierarchy

  3. Flow / IA

    Structure · How

    • Conceptual models
    • Flow charts
    • Use case diagrams
    • Customer journey maps (touch points)
    • Context of use

  4. Features

    Strategy · What and when

    • Design brief
    • Vision / value proposition
    • KPIs
    • Alignment model

  5. User needs · Business objectives

    Strategy · Who and why

    • User story map (mile wide, inch deep)
    • User stories / scenarios
    • Personas / empathy maps
    • Mental models

  6. Environment / culture

    Foundation

Adapted from The Elements of User Experience by Jesse James Garrett. My walkthrough of the original model

Scope lives with strategy

Garrett separates scope from strategy. I like to think of user needs, business objectives and features all together. Often, when the brief for a project comes in, it already outlines the features the business would like to include.

Skeleton and surface work together

In my practice, I don’t separate visual design from the skeleton. I often use low- to mid-fidelity mocks to explore layout and interaction ideas, but also colors and fonts.

Culture is the foundation

Every product is built inside an environment: the team, the company and its culture, and the market around it. That environment shapes every decision above it, so it sits at the base of the model.

Validate ideas, then test the solution

A good design process allows for quick iteration cycles: design something, test it, learn from it, iterate again. Sometimes we need to stop, backtrack and rework some ideas. That’s part of the process.

Process

  1. 01

    Understand

    User needsBusiness objectives

    I start by talking to your stakeholders and to the people who actually use the product, and I look at what they do, not only what they say. Then I write back what I heard. It is a simple habit that catches misunderstandings while they are still cheap.

    What you get

    • Conversations with stakeholders and users
    • A short write-up of what I heard
    • The workarounds people already use

  2. 02

    Define

    Features

    Together we write a short brief: the job to be done, the constraints, and the decision we are trying to make. We agree on what success looks like before anything gets built. If we cannot agree on that one page, we are not ready to design yet, and finding that out early is a feature.

    What you get

    • A one-page design brief
    • Success criteria, agreed up front
    • A list of what we are not doing yet

  3. 03

    Prototype

    Flow / IAInterface

    Flows first, then sketches, then a prototype you can click. I lean on familiar patterns so people have nothing new to learn. You see the work every week, and critique is specific: what works, what does not, what I am trying next.

    What you get

    • User flows
    • Sketches and wireframes
    • A clickable prototype

  4. 04

    Refine

    Look and feelValidate ideasTest solution

    The prototype goes in front of real people, and we watch where they get stuck. We fix what they trip over, check that every screen still traces back to the problem, and cut what does not. Then the look and feel goes on. The engagement ends with a decision you can act on: ship it, fix it, or drop it.

    What you get

    • Test sessions with real users
    • A prioritized list of fixes
    • The final look and feel
    • A clear call: ship, fix, or drop

Principles

Find the job

Nobody wants your product. They want a job done. If you cannot describe the problem without mentioning the product, you do not have a problem yet.

Research should surprise you

What people say and what people do are two different things, and you build for the second one. If the research did not surprise you, it was not research.

Cut to the riskiest assumption

Adding features is free now, which is exactly what makes them expensive. A first version tests the one assumption that could sink you. Everything else goes on a list for later.

Flows before screens

Screens are stops along the way. The journey is the product, so I design the journey first and the screens second.

Boring layouts win

People arrive already trained by every product they have used. Familiar patterns cost them nothing to learn, and original navigation is a tax they pay so a product can feel special.

The surface comes last

Decide what a product should feel like before deciding what it should look like. Restraint reads as intention: one font and two colors, chosen, beat ten defaults.

Working on something exciting?

Tell me about it — what you are building and where it is stuck. A short email is enough. We will figure out what to do from there.

Get in touch

Further reading

Behavior design

A behavior happens when motivation, ability and a prompt come together at the same moment. It is a useful check when people say they want a feature but never use it.

See BJ Fogg, Tiny Habits

Hook Model (aka Desire Engine)

Trigger, action, variable reward, investment: the loop behind viral products. It helps answer a simple question: why would anyone open this again tomorrow?

See Nir Eyal, Hooked: How to Build Habit-Forming Products