One of the most frequent questions I receive is “Who owns Design?” Should the designers report to the Development or Engineering team, should they report to Product Management, or perhaps Marketing? Or, should Design be its own group? The answer might surprise you.
Before we can define where Design belongs in an organization, we must first define “Design.” There have been dozens of books written on this topic and the debate will continue to rage online long after this blog turns to dust. For now, let’s turn to “Paul’s Pragmatic Definition of Design”
“Design is the role in a team that understands a market problem, and comes up with a solution to that problem.”
It’s doesn’t have to be harder than that. To determine where Design belongs, lets examine whom the Design primarily works with on a day-to-day basis. Design works sits as the middle layer in this diagram:
Typically Product Management is responsible for the top layer of finding and quantifying the markets’ problems. Development is typically responsible for the Build layer of bringing the designed solution to life.
However, to make this picture more complex, Design doesn’t mean just one thing. At a minimum, there are two flavors of design:
Front-end Design, and
Back-end Design
Front-end design is what most people mean when they say “Design.” The titles found in front-end design include User Interface, User Experience, Human Computer Interface (HCI), and Human Factors Designers – all titles found predominantly in software projects. But front-end design is not limited to software.
Front-end Designers in hardware applications are concerned with ergonomic design, user fatigue, eye level, placement of power cables and interfacing to larger systems – such as how a server might mount into an equipment rack. In services, a front-end designer might think about how many key presses a user must make on their phone when they call into an interactive-voice-response system before they can talk to a human.
Back-end Designers are often called “Architects.” In software, they are typically concerned with items like choice of codebase, code re-use, selection of libraries, how to build a system that is both scalable and secure, and whether to use Amazon EC2 or another cloud provider. In hardware, they might choose the clock speed of the processor, or how much memory overhead needs to be planned for in the system for future upgrades.
Design is measured differently than Product Management and Development. We teach that Product Management should be measured on its ability to be market-sensing. That is, members of the product team should be measured on their effectiveness at bringing accurate market data into the business to feed better decision making. Development is often measured on a combination of scope, time, and quality. Design is not measured using these metrics.
How to effectively measure a Design team is a large question that incurs significant debate. But, suffice it to say that designers have their own set of metrics to test the effectiveness of their designs. For Design, measurement needs to answer the core questions: “Does the design effectively solve the user’s problem?” “Does the design fit into their daily life or workflow?” “Does the design act in a way the user expects it to act?”
The bottom line is: Design is a huge role, encompassing a wide variety of areas. It’s very rare that one person highly skilled at both front-end and back-end design.
TL;DR, Just Tell Me Who Owns Design!
In my experience, back-end design almost always reports to Development. Because of the intertwining technical nature of the decisions these Architects are making every day, it makes sense that they would sit within the reporting structure of the team creating the solution.
Front-end design is a very different answer. In the past decade, front-end design has migrated, from reporting to Development, to reporting to Marketing, to Product Management, to their own group. Sometimes, they are contracted resources that report to whoever hires them.
Like Product Management, there is a natural tension that exists between front-end design and the Development (and Marketing) teams. This tension arises from differing (sometimes competing) goals and different measurements of success. Typically, this tension is a good thing. However, when we subsume that tension and shove front-end design under Development, or Marketing, the tension resolves in favor of the executive who owns that team. For instance, a Development team who owns Design and is measured on “hitting the date,” will naturally pressure its designers to create designs that help them hit their date. This is probably not conducive to good designs for the user.
So who owns Design? The designers, of course. And who owns the designers? I believe that the goals of Product Management are highly aligned with Design, so I can easily see these reporting up the same structure. I can also see success for Design as an independent part of the Product Team.
Wherever you place Design in your organization, ensure that you have an honest conversation about how designers are measured. If you measure Design like Development or Marketing – the results will be sub-optimal.