Nothing here is exotic: understand, define, prototype, refine. The hard part is not skipping steps — most design goes wrong when somebody does.
Problem first
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
Method
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.
Look and feel
Interface
Flow / IA
Features
User needs · Business objectives
Environment / culture
Adapted from The Elements of User Experience by Jesse James Garrett. My walkthrough of the original model
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.
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.
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.
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.
Lenses
Desirable, viable, feasible
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
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
Desire engine
Trigger, action, variable reward, investment: the loop behind products people come back to on their own. It helps answer a simple question: why would anyone open this again tomorrow?
See Nir Eyal, Hooked: How to Build Habit-Forming Products
Process
01
User needs · business 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
02
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
03
Flow / IA · interface · look and feel
Flows first, then sketches, then a prototype you can click. I lean on familiar patterns so people have nothing new to learn, and the visual polish comes last. You see the work every week, and critique is specific: what works, what does not, what I am trying next.
What you get
04
Validate ideas · test 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. The engagement ends with a decision you can act on: ship it, fix it, or drop it.
What you get
Principles
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.
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.
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.
Screens are stops along the way. The journey is the product, so I design the journey first and the screens second.
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.
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.
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