Hiring the Right Shape of Designer

I've noticed a worrying trend in the last year, where there have been fewer designer roles inside the broader civic tech landscape than perhaps at any point since the earlier days. Having done a lot of designer hiring over the past decade, no organization is immune to justifying roles and their headcount.

Just so we're aligned, I talk a lot about service design, and define the craft of service design as thinking less about screens and all about outcomes. What does ideal state look like? Service design is thinking about the intersections of interactions, from policies, handoffs, incentives, constraints and most crucially, human interactions that can cause problems well before (or after) anyone has designed anything.

Good example: You think the solution to a problem is building a better app to solve a particular bottleneck, but a forward-deployed service designer is able to observe, ask questions of users, setup tests at each milestone that help your team uncover that the problem isn't in the technology, it's confusion somewhere else inside the process.

How to hire the shape of designer for the shape of your problems

There are increasing number of Designer-Engineer hybrid roles, Product Designer are still around because people value craft aspects of the work. But AI encroaching on the territory where designers once worked, a lot of teams are going without skills and perspectives that designers bring to a room. Content design roles are shifting and have been for a while, but a better understanding of the value of information architectures would provide a boon for that right now, and despite millions of people the world typing into chat interfaces every minute, product teams don't seem to know how to scope and build the right positions and it's showing downstream in product deployment.

Too often, we designers -- content/information architecture, service designers, UX researchers -- find ourselves on projects where the scope doesn't seem to match where users are.

Service design has always felt underrated precisely because its impact is upstream of the interface: it shapes the questions teams ask, maps the system around the user, exposes constraints within an org, and often reveals that the right solution is to redesign the service rather than the screen. This can be both easier or harder, depending on the situation, but in both cases, service design can help teams unlock key questions that might otherwise go unanswered. As AI makes interface production cheaper and faster, those systems-level capabilities seem even more valuable.

Service design as the forward-deployed role of your dreams

You might be thinking, "Can't we just use AI to answer those questions that designers were going to?" Maybe. It's not so much about the questions though.

Having spent the past year managing multi-agent AI teams, I've learned that production quality is only as good as your understanding of the problem you're trying to solve.

Even with strong domain knowledge, if you don't know the stack you want to built atop, if you haven't deal with 1000s of hours of users, or experienced different shapes of problems, your team will often miss otherwise obvious things. Increasingly, teams seem reluctant to ask questions because they're afraid of slowing momentum, but the risks of wasting cycles (and tokens) on cheap, half-baked solutions is even worse than the era of too many memos.

I'm biased -- I scaled a service design practice from the ground up -- but I think too many leaders are ignoring the broader contributions of designers outside of craft. Yes, lots of designers care a lot about how things look and feel, but there's more to the role than just aspect ratios. I'm not even talking about content. It's been funny to think how we're surrounded by tools that generate lots of content, but content folks are less valued now than ever. I thought for a second, that (regardless of your feelings about it) that prompt engineering was the backward to get content strategists and information architectures onto AI product teams. But alas, that was a mirage.

The forward-deployed craze at is core is just identifying how to get the expert embedded closer to the front lines of problems and using those skills to help the domain experts in the problem space, be better able to leverage technology or a particular set of tools to unlock, break through and tackle value faster; including unblocking problems.

What do I do with a service design when I can't fix the service?

A lot of criticisms of service design have less to do with the practice, and more to do with how orgs hire for it. It's easier to fix a screen, improve a metric, and research short-term than invest in the longer term outcomes. People think overresourcing on roles like service design somehow takes away an FTE from bigger problems. On the contrary, good designers can be deployed to work outside of the traditional domain of design when craft work is slow, it just takes optimizing for those kinds of designer-leaders.

A service designer can do everything a product or program manager does, the reverse is much less common. The Designer-Engineer hybrid seems easier for people to make sense of, but the Designer-as-PM thing seems harder for folks to understand.

Lots of designers leave design to get this role shape, but I'm arguing it's not always necessary -- or advantagenous -- to abandon design. The player-coach phenomenon tries to touch on this, but wastes good designers having them manage in orgs where the role often lacks empowered (design) leadership, which creates bad incentives for anyone who might want to grow in a product-centric way.

Part of why I've written so many blog posts over the past few years trying to reframe design, has largely been about scope, authority and understanding. It's almost as important to develop designers sense of communicating ideas, as much as helping non-designers be able to recognize that you don't have to silo designers into narrow roles.

The biggest story here is so many problems start and end with not having designers in the room able to ask critical questions at the stage when we're developing problems, constraining scope, identifying features, and deciding on which way we'll go.