Productive friction
When production friction went down, our opportunity for productive friction went down with it.
Generative models reduce production friction — production... the actual building... isn't really much to consider any more. But when production friction went down, our opportunity for productive friction went down with it. I talked about this in my presentation "Accessibility & Inclusion in the Age of the Builder".
Two kinds of friction
There were always two types of friction in the process. The first is production friction, the effort it takes to build the thing. In the before times, it might take 6 to 12 weeks to get a rough design together, prototype, and get that in front of someone to run an experiment and get feedback. Maybe more, maybe less, but it was NEVER as quick as it happens today. Now we can get things out there in a day, run an experiment, and get the feedback we were after.
The second is productive friction. Also in the before times, we'd collaborate to make it happen: researcher, designer, engineer, product, tester, content and more. The process involved sketches, wireframes, mockups, prototypes, and eventually a working version worthy of testing. That process, while slower, allowed for discussion, debate, prioritization, disagreement, compromise, and eventually alignment on the direction.
That's what I like to think of as productive friction. Productive friction is friction with a purpose: it's useful, and it helps us create better things. It's how we get crystal clear on who we mean when we talk about inclusion. It's how we find the flaws in our own thinking.
What we lost when the process shrank
Each one of those artifacts was an opportunity for us to review, to think, to encode our intent on what we wanted the design or the product to actually do. We had many touch points throughout the process that encouraged us to think about accessibility, and despite the messy process, we had lots of chances to get it right. Now we have one builder, and they are taking on pretty much every role. When we used to have five people that might advocate for accessible solutions, it's now one.
Rushed decisions are bad decisions
Think for a second: when do you make your worst decisions? Your absolute worst decisions? When you don't know what you need to know, and you're rushed. Pressure to ship used to be going from 12 weeks down to 10, and now it's going from 12 weeks down to 2. When we're rushed, we tend to make bad decisions.
Getting productive friction back
My natural instinct was to introduce the debate into the AI's process, and I've been doing that. I've been using adversarial reviews, skeptics and hardline devil's advocate stances to engage in that debate. But that's the same as outsourcing the most important part of the work that we should be doing: the judgment — the deciding, the friction, the debate. We cannot outsource all of our judgment to LLMs.
Here's what I've found instead: poor drafts from an AI are a massive source of productive friction. A poor draft gets something out there for me to react to, to be enraged by, or to simply correct, and the argument still happens in me.
Mix the roles
In 2012 I wrote about the same problem in Web Accessibility: transitions and process. When we were doing group exercises, I encouraged participants to talk about the problems we were trying to solve with someone that wasn't the same as them. No groups should be just designers, or just developers or just any one role. That still holds, and we need to build judgment in every single person that is doing work.
Where does the debate happen now?
Where does the argument and debate and disagreement happen on your team now? Where does it happen when teams are becoming "a collection of solo builders"?