What should
exist?
I keep coming back to one question.
What should exist?
It sounds simple. Maybe even obvious. But taking the question seriously has changed how I approach design.
I have always asked why. Probably too much, sometimes. Over time, though, I realized that I am not asking why simply to be thorough. I ask because an answer that stays on the same layer as the thing it is supposed to explain rarely feels complete.
A feature is proposed. Why does it need to exist?
Because people need it.
Why do they need it?
Because of a particular behavior.
Why does that behavior exist?
Because of something in the surrounding system.
Sometimes the answer is straightforward. The brief is clear, the constraint is real, and the right thing to do is simply make it well.
But sometimes the questions reveal something underneath the original request. The problem is different from how it was first described. A constraint has an important consequence. A user's behavior doesn't match the assumption. Or a different intervention could solve the same problem more effectively.
That is when I want to go one level deeper.
Understanding before deciding
Going deeper doesn't mean making things more complicated, or endlessly questioning the brief.
It means trying to understand enough to know what is actually worth doing.
A public library might appear to have a search problem. When I look closer, the problem can involve fragmented catalogs, institutional boundaries, metadata, authentication, disconnected systems, and the way people actually discover knowledge.
A journaling product might appear to need an AI assistant. A closer look shifts the question to the relationship between a person, everything they have written about themselves, and a machine that can help them make sense of it.
The point isn't to reject the original problem.
It is to understand it well enough to make a better decision about how to solve it.
Sometimes that means changing the approach. Sometimes it means confirming that the original approach was right.
Either way, once the problem is clear, I want to commit.
Design does not stop at the interface
This is probably why my work tends to move between research, systems, interfaces, technology and code.
I don't see these as completely separate stages of the process.
Technology changes what can exist. Human behavior changes what should exist. Systems determine what is possible. Interfaces mediate the relationship between all of them.
So when I build something, I don't always wait until the end to think about implementation.
Sometimes I need real data before I can understand the information architecture.
Sometimes I need to build the system behind an interaction to understand the interaction itself.
Sometimes a technical constraint changes the design.
Sometimes the fastest way to answer a design question is simply to build it and see what happens.
Code, in those moments, isn't just implementation.
It is a way of thinking.
That doesn't mean everything needs to be built. I don't want unnecessary features, unnecessary technology, or complexity for its own sake.
The question is always:
What does this situation actually require me to make exist?
If something is necessary to support an important human or system relationship, it belongs.
If it exists only because it looks impressive, it probably doesn't.
Making the answer real
I care about ideas, but I don't want them to remain ideas.
A concept becomes much more interesting to me when I push it far enough into reality that it starts pushing back.
A prototype exposes an assumption.
A technical constraint changes an interaction.
A user behaves differently from what I expected.
A system reveals a relationship I had missed.
Those moments make the design more precise.
This is why I tend to move between thinking and making.
I understand, question, build, learn, reframe, and build again.
The process is rarely perfectly linear because the problem is rarely fully understood at the beginning. But the goal isn't endless exploration. The goal is to reach enough clarity to make a decision and take responsibility for it.
What should exist?
I think this is ultimately what design means to me.
Not simply making something usable.
Not simply making something beautiful.
Not simply answering a brief.
But understanding the situation, deciding what is worth changing, and then making that change real.
That requires curiosity, research, technical understanding, judgment, craft, and a willingness to change your mind.
It also requires a point of view.
Because there is rarely one inevitable answer to a design problem. At some point, someone has to decide:
This is the thing we should make.
And then we have to make it.
That is the part of design I find most exciting.
The question is simple.
The work of answering it isn't.