Observation
For a long time, I thought design meant creating something new.
Today, I realize that, more often than not, it begins much earlier.
It begins by observing.
I enjoy understanding how a system works, even when I didn’t build it.
Not to look for mistakes.
But to understand the decisions that led it to behave the way it does.
Over the years, I’ve analyzed applications, workflows, products, and services with the same curiosity I bring to a new project.
Sometimes an unexpected behavior turns out to be nothing more than a bug.
Other times, it reveals a flawed assumption, a fragile process, or a design decision that doesn’t hold up in real-world use.
That happened while analyzing a swimming device I use every day.
What began as a simple report gradually became a detailed record of recurring issues, patterns of behavior, and possible improvements.
Not because I was trying to find a bug.
Because I wanted to understand the system.
That’s when I realized that careful observation is already a form of design.
Every anomaly tells a story.
Every exception puts an idea to the test.
Every detail has the potential to suggest a simpler solution than the one imagined at the beginning.
The same approach had led me, years earlier, to discover that a Microsoft Word document is simply a ZIP archive.
I wasn’t looking for a clever trick.
I was simply looking at something familiar from a different angle.
Many of the ideas I value most didn’t begin by writing code.
They began by asking one more question.
And by observing long enough to find an answer.
Before I change a system, I try to understand it.