- The Product Picnic
- Posts
- Why design goes wrong and how to set it right, part 1
Why design goes wrong and how to set it right, part 1
At the root of design's crisis is an incentives crisis throughout tech. But we have tools that let us cut through the magical thinking of feature factories - if we're willing to use them.
Hey, picnickers! This issue is going to be slightly different - a two-parter - because it was running quite long.
Reading Material
UX is having a crisis of meaning. Fabricio Teixeira has wrapped up the last-ever UX Collective “State of UX” on a sad note. Erika Hall predicted this in 2018. In 2022 we still talked about delighting the user. Now we are struggling to achieve neutral quality.
User centered design was/is/will be hard. Centering on widgets and processes is easier. Product is a retreat from the future.
Even design systems teams - for years the darlings of the field and the place where design has been able to entrench its influence even as it was being kicked out of other rooms - are demoralized. Designers never locked down the ephemeral influence we seemed to achieve in the 2010s; whatever changes we won have quickly become reversed with design retreating to the role of “look and feel” under the guise of new terminology.
Unfortunately, design work does not exist in a vacuum, but in the social system we call “work.” We focused on craft over change management and missed the trick when it came to refreezing. Now we are back where we started, or possibly worse, depending on how you look at it: the products of the past may have been clunky, but at least they did what they were told.
Designers will say: that’s not my fault, the product manager made me do it. I don’t want to sit in meetings, I just want to do good work that speaks for itself.
Well, that’s how we got here in the first place.
The Timeline
The joke about explaining water to a fish has never made sense; fish can feel the current of the water and see it carrying debris and food. So too can you make out the currents of the industry by looking at the ripples in its wake.
Those ripples show a reorientation from “design for use” to “design for sales”. And in that paradigm, the salespeople become the customers; design is not seen as a way of understanding what people want, but a delivery function selling feature checklists to stakeholders, with quality a secondary concern.
There is an ocean of difference between “good” and “good enough”.
Rather than using research to understand who we are building for, our orgs have been setting course based on the ideal user they’d like to sell to: one who simply wants more features. Despite that approach visibly failing, companies continue to ship solutions to made-up problems because the systems to discover better ones are no longer in place. Instead, teams are told “hey you - innovate!” with predictably sad results – burning trust with stakeholders and users on blind iterations.
Making really good, easy to use software is hard and requires solving tricky coordination problems in organisations. Almost nobody is incentivised to do that.
Because incentives have been suborned, the entire feedback loop of design falls apart. Without the user as the touchstone for quality, “data-driven” decision making has fallen to p-hacking test results. Teams are asked to lie to themselves about the value of their work by embracing these fake metrics, which further drives down both quality and morale. And instead of doing better, those so-called leaders respond with draconian employee metrics designed to crush talent rather than nurture it. People trying something different are demonized by managers whose understanding of the work begins and ends with “best practices.”
I’m going to dive deeper into how to set design teams back on the right track in the next issue, but it all starts with correcting this delusion that design can stay in Figma and simply build what comes to mind for “validating” later. Which means, of course, starting with user research.
Unfortunately, many designers (not to mention product managers and developers) aren’t trained researchers. And even if you are, you might not get very far if your team doesn’t at least have a slight understanding of what it is you’re doing. When it comes to getting beginners up to speed or to pros checking their work, I’m a huge fan of checklists. And one of my favorite checklists is the PACT Analysis question set. It’s the perfect tool for a designer when they are on their shakiest footing — just poking their nose into a new domain and not even sure of what questions they should be asking.
For a broader checklist of the “bridge processes” of design (the things you do in between the pixels) Scott Jenson has put together GIST. It’s a nice tool for making sure you’re asking the right questions, and equally useful for sending to your cross-functional partners so that they can understand there are more steps involved than “read ticket → open Figma.”
Diagram of the Week
One of the most common pitfalls of “build measure learn” processes (aside from forgetting to do the latter two steps) is iterating on the wrong dimension of the experience. Two of those many dimensions are wonkiness (mental model mismatch) and jankiness (poorly executed interactions). When users don’t like the UX or can’t complete tasks in the tool, it’s critical to understand why. The cure depends on the disease.

Trying to reduce the jankiness of a system won’t help if the problem is that it’s wonky, and vice-versa.
Join me next week for Part 2 of this train of thought, on how to make our process more robust against the broken feedback loops of the industry.
— Pavel from the Product Picnic