This was first published on my mailing list The Looking Glass. Every week, I answer a reader’s question.
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!
No comments:
Write comments