When presenting my philosophy of design organizations, I show this slide: 
 On the left, comprised of 5 robot lions (stay with me…), you have super robot Voltron, Defender of the Universe.  On the right, 5 unicorns. The unicorns refer to the “design unicorn” a designer skilled at interaction design, visual design, and front-end development. They’re “unicorns” because some believe they don’t exist, though others are betting that they are very much real. For the sake of argument, let’s say that design unicorns are real.
My concern is that all this talk about unicorns, on thus on design at the level of the individual, is misguided, and potentially even harmful to design as a field.
Companies want a unicorn because she can be the lone designer on a product team, working with product managers and engineers to deliver features. On the face of it, this seems great – you get a lot of bang for your buck.
However, in my experience, design is best considered at the level of a design team, and the point of the slide above is that a coordinated team of 5 designers (of varying skill sets) can out perform 5 identically-skilled unicorns working in isolation.
When I joined Groupon, product designers primarily acted on their own in product teams. And what I saw is that the scope of their efforts was quite constricted. When you’re asking one person to deliver interaction design, visual design, and front-end code (or at least something prototyped), it leads to designers focusing on narrowly defined features — a single web page, or augmenting an existing flow.
Among the first things I did as VP of Design was relax our requirements for product designers. They no longer needed to be technically savvy, and, they could have an emphasis in interaction design and IA or in visual design.
And much of my own initial effort was on hiring strong design leads — directors and senior managers. This turned out to be key. About 9 months into my tenure, I organized the 40-plus person Design Union (what we called the whole design team) into a series of teams, each with a lead. This proved transformative not just for design, but the for the company. With these teams in place we could deliver on larger scale efforts like Groupon’s first-ever website redesign (a prior effort, before I had joined, had failed), or DealBuilder, a self-service tool for merchants to launch a deal.
Another short-coming of focusing on design unicorns is that it reduces design to an execution function (I’ve written about definition and execution in my post and presentation on The Double Diamond.) Approaching design from the orientation of teams, with strong team leadership, not only allows designers to tackle broader problems, it also enables them to move “upstream” into the decision-making behind product definition.
Team Structure
Through experience, I’ve arrived at a sense of what seems to work for the structure of design teams (again, these are teams within a larger design organization, not the whole organization itself!).
Teams should have 4-7 members. Any larger than that, and team coordination gets unwieldy.
Teams require strong singular leadership. This Team Lead role is perhaps the most challenging in the whole design organization (even moreso than a VP of Design). The Lead must:
- Manage down – getting the most and best out of their team
- Manage across – collaborate with cross-functional partners
- Manage up – presents to executives and other stakeholders
Pivoting between detailed delivery within your team, coordination with peers in product, engineering, and marketing, and communication to executives can induce a kind of whiplash that not everyone can handle (in fact, I would say it’s rarer than the ‘design unicorn’). But if you find folks who can handle this successfully, your design organization can be surprisingly effective.
These teams should be organized around business problems (supporting a line of business) or aspects of the customer experience, not by function (interaction design team, visual design team, etc.)
And within these teams should be located a spread of skills — user research, strategy, planning, interaction design, information architecture, visual design, and prototyping. And this suggests another reason to Think Beyond Unicorns, as no one could be expected to excel in all of these areas. Instead, hire folks who excel at a couple of these but can productively collaborate across all of them. (I’m not in anyway advocating the hiring of single-minded specialists.)
There’s an alchemy that happens with great design teams, where the whole is greater than the sum of the parts. My understaffed teams were able to deliver far more than could have been reasonably expected because they could leverage their team-ness for greater effectiveness.
When I next write about teams…
Something that I’ve realized is that the ideal level of scope for a design team is different than that of a product and engineering team, and designers are currently constrained by working within an organization optimized for the latter. When I have time (and after I do some doodling), I want to talk about bridging that gap.
As a so-called “unicorn” I concur that our capacity is extremely limited and is heavily biased toward the low end, because one “unicorn” will never cost as much as one full-time senior designer and developer each—or if they do, the client/employer has enough money for those other players anyway. Moreover, people seem to forget that you cost an order of magnitude more than an intern, and are content to saddle you with intern work, which is a net liability for everybody.
Where a unicorn (and by that I mean can sling a product end-to-end) is genuinely useful, aside from startups and charity work, is any place where the communication has to happen intracranially, because it’s too fuzzy to translate into language. I’m the first to admit, though, that I don’t have nearly the stamina of even a small team.
As the maxim goes, however, many hands make light work often, but they make more work always. So yes, work has to be partitioned and communication has to be trunked the bigger the team gets (cf Mythical Man-Month; and 7 is a reasonable upper bound). Plus you also have to be able to afford to pay people to sit idle if they’re waiting on another person, as well as pay for the process of negotiating new conceptual structures and task decomposition/interfaces (cf http://mitpress.mit.edu/books/cognition-wild, Chapter 8). But you probably know all this better than I do.
This is an approach that’s been working for me for the last seven months.
A team of four people who have individual specialist skills (user research, strategy, interaction design, visual design front end coding). Nobody is solely responsible for any one things. It’s up to the individual members of the team to do things that add the most value, be that building a design in code or exploring a design route.
I think of this as a team of unicorns. But all unicorns look different.
With time skills cross pollinate and peoples’ skills grow.
Thanks for this article, it articulates something we have been thinking about and trying to implement within our own design organisation. Something else we’ve been pondering is “what is the role of external providers for mature in-house teams?”. I’d love to hear your thoughts on that.
…or to phrase it another way: what does a good engagement model look like between mature in-house teams and external design agencies/consultants?
I don’t really have experience with that, at least not from the in-house perspective. At my two in-house jobs, I was discouraged from using external agencies (for reasons both of price and developing intellectual property).
I wish I had this article a few months ago. This is really close to the model of a team I’m building right now. Everyone has a superpower, but can collaborate. Extremely powerful stuff.
I really like this Peter. Back when I was running end-to-end teams I kept a spread sheet with all team members and about 8 skill areas that had a 1 to 10 scale for capability in each skill area. I was essentially ensuring I not only had all areas covered across 9 to 22 staff (depending on time) to ensure there was not only skill but back-ups. I could move the team around for projects or different stages in a project life cycle to get the best result. This also helped me plan for the eventual need to replace team members. I ensured there was a lot of cross training and people could learn and improve areas of interest (usually if they helped others learn their strengths). But, this cross training and heavy mentoring improved each of the team member’s value and earning capability. I figured I would lose one or two a year to get a large bump in pay and the spreadsheet always came in handy when sorting what the new addition to the team could look like as far as skills. Word also got around and there was usually a healthy abundance of great candidates to choose from to add to the team.
I often miss running teams and projects / product / programs (multiple projects and programs rolled under me). Doing this takes good management skills, but more importantly good management tools.
I did the same thing as Thomas. Used a spread sheet to create a star diagram that alouded me to see both whole team strength and weakness individuals. Personally I see there are advantages to have T-shaped people on the team, balance of skills but with specialisms.