Ask the Experts: Who Owns Design?

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.

Share on twitter
Share on facebook
Share on linkedin
  • Paul Young oversees the strategic development of Pragmatic Institute’s portfolio of products and leads the executive team in the evaluation of new product opportunities. He also manages the instructor team. Paul began his career as a software developer and has worked in startups and large companies across B2B and B2C industries, including telecommunications and networking, IT and professional services, consumer electronics and enterprise software. He has managed P&L lines for products with hundreds of millions in revenue, and faced difficult choices about which products in the portfolio to retain and which to kill. Reach him at

Related Content

Black Box Feature Image

From the “Black Box” to the Sandbox: Advancing Product Management and Design Collaboration

For product and design teams, a “black box” understanding of each other’s functions can create problems like poor communication and lack of trust, resulting in inferior products. Pragmatic Institute’s design practice directors explain how both groups can move into the sandbox: a space to build new things together. Learn how an intentional approach to collaboration will help you improve product quality and your team’s efficiency in achieving market-winning, delightful solutions.


Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Stay Informed

Sign up to stay up-to-date on the latest industry best practices. Get content such as:

    • The Pragmatic – Industry insider magazine
    • The ever-growing webinar series 
    • Our world-class podcast series