I’ve been building products for nearly three decades and one of the things I wish someone had told me early on is this: you don’t need to be a designer, but you need to understand design well enough to have an opinion.
A “this flow is going to confuse people and here’s why” opinion. That’s a fundamentally different skill, and it’s one that separates good PMs from great ones.
Design Literacy Is a Product Superpower
Most PMs I’ve worked with fall into one of two camps. Either they defer entirely to the designer (“you’re the expert, I trust you”) or they micromanage pixels without understanding why.
Neither works great.
The best PMs I know can open a Figma file, look at a proposed flow, and say: “This solves the problem, but I think we’re going to lose people at step 3 because there’s too much cognitive load.” That’s product judgment informed by design principles.
Here are the fundamentals that have made the biggest difference in how I work.
Visual Hierarchy Drives Behavior
Every screen has a job. The user lands on it and their eyes need to go somewhere. If everything is bold, nothing is bold. If there are six calls to action, there are zero calls to action.
This sounds obvious, but I can’t tell you how many product reviews I’ve sat in where the page is trying to do five things at once. The conversion data always tells the same story: users don’t know what to do, so they do nothing.
The principle is simple: every page should have ONE primary action. Everything else is secondary.
When I look at a design now, the first question I ask is “what’s the one thing we want the user to do here?” If the designer can’t answer that in one sentence, we have a problem.
Consistency Reduces Cognitive Load
This one took me a while to internalize. Consistency is about reducing the mental effort required to use your product. (If you haven’t read it, Schneiderman’s Eight Golden Rules is a great foundation for this.)
When a button is blue in one place and green in another, when the save action is top-right on one page and bottom-left on another, when confirmation messages look different everywhere, each inconsistency is a tiny tax on the user’s brain. Individually they’re nothing. Collectively they’re the reason people say “this product feels clunky” without being able to explain why.
As a PM, I’ve learned to flag consistency issues early. They compound. And they’re 10x easier to fix in design than in code.
Feedback Loops Build Trust
Users need to know their action worked. Every single time. No exceptions.
Click a button? Something should visually change. Submit a form? Show a confirmation. Trigger a process that takes time? Show a loading state.
I still see products that leave users wondering “did that work?” And every time that happens, trust erodes a little. I’ve started treating feedback loops as a product requirement, not a design nice-to-have.
Whitespace Is Not Wasted Space
My instinct as a PM was always “we have this space, let’s use it.” More features visible, more value communicated, more reasons to convert.
That instinct was backwards. Whitespace is what makes the important things important. It’s what gives the user’s eye a place to rest.
Some of the most effective design changes I’ve seen were about removing things. Taking away a sidebar. Eliminating a secondary nav. Letting the content breathe. The metrics almost always improved.
Accessibility Is Just Good Design
I’ll be honest, I used to think of accessibility as a checkbox. Something we needed to do for compliance. I was wrong and it wasn’t until I reached mid-forties that I started to recognize why they are necessary.
High contrast text is easier for everyone to read. Clear labels help everyone navigate.
Keyboard support benefits power users as much as it benefits users with motor disabilities. When we improved accessibility on our platform, our overall usability scores went up across the board. For everyone.
The PM’s Role in Design
My job is to define the problem clearly enough that the designer can solve it well. I challenge designs that optimize for aesthetics over usability. I push back when a beautiful mockup doesn’t account for edge cases, error states, or the reality of what happens when a user has 500 items instead of 5.
I don’t draw wireframes or pick colors or argue about border radius.
The best design partnerships I’ve had were two people with different expertise looking at the same problem and making it better together. That only works when the PM speaks enough design language to have the conversation.
I wish I’d started learning design fundamentals earlier. You don’t need a course. You don’t need to learn Figma (though it helps).
Just start asking “why” when you see a design decision, and pay attention to the answer. That habit alone will make you measurably better at your job.