"Design without observing becomes an expensive guessing game."
This quote came to mind while I was (for the thousandth time) complaining about the design of my expensive personal coffee grinder:

To understand my point, a bit of context helps. Some time ago I got into coffee and, like any stereotypical coffee enthusiast, realized I needed to grind my own beans. I went to a fancy kitchen store and bought this machine. It was automatic, small, nice-looking, and offered a wireless experience. It sounded great, but soon problems appeared that made me wonder: how do you design a simple machine with so many flaws? Just to mention a few:
- Coffee beans are hard, so it’s no surprise the motor sometimes needed help given its size. But to help it, I had to remove the glass container while it was grinding—which was impossible to do without making a mess.
- The grinder was “wireless,” but when it wasn’t plugged in, it tended to lose power for some reason. That didn’t help with beans getting stuck.
- The power switch was a tiny button hidden behind the charging compartment. Sure, it kept the grinder looking clean, but it also made it impossible to turn on while charging—and as I said, I needed it plugged in to avoid losing power. Using it became a complicated maneuver.
Unsurprisingly, the machine eventually broke. The materials looked fancy, but the charger connection wasn’t well made, and one day it fell apart. It was one of the worst product experiences I’ve had and made me ask: how does a company fail so hard at making a usable product?
One period of history I love talking about with anyone who will listen is the ’60s, especially what happened at Xerox PARC. For me, that’s when modern product design was born—when the gap between fast-moving technology (as is happening again) and human behavior started to close. And it happened by doing one simple thing: observing.
Observing is critical to good design because it’s directly tied to how many iterations you can make within a timeframe—in other words, how fast you can test, observe, and improve a solution. If someone had observed how my coffee grinder was used day to day, they would have quickly realized how easy it was to fix those small but annoying issues, which could have paid off for the business in the long term. I’m sure I’m not the only unsatisfied customer.
All this made me realize how expensive it becomes for a business to skip observation during design. Software product development runs into similar problems, and I have to say, most of the time it’s on us as designers—this is where we should play a more critical role. I agree products shouldn’t ship incomplete, but I also believe we often get “lost in the sauce” or operate overconfidently based on our assumptions. There’s a quote I tell myself whenever I feel my ego steering design decisions:
You don’t know shit.
It doesn’t matter how many years of experience you have—user behaviors are hard to predict and constantly changing. They evolve as technology and society evolve. Guessing and moving forward on risky assumptions isn’t a shortcut; it’s a costly gamble. The real shortcut is to test and fail as quickly as possible, because more iterations lead to higher-quality outcomes. Even though that approach seems obvious, many organizations—and their structures—still punish failure or overvalue the consistency of their design systems. It doesn’t matter how clean or consistent things look if they don’t consistently solve problems, as my broken coffee grinder can attest.