Product design thinking

Like many other designers in the industry, I was mostly self-taught. When I was starting, there wasn't really a field of product design for taking classes. We had to figure it out from others along the way, along with our own musings and trial-and-error.

I remember one dashboard that I designed. It was pretty bad, but I was new and trying my best. It wasn't pretty. It goes without saying, if you're considering whether you need a dashboard, the answer might be no—but in this case it solved the problem that we needed, and the client was happy.

So, most days I feel like I'm just getting started and barely understand the principles of how to apply good design. If you're newer than me, though, and are looking for some things to pay attention to, here's a good list to start from.

Make it as simple as you can, then pause

As humans, we want to hedge our bets. We don't want to commit or go all in; we want options. You'll see this when you're designing software. We want two ways to do things, multiple views, lots of words to get the point across—all of these come from a desire to ensure that all edge cases are accounted for, and no one will get lost using the software.

In reality, though, you're just making a muddy mess, and most people just don't read. If you're building screens with information on them, try an exercise where you remove 75% of what's there, and then only add things back if it's not clear how to proceed.

So when you're trying to decide whether you should account for all use cases, don't. Start with the simplest path forward, and only add on when you see a compelling reason to do so.

If the launch of your product depends on that extra sentence to give the right caveat to ensure that someone doesn't miss how a specific piece should be used—I'm sorry to tell you, but that's not going to cut it.

There's been so many times that I've been tempted to just add more descriptions, make things bolder, cram stuff together, anything in the name of trying to make sure that we captured what mattered.

The result, of course, is that by emphasizing everything you actually emphasize nothing.

Once you have cut and simplified it down, and have evidence that the path is understandable, quickly ship and learn from the marketplace. Don't iterate forever, tweak into infinity—there's diminishing returns on this. Another month spent polishing a screen to perfection isn't going to do as well as shipping, learning from real people, and then tweaking over the ensuing weeks.

Follow best practices, until you don't

We've all grown up in a world where we have an expectation about how things work. If we see a big shiny button on a page, we'll press it. If we see text underlined, we assume it might be clickable. If we see a hamburger icon, we guess it might open something else up.

These patterns have evolved and settled over decades, and they're worth following. Spend time understanding what's out there, what exists, how it's used, and don't stray from it unless you have a good reason.

And no, the first reason you're thinking of isn't good enough. I can't tell you how many times I've gone and created some incredibly cool, unique and unheard-of interface, only to find that it completely falls apart in the real world. It's far better to pick from off the shelf pieces—design patterns we've all been clicking for years—than to try and reinvent how I should interact with your designs.

Over time we grow to expect that things will just work a certain way, and you better have a good reason to go against that.

New designers (and us old ones) struggle with this. We want to make something novel, to flex our muscles in creating the perfect component that works in just this one situation.

Stop. Leave that for your Dribbble pages.

In production, the real world, you're better off understanding the 20 most used components, sticking to them, and coming up with simpler pages and flows that don't need some super complex, multi-segmented-dropdown-toggle remixed with status signals and varying states.

Care deeply, without getting precious

Care about your craft, care about the work you do, and invest the time into making sure that you've thought about the interfaces you're making, that you've owned the understanding, and that you've tested what you're building.

Don't leave your brain outside the work; spend the time to understand why someone might be approaching your product, see how they might use it, and then find a way to solve it that's obviously simple in hindsight.

Learn design patterns

The more time you spend diving into patterns, studying what's out there, and putting simple blocks together to build out screens, the more this will become second nature.

And notice that up until this point, I haven't even mentioned AI. It knows about all of these patterns, and will happily build out pages with them—but it doesn't intuit the emotional nature of why I'm approaching a product, the context I have before and after I view your page, and it can't understand how all those pieces fit together.

That's what you can offer.

Years ago I worked with a fantastic product person—someone I was initially shocked to realize had no prior experience building products—who learned by studying patterns endlessly. He downloaded apps, took screenshots, and replicated design after design until he could see why and how it had been built.

I learned from that, and now can pull from a catalog of patterns in my brain and apply them to a given screen based on the knowledge of how these things are typically done.

Now, that doesn't even come close to implying that I'm perfect at this. I'm surprised time and again how users respond to my work—but I adjust and improve my priors as a result.

--

And finally, have fun with it. AI is doing a lot these days, but we aren't at a point where we can give up the reins to our brains. We still need your thinking, your understanding of how the pieces fit together, and the care you bring to building products that are useful to the rest of us.