What distinguishes a great product designer from the average one? I think the answer lies in how they interpret the design scope.

Typically, the design scope will reflect the current business goals and team resources. It tells the designer what the product is supposed to do at a given time.

Whether a notional product roadmap, engineer capacity, or any specific constraints—we have it all in the design scope, defined by non-designer peers.

But the problem is the customers don’t read the design scope before using the product and most likely don’t interact with the product like we think they’re supposed to.

At the end of the day, people judge the product by what it does, not what it’s supposed to do.

The customers only care about their outcomes and probably don’t interest in the business goals or team resources.

They will blame the product for unpleasant experiences and not dig deep into its scope once things go wrong. People only criticise the final work—your design.

The design scope instructs designers to work based on hypothetical limitations, and when it’s not done right, it kills the creativity and deactivates common sense.

It’s hard to think and feel like customers when we have too much context and know which design will move the team’s backlogs.

As a product designer, I hate design scope because it forces me to approach the design differently from how the customers experience the product.

After all, the product designers should represent the customers, not the organisation.

That’s why designers do user research, rapid prototyping and usability testing to hang around with the customers day-in-day-out.

“Ask many great questions before reading the design scope to protect the customers’ point of view”

I came across many great product designers with one thing in common—they never let the design scope tell them what to do. 

Either they ignore it or create a new one that works for them.

They ask many great questions before they read the scope to protect their naive point of view. They secure the customer’s common sense in their craft.

Here are my three steps to deal with the design scope.

First, I ensure people are happy and sign off the design scope—then I forget about it and come to work fresh.

Second, I asked many questions to create the creative assumptions, in other words-my own design scopes.

Lastly, I validate my rebel thought with my alliance (the customers).

If I got something right, we’re landing on a better design, and we can rewrite the design scope later. But if I’m wrong, customers love it anyway.

Seriously, if you can’t recalibrate the design scope, you probably don’t have a say or a seat at the strategic table—which is sad.

Stop letting the design scope limit your design progression.

Businesses know what they want, but designers understand what their customers need.

The design scope should be a floor, not a ceiling.