Taste is a dead end; what you should have is a point of view

By justifying decisions on the basis of taste, designers are throwing away the influence they need for preventing low-value feature bloat

Is “is UX dead” the right question to ask, or at this point have we gotten to asking “is UX still dead?” Ryan Rumsey has put together a resource for keeping track, so now the rest of us no longer have to tune in live to check the score. 

And we seem to have a fellow traveler in the funeral procession. Microsoft has followed the likes of AirBNB and Spotify, planning to slash the product management headcount in half. Unfortunately, as much as design likes to pretend that we are a strong independent silo, the PM function is a critical partner for getting good design from Figma to production. Unfortunately, they are currently too occupied by their own impending doom. 

Reading Material

When it comes to demonstrating ROI, Product has a few more cards to play than UX. The most obvious one is scale: grabbing bigger markets and customers with higher lifetime value is a sure path to safety. Steve Farrugia points out an interesting consequence of this trend: because business customers are so much more profitable, everything is now a productivity app

When all the tech products try to be general purpose enough to satisfy business and personal needs, the business needs will inevitably be dominant because that's where the big money is. The result is the workification of everything. 

 If your product wasn't a productivity tool before and has nothing to do with work, the looming pressure of layoffs demands that you figure it out. Whatever problem it was designed to solve before, it's now solving a whole unrelated set of problems with a bunch of new features awkwardly stapled to it.  

Obviously this is terrible for the long-term health of the actual product. Joan Westenberg calls this featurecide: the creeping accumulation of features that are disconnected from the core product mission, justified by the excuse that they serve a use case. 

A use case is a solution to a problem they wish you had

Any accidental resemblance to fulfilling a real user need is usually shed at this stage. After all, velocity is key; PMs have been some of the most vocal supporters of the “design is slowing us down” myth and don't want to fall in the same hole. Even though we know that what people say is not what they do, it's faster to just ask people if they want new features and then use that reasoning to justify a solution for a completely unrelated use case as the “lean skateboard” output. 

Unfortunately, substituting research with validation skips a critical step in the process. Without taking the time to frame a real problem, we have no understanding of what success actually looks like. The main purpose of the “solution” is to launch within the timebox provided by the roadmap.  

”If ChatGPT tells you that millennials want more sustainability from eCommerce websites, do we know what to do? Do we know how these people define sustainability and how our target audiences expect us to execute on that?”

Without a meaningful North Star aside from velocity, decisions are made haphazardly, each one placing constraints on what it will be possible to do next time. The product managers who manage to evade layoffs in the short term (or for the programmers who are given Product work as additional duties) end up presiding over a colossal pile of user experience debt.  

Needless to say, this is a big problem for UX! And we have a great opportunity to fix it! One of my most fringe and radical beliefs is that designers are not the only people who want to do good work and if UX were to stand shoulder-to-shoulder with Product, we could dismantle the race to the bottom at its foundation by achieving efficiency through doing good design instead of no design, and push back against the executives creating these incentive structures

Unfortunately, UX is having a different conversation. A counterproductive conversation.  

I can't imagine walking into a room of executives and saying, "This direction is better because of taste.”

The Timeline

The idea that “product owns the What and design owns the How” (or any other permutation of a clear-cut division between the roles) is a simplistic notion that’s been at the heart of the discipline’s downturn. Design grew comfortable with a chain of hand-offs rather than a real product trio and settled firmly into a requirement-taking role whose job was to make the PM’s idea good.  

But because the What is being defined without a real goal in mind beyond “what we can roll out fastest” there is no longer a meaningful “good” to aim for beyond banal 101-level heuristics

“Make it simple” is only one level of abstraction down from “make it really good!” 

As a result, designers who want to distinguish themselves from the 101-level heuristics people but are no longer being fed the principles by which they can do so are turning to a nebulous construct: taste. 

In an environment of ambiguity, taste feels like a refuge. Finally, something that design alone can control. Now that we are no longer beholden to external forces for how we deliver value, things are certain to turn around! 

Hah.

Stakeholders are happy to pay lip service to “design taste” as long as it concerns decisions they don’t care about. But it has no place in how they define value. As soon as “taste” gets in the way of doing more features faster, it has all the convincing power of a gentle puff of hot air.

What’s the Venn diagram of designers who think only they can understand the user, and designers who complain stakeholders always disagree with them?

Guy Segal 

Yes, aesthetics are a unique thing that only design owns. Aesthetics are a powerful tool for communicating something about the product to their audience. Constraining that tool solely to express the designer’s taste is a colossal liability, because it limits what they can communicate and to whom. 

Instead of taste, what Design should be cultivating is a point of view. 

The difference is subtle, but easy to grasp. When you say “no” to a design decision – how do you explain why not? Does your explanation reference the purpose of the decision – is the argument "this is a suboptimal way of achieving your goal" – or is it just "it's not the way I would do it"? Are you adding value with a rationale for why it's the right thing to do for us, right now or falling back on axioms? 

If you find yourself doing the latter, you are solving design problems rather than user problems. Rather than banging the drum of “make it usable” look to see what exactly is making it unusable today for people who are not you, rather than attempting to displace their problems with your own under the cover of empathy. 

That question can’t be answered by having really good taste. It can only be answered by doing real UX. This is the measure of user research impact, worth hundreds of millions of dollars. Worth, perhaps, the value of the company. 

They’ve stopped relying on tactical metrics, such as customer satisfaction (CSAT), Net Promoter Score (NPS), task success rates, or conversion rates. These common metrics seldom provided the UX team with worthwhile insights on improving their users’ experiences. Instead, the team now opts for metrics that map closely to their subscribers’ experiences.

Real research doesn’t just deliver better outcomes – it also delivers them faster. High-quality insights produced by professionals last long past the lifespan of the project, meaning that an investment continues to pay dividends. Real research also provides the context that data – including quantitative data – needs in order to be actually useful.  

Fake research (whether done by humans or AI) might be faster, but it provides none of these benefits. As with most shortcuts, there’s a reason that the road isn’t laid down that way. 

–Pavel at the Product Picnic 

The banner image in the web version of the newsletter is sourced from the incredible USDA Pomological Watercolors collection.