On Being Anything Other Than a Designer

1 October 2026

The Work Between Seeing and Fixing

I’ve spent the last year trying to be anything other than a designer. 18 months ago my title was Head of Design. I’ve written about Forward Deployed Design and how it’s crucial to think about the people impacted by the work. But the AI era has not been kind to the human-centered designer, especially if you don’t work at a massive company.

  The whole idea around Design as Repair was borne out of a desire to bridge the gaps between how we spot problems and how we actually solve them. “What good is seeing the problem clearly if you remain too far away from the part of the organization capable of making it stop happening?”

My frustration around the debates of right now — regardless of your sector — is we’re centering the wrong stories, the wrong people and the narratives that place the technologist (engineer, strategists, managers, transformers) at the heart of the solution rather than the people we purport to care about. Having spent the bulk of my career working on public-shaped problems, this has a massive downstream impact. I’m not talking about just asking questions, because asking questions and finding out where there’s impact are just the bare mininum of what we can be doing.    I’m asking when we contemplate innovation and methods of operating, how often can we point to successful implementation of practices that stop us from repeating the same mistakes, and let us get down to the business of solving problems that we don’t have to solve twice, because our processes instill a resilience that doesn’t force us to go backwards over and over again.

Being an Organizational Sponge

The AI-era has caused a lot of people to write about how generalists are going to benefit from an era where it’s less about knowing one thing and having dexterity in a lot of different areas, but I think your mileage will vary considerably.

I remember last year, I was talking to someone and they told me something that actually bugged me at the time, but I had to really marinate on what they were saying.

“I’m not sure how to explain what you do. I mean, I know I saw it. But it’s hard for me to convey it.”

This goes back to our whole “I’ve been trying to outrun design,” thing from earlier in this post. I spent 6 years managing designers, and 4 of them as a final decision maker over hiring decisions, promotions, approving timesheets, travel, training requests and budgets. Not to mention oversight for the broader practice and making the call on all manner of things. At the time, I was just living through the day-to-day, but in reflecting, the role was a mistake. It’s a lot easier to be in charge when your company ships a product that’s recognizable. When you manage 40 people and your work impacts millions of people and tens of millions of dollars, you should have lots of stories to tell. But some work doesn’t lend itself well to neat narratives.

In some orgs, there are people who become very good at absorbing mess: customer complaints, workflow failures, organizational contradictions, bad interfaces, broken processes, implementation gaps and conflicting incentives.

There’s that person in your job who is the one people call for all kinds of tasks that only “they can do,” and the reward for people this is just feeling useful. When you lose that role, it can be very destabilizing because for one, you have to teach new people all over again how useful you are in all these contexts.

This job doesn’t pay well, it doesn’t have a title and it’s extremely context dependent. Through the past year or so, I realize these people exist in every company. Sometimes, it’s called “glue work” but I tend to think that there’s a bigger story here and I’m interested in probing it over the next year.

Not Service Design, Not Cx, A Secret Third Thing

As a longtime service designer who has spearheaded an entire practice and taught it to undergrads, I have a strong set of firm beliefs about what service design and where it leaves a lot to be desired. I also feel this way about the broader field known as “customer experience,” which in the context of public sector work leaves a lot to be desired because it assumes you think of “the public” as customers. (I do not.)

The AI era threatens to make the relationship between product impact, and customers even more distance because akin to the conversation people in sports are having around analytics (versus “the eye test”) mirrors the disconnect in product/customer segments where NPS and other metrics can somehow substitute for actually understanding customer pain points.

I think the forward-deployed design rolecan have some usefulness here, especially paired on a product team with complementary roles, but I think there needs to be some deeper inquiry around how product teams stay closer to the people affected by their work:

• how research and customer knowledge remain connected to implementation;

• how organizations build capabilities rather than depending on heroic individuals;

• how technical leverage from AI changes who can prototype and intervene;

• how CX and service-design practice can move from repeatedly identifying problems toward eliminating their causes;

• how organizations learn enough from interventions that they do not need to solve the same problem again.

I don’t think the answer is another heroic generalist whose job it is to Gumby into every organizational gap. The bigger question is “how do you build enough capability into teams to better understand customer need, and where you can still experiment technically and deploy iteratively without suggesting there’s one role that can do all of those things well.

This would require is having a mandate to take edge cases seriously, to build product teams that value qualitative evidence alongside metrics, tracing recurring pain across customers and frontline staff, and giving the people who understand those patterns some path to changing those conditions so they’re not a forever problem.

I’m less interested in resolving the “what do I call myself,” question now. I’m more interested in having discussions with other problems solvers to figure out where we need to sit to tackle consequential problems. With AI continuing to change how we deploy products, it’ll require having imagination about the roles we create to address problems across the product stack.