Welcome back, picnickers! This is going to be another one of those “thinking about the intersection of two themes” posts. Both are themes that I’ve explored extensively in the past:

Add those two together, and the thesis writes itself: the friction of a process is a valuable constructive constraint. Thoughtlessly eliminating friction from our process does us a disservice, doing so makes us less effective rather than more.

If you want to hear more on this theme, join me at the IAC in April:

But here are my initial thoughts on why (and how to) bring helpful friction back into design.

LLMs are the elephant in the room here (although this should not be surprising, as they are the elephant in every room right now, and we will not dwell on them too long).

AI tools are the poster child of the “just go faster, at any cost” crowd. And we see just what costs proponents are willing to pay: taking the computer’s word as the truth rather than the mere outcome of statistics, and then inventing falsified post-hoc justifications to back up the AI’s guesses and assumptions.

Users of these systems become reliant on getting one quick and authoritative answer; they lose the ability to evaluate the quality of that result, and the output of their work reflects that:

It is one thing to read a fact and memorize it — and entirely another thing to connect it to other facts, draw a conclusion, and become invested enough in that conclusion to advocate for it in a persuasive manner. In order to meaningfully understand and use new information, it is essential to linger.

We are now going to stop talking about AI, and come back to talking about product development. Because the reasoning behind AI being thrust into everything — go faster or fall behind, adapt or die — echoes the arguments used to “optimize” that process, reorient towards a mode of thought driven by product needs rather than user needs, and turn designers from system thinkers into technology implementers.

Interestingly, the designers who chose frictionlessness are the ones who are now in a panic because product managers have access to the same AI that scraped the same design systems and generates the same “good enough” screens.

Even an appeal to relevance on the basis of taste is an appeal to friction: stop, slow down, ask me what I think first, wait for me to think about this design and articulate why it’s good or bad. But when the name of the game is velocity, that argument will always fall flat. No one cares. No matter how far you pare down your design process, it will never be faster than doing nothing.

We have to compete on other terms; which means we have to make friction compelling.

The main problem with choosing friction is that it’s easier not to.

It is easier to design the feature in isolation than to investigate what context it will appear in.

It is easier to smear GenAI over everything than it is to figure out whether the bottleneck users face is even technological in nature.

It is easier to let product managers worry about “the what” than to ask difficult questions and then reckon with the answers. It is easier to focus on “usability” over substance. It is easier to align the team around a feature than to dwell in the ambiguity of the discovery process. It is easier to come to a consensus around a solution no one hates, than it is to advocate for one that some might love.

And the path of least resistance has produced some awful design. Because it’s also easier to create “simplicity” by sweeping complexity under the rug, than it is to reckon with making the complex understandable. It’s easier to go for your first cool and clever idea than it is to consider boring but practical alternatives. And unfortunately it is easier to give in to our biases about who uses our product than it is to fight against those biases (and no, you can’t “just use AI” because AI is just as biased as the training data, and deliberately adjusting prompts to account for that is — surprise! — additional friction).

For a while, the path of least resistance served designers very well. Going faster was incentivized, even when the results were poor. Many designers became successful by baking the speed-over-quality ethos into their practice. It is understandable that they are still attached to it.

But the game has changed. “Going faster” now means “going without designers.” And because we did not build our own influence and power (it was easier not to) our attempts to say “design isn’t optional” have withered on the vine.

When design is optional, we cannot dictate to our colleagues what they ought to want. We can only pitch them our services on the terms that they already value, in circumstances where our intervention is wanted and needed.

One of the interesting things about friction in product experiences is that there are two distinct kinds, which we tend to conflate into one. There is the friction of the medium, and the friction of the design. Frictions that are inherent to the material, and frictions that are a result of that material’s shape.

Most attempts to create constructive friction end up being the latter; think about those annoying “are you sure?” popups that never work because in the moment of clicking the button we are sure, and doubts only creep in seconds or minutes later.

Similarly, most attempts to remove friction try and use design decisions to compensate for frictions in the material, which also usually fails. Consider lazy loading (a design decision) which unsuccessfully tries to compensate for throwing megabytes of poorly optimized website at every user (a material friction).

So too is the case with process. Despite the efforts of everyone involved to design a frictionless process, frictions still peek through those design decisions when they result from the material, and the material of process is people.

If velocity was the only goal, then every stakeholder meeting would be resolved in 15 minutes through mutual compromise and camaraderie, instead of the hours, weeks, and months of vicious power struggle that these conversations become in reality.

The main superpower of design thinking was that it let us cut through this Gordian Knot. For designers looking to rebrand as product managers, that skillset remains the best weapon for building influence. But you don’t need a PM title to do stakeholder alignment. If anything, it’s the reverse: designers can successfully pivot into Product because they have this skill.

A table where everyone is agitating for their own super cool idea has extremely high natural friction, and a need to resolve it. A small friction (the design process) begins to look like a palatable alternative. Rather than throw our own super cool idea into that arena (or worse: wait outside the door and try to impose a taste-based veto) designers can take that opportunity to align stakeholders around a shared vision — and place our own thumb on the scales while we do it.

— Pavel at the Product Picnic