Alright, time to ruffle some feathers. This month’s buzzword on the chopping block? User-Centered Design.

You know, that phrase gets thrown around so much that it’s practically lost all meaning. Every time I hear it in a pitch or a meet-up, my eyes do an involuntary 360-degree roll. If you are close to me, you can practically hear the roll.
I should have that checked.

Here’s my take: this overused, over-glorified term is a distraction.
It pulls designers away from their actual job: solving real problems and delivering value.

I’m going to throw up a fallacy here: The real job of a designer has very little to do with the customer. Before you cast your stone, let me explain.
It will take a while, but I promise, before the end, I’ll get to the point.
Stay with me.

So, what does a user want and need?
That’s not a designer’s endeavour; it has never been. Knowing is vital, but if you can’t stop your mind from generating solutions on the fly, you should not be near the data before the research is validated.

How does the user get compensated? Not your call.
Maybe you can talk about how a market is approached, but it’s not your call.
All the above is a business duty.
Your design solution should be focused on solving a problem for the customers and equally on making money for the business you work for.

Somehow, we got ourselves into this mess where we, the designers [alone], feel responsible for defining the market’s needs. We became the self-appointed advocates of the categories of customers, and paradoxically, we lose almost every battle with the product and marketing team.

The design team is meddling with the business team’s responsibilities, and in return, the business team and other functions have hijacked the whole design function.
Instead of solving real problems, designers are now order-takers, trapped inside the design bubble, while product, marketing and engineering call the shots.
It’s a mess.

Let me be crystal clear: the business team should be the primary stakeholder in defining what problems need solving. Designers can (and should) advise, but so should every function within the organisation. 

Everyone should do their specific research and bring evidence to the table.
It’s a shared effort, and the primary stakeholder in defining a problem, you guessed it, is the business team.

And let’s be honest here; designers are actually the worst people to validate problems. Why? Because our job is to solve them. That mindset is like a walking hammer. Everything looks like a nail. We see problems everywhere, even where they don’t exist. How do I know? Just look around at the rate of failing projects of any size where the designer mind contaminated the process.

My favourite hobby horses are the Metaverse and the AI Pin, but Apple’s Vision Pro is not far from the podium. They all “solved” problems we didn’t know we had.

Are you still here?
Props to you. Let’s keep going.

Only after a problem has been validated from every angle/function.
Only after the business has decided it’s worth investing in a solution.
Only after it’s clear that this thing they want to solve is sustainable.
This last one is crucial – for business, product and brand.

If all, some, or none of the above are validated, let the business team take responsibility for the bet. If there is enough/any evidence, start with a strategy you can align with other functions.
Yes, before carving your solution in stone. A strategy is also a bet; you can (and should) update it if new evidence shows up.

One more thing: solutions need to be validated too. By whom? By [future] users/customers, of course.
Not every idea that sounds great in a brainstorm session actually works in reality.
Not every feel-good thought can be built into a product.

Once the problem and solution are validated, and there is an obvious connection between the two, you give designers more responsibilities with a strategy in place.

That’s when these lovely creative folks should be allowed to experiment and build the infrastructure and the vehicle for this brilliant, market-ready solution.

Skipping the steps, not allowing the business and product to take responsibility, go through the work and validate their assumptions, creates an endless supply of cortisol.
Design frameworks and principles only work when there is consensus on what problem must be solved and some agreement on how.

Well, I promised to return to the user-centered design, didn’t I?
A designer’s job, along with other functions, is to help building the solution.
The job is about building an infrastructure for a vehicle to move on. That vehicle is what we call a product. 

Sometimes, the infrastructure is a service. Sometimes value can be delivered via a service, and the vehicle delivering some value is a person, but this is for another time.

A well-designed vehicle can take this precious cargo to the market and bring back a great reputation and revenue. The precious cargo is the value we can create inside the organisation using creativity, technology, physical parts or code.

This vehicle will unload the cargo on the market and must bring back revenue, awareness, and respect, qualities you want to build into your brand’s foundation and keep the lights on.

User-centered design is distracting because it removes the focus from this balance of delivering value to the market and the shareholders.
The solutions we design must, therefore, be value-centered. The conversations are less contradictory, and the cortisol level gets at the right level again.
If you would like to learn more about this, please read this.

Every successful product out there and every thriving business has found that balance.

As I’m cleaning the chopping board, the user-centered design is now resting in a black plastic bag, and the next one is “experience” in the context of product design.

I’ve got to go and sharpen my tools because this one is everywhere, from visiting WB Studios to eating cooked dough covered in ragu.

I’ll see you soon.