HOW I APPROACH PRODUCT PROBLEMS
I don't diagnose a product from a screenshot.
Every product problem comes with context.
There are existing decisions, user behaviors, technical limitations, business goals, assumptions, data, feedback, deadlines, and people who already understand different parts of the system.
I don't want to look at a screen and immediately decide what should move, change, disappear, or look different.
First, I want to understand what I'm looking at.
01 / CONTEXT
Context before interface
A screen is only one part of a product.
I want to understand what happens before it, what happens after it, who depends on it, what the user is trying to accomplish, and what the business expects it to achieve.
Changing the interface without understanding that context can create a better looking version of the same problem.
I want to solve the problem, not redesign the symptom.
02 / DEFINE
Define before deciding
The first question is not:
“What should we design?”
It is:
“What are we actually trying to solve?”
Sometimes the original request is exactly right.
Sometimes it is only part of the problem.
Sometimes the work reveals that something completely different needs attention.
My responsibility is not to protect the first idea.
It is to help get us closer to the right problem.
03 / PROCESS
The problem determines the process
I don't believe every project needs the same process.
Some problems need deeper discovery.
Some need data.
Some need conversations with users.
Some need rapid prototypes.
Some need systems thinking.
Some need interface exploration.
Some need code before another design file.
I use the tools the problem requires.
The method serves the problem.
Not the other way around.
04 / SYNTHESIS
Make sense of the pieces
Product work rarely arrives perfectly organized.
There are ideas, constraints, opinions, requirements, feedback, existing designs, technical realities, business needs, and sometimes conflicting information.
Part of my job is to take those pieces and make sense of them.
UnderstandQuestionRemoveAddConnectAdaptTestShareCollaborate
Then turn what remains into something the team can act on.
05 / OUTCOME
Outcome over artifact
A polished interface is not automatically a successful solution.
The final question is whether the work improved what needed to improve.
Can people understand it?
Can they accomplish what they came to do?
Does it work within the technical reality?
Does it support the business goal?
Can the team build it, maintain it, and continue improving it?
That is the standard I care about.
- I design interfaces.
- I build prototypes.
- I create systems.
- I can work in code.
- Those are tools.