This is one of the questions I receive most frequently. Should designers report to development, engineering, product management, marketing or someone else?
Or should design be its own group?
To answer the question, we must first define “design.” Even that has been heavily debated, but for now, let¹s use my definition of design:
Design is the role in a team that understands a market problem, and comes up with a solution to that problem.
At a minimum, there are two flavors of design:
Front-end design. This is what most people mean when they say ³design.² The titles found in front-end design include user interface, user experience, human/computer interface and human factors designers. These are 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. In services, a front-end designer might think about how many key presses a user makes on their phone when calling into an interactive voice-response system before they can talk to a human.
Back-end design. Those involved in the back end are often called “architects.” In software, they are typically concerned with items like codebase choice, code reuse, library selection, building scalable and secure systems and whether to use Amazon EC2 or another cloud provider. In hardware, they might choose the processor¹s clock speed or determine how much memory overhead would accommodate future upgrades.
In both cases, design is measured differently than product management and development. We teach that members of the product team should be measured on their effectiveness at bringing accurate market data into the business to feed better decision making. Meanwhile, development is often measured on a combination of scope, time and quality.
But for design, measurement needs to answer several core questions:
- Does the design effectively solve the user¹s problem?
- Does the design fit into the user’s 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 is highly skilled at both front-end and back-end design.
In my experience, back-end design almost always reports to development because of the intertwining technical nature of the decisions these architects make every day.
Meanwhile, front-end design has migrated in the past decade, reporting to development, then to marketing, then to product management. It eventually became its own group in some companies, and is also sometimes a contracted resource that reports to the hiring party.
Like product management, there¹s a natural tension between front-end design and development (and marketing) teams. This tension arises from differing (sometimes competing) goals and measurements of success. Typically, this tension is a good thing, but when we shove front-end design under development or marketing, the tension resolves in favor of whoever owns that team. For instance, a development team who owns design and is measured on hitting the date will naturally pressure designers to create designs that achieve that goal‹not necessarily conducive to good designs for the user.
So who owns design? The designers, of course. And who owns the designers?
The goals of product management are highly aligned with design, so I can easily see reporting up the same structure. I can also see success as an independent part of the product team.
But wherever you place design in your organization, have an honest conversation about how designers are measured. If you measure design like development or marketing, the results will be suboptimal‹and understanding that is more important than where they sit.
