Being anything but a designer: the work between seeing the problem and solving it

Ron Bronson, who was a Head of Design 18 months ago, writes in this piece that he has spent the past year trying to be anything but a designer. His starting point is that the AI era has not been kind to the human-centered designer, especially one who does not work at a large company. The article is a personal reflection and includes no data or studies. What follows summarizes his ideas as he presents them.

Bronson links this reflection to two ideas he had already developed: "Forward Deployed Design" and "Design as Repair." The latter, he says, grew out of a desire to close the gap between how we detect problems and how they actually get solved. He sums it up with a question: what good is seeing the problem clearly if you are still too far from the part of the organization that can make it stop happening?

His frustration with current debates, whatever the sector, is that they place the technologist (engineers, strategists, managers, "transformers") at the center of the solution rather than the people we supposedly care about. Having spent much of his career working on public-interest problems, he argues that this has a strong downstream impact. He makes clear that he is not content with asking questions or locating where the impact is, because that is merely the minimum. He asks how often we can point to successfully implemented practices that prevent the same mistakes from recurring, so that no one has to solve the same problem twice because processes build resilience.

Under the heading "Being an organizational sponge," Bronson disagrees with those who write that AI will favor generalists, meaning people who handle many areas rather than mastering one. He believes the outcome will vary greatly from case to case. He recounts that someone told him last year: "I don't know how to explain what you do. I know I saw it, but I struggle to put it across." That bothered him at the time, and he needed time to come to terms with it.

The author says he spent six years managing designers, four of them as the person ultimately responsible for hiring, promotions, timesheets, travel, training and budgets, as well as overseeing the practice as a whole. On reflection, he concludes that the role was a mistake. He notes that it is easier to lead when the company ships a recognizable product. When you manage 40 people and the work affects millions of people and tens of millions of dollars, there should be plenty of stories to tell. But some work does not fit into clean narratives.

According to Bronson, some organizations have people who are very good at absorbing mess: customer complaints, workflow failures, organizational contradictions, bad interfaces, broken processes, implementation gaps and conflicting incentives. They are the ones called in for tasks that supposedly "only they can do," and their reward is feeling useful. Losing that role is destabilizing, because you have to show people all over again how useful you are in so many contexts. It is work that is not well paid, has no title and depends heavily on context. He says these people exist at every company. It is sometimes called "glue work," but he believes there is a bigger story and plans to explore it over the coming year.

In the section "Not service design, not CX, a secret third thing," Bronson, a veteran service designer who built an entire practice and taught it to undergraduates, says he has firm views on where service design falls short. He feels the same about the broader field of "customer experience" (CX), which he finds problematic in the public sector because it assumes the public are customers, a premise he does not share.

He also warns that AI threatens to push product impact even further away from customers. He compares it to the sports debate between analytics and the "eye test" (direct observation): metrics such as NPS can end up replacing a real understanding of customers' pain points.

He sees some value in the forward-deployed design role, especially when combined with complementary roles on a product team. But he calls for deeper inquiry into several questions: how product teams stay close to the people affected; how research and customer insight remain connected to implementation; how organizations build capabilities instead of relying on heroic individuals; how AI's technical leverage changes who can prototype and intervene; how CX and service design move from identifying problems over and over to eliminating their causes; and how organizations learn from their interventions so they don't solve the same problem twice.

His conclusion is that the answer is not another heroic generalist slipping into every organizational gap. The underlying question, he says, is how to give teams enough capacity to better understand customer needs and to experiment technically and deploy iteratively, without assuming a single role can do it all well. That would require a mandate to take edge cases seriously, product teams that value qualitative evidence alongside metrics, tracking of recurring pain among customers and frontline staff, and giving those who understand these patterns a path to change the conditions that produce them.

Bronson says he is now less interested in figuring out what to call himself and more interested in talking with other problem-solvers to see where one needs to sit to tackle consequential problems. With AI changing how products are deployed, imagination will be needed about the roles created to address problems across the entire product stack.