Why hire more designers?

This was first published on my mailing list The Looking Glass. Every week, I answer a reader’s question.

Photo by Rich Savage

Why hire more designers?

I’m working on getting buy-in to hire another designer and a researcher for my company, I’m currently a design team of one. Other than designer:dev ratios, do you have other ways for justifying increasing Design’s headcount?

I hear questions like this from time to time. Sometimes there’s already a design team, and the question is when or whether to hire more. Another variation is from startup founders, who may plan to hire a few engineers first to get their products off the ground, but aren’t sure at which point to hire a dedicated designer.

Let’s start by understanding what designers are uniquely good at, which should shed light on whether bringing one or more designers onto the team is a good idea.

Designers make products easier and more pleasurable to use. This is generally pretty well-understood as one of the unique values that designers bring to a team, but it’s worth talking about here because if your product doesn’t compare well against similar products on the market when it comes to usability, or if you’re looking for a competitive advantage on that front, hiring more designers strengthens your position. And make no mistake, this can be a huge competitive advantage. Many a first-to-market product has been beaten with comparable functionality dressed up with a better user experience, for example smart phones existed before the iPhone, traditional taxis existed before car hailing services, etc.

Designers help you visualize your future vision. If you want to communicate what your product might do in a year or two’s time, you can either tell people through words, or tell them through visuals. This is the superpower of a designer — they can take abstract sentences and concepts like “we will revolutionize collaboration in the workplace” and show how it works, which as many a writing teacher or film director has taught, is way better and more powerful: Show, don’t tell. Furthermore, designers are generative — given specific people problems you’re trying to solve, they can brainstorm and create potential solutions and show how those solutions might work. As a result, if your team is only iterating on your product in incremental ways on three month sprints without a clear understanding of where you’d like to be in a year’s time, this is fertile ground for a designer to help change the equation. You need people to balance out short-term thinking, take a step back, and look further ahead to the bigger bets that could result in step-function gains and will require throwing away the assumptions/constraints of what you can build in a few weeks or months.

Designers help you think in terms of people’s experiences across the whole of your app or system, not just sub-components. Most companies tend to structure their product teams around individual features or product goals, which makes sense because you want one engineering team owning the code for each part the system — it’s tough to manage when four or five different teams all want to muck with the same code stack. However, this needs to be balanced with perspectives that are more holistic. Your users do not look at your product in terms of your individual orgs. They do not realize that a separate team owns the sign-up and NUX flow than owns the notifications feature. In their head, the product is one experience and it should work seamlessly from when they decide to give it their attention to when they put their device away. This holistic, user-centered view is where design (as well as research, analytics, marketing, communications, etc) plays a strong role. In most tech companies, design tends to operate more centrally than PM or engineering. This diversity and intentional push-pull creates better outcomes. Designers help can spot issues like:

  • When experiences become too complicated because everyone is inventing their own way to do something versus trying to find common patterns of interactions
  • When there are confusing gaps in the end-to-end experience of someone traversing multiple features.
  • When you’re too focused on a certain niche subset of users (like power users), and neglecting new potential customers who don’t yet understand your product as well.

A side note on “ratios”: As a tool, designer:developer ratios are pretty blunt. When zoomed way out at a large scale, it can be a reasonable sanity check how well the company aligns to software industry peers. e.g. “With these 2,000 engineers we have, about 300 designers puts us in the right range” (at a high-level, 7:1 is reasonable.) However, anyone adhering to a golden ratio without digging deeper is liable to miss the mark. When looking at each sub-team, a major factor is how much the team is focused on user facing products, and whether the work is largely expected to be iterative (variations within well established patterns) or innovative (new functionality without a basis to draw from). On teams I’ve managed, the ratio of designers:developers can vary as widely as 1:2 to 1:10. We have something similar to 1:2 on the team building design tools (where the designers are themselves quite technical, they need to have expertise in their “clients” which are other designers, and the products are largely new feature development.) We have lower ratios on teams that are backend-heavy, where huge swaths of engineers work on ranking and machine learning. As a rough rule of thumb, I look at how many front-end or UI-facing engineers are on the team, and then figure something like 1:3 or 1:4 designers to those engineers. Again, emphasis on the rough part. The right answer takes into account the problem to be solved, how much the designers code or don’t code, how design-minded the front-end engineers are, and additional factors like the skills and output volume of the existing team members.

A side note on the risk of having designers work alone: For higher design quality and productive, it helps to have more than one designer working together on a product. This may seem counter-intuitive, and defy the mythical man-month, but I’ve seen enough examples of 1 + 1 = 3 with designers to advocate strongly for it. Why? The reason is simple: designs rarely emerge fully formed. They rely on a process of iteration, with new inputs helping to support strong outputs. An important source of constructive input is critique from other designers. Designers working alone miss out on other people challenging them, pointing out ideas they might have missed, and collaboration so you get the strengths of multiple designers. Even without headcount constraints, we often prefer, instead of dedicating 1 designer 100% to a single project, resourcing 2 designers 50% to two projects. This will often yield higher quality work faster than a single designer working 100% and ensure that work on a team doesn’t grind to a halt if a designer happens to want to take vacation, or is out sick for a few days.

Despite being an advocate for design thinking and strong believer in the value that designers can bring to teams, I’d be providing bad advice if I simply told you to “hire more designers.” There are situations when a designer when would be a great addition, and situations when another designer isn’t what’s needed.

Think about how the above situations and unique capabilities of designers may apply to you, and if you do decide to grow the design team, I wish you the best of luck with hiring!


To ask a question or follow along weekly with more Q&As like this, subscribe to The Looking Glass mailing list.