Resources > Articles

Ask the Experts: Who Owns Design?

Post Author
  • 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 pyoung@pragmaticmarketing.com.

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.

Author

  • 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 pyoung@pragmaticmarketing.com.

Author:

Other Resources in this Series

Most Recent

The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.
Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.
Article

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.
Article

A Quick Guide to Value-Based Pricing

Value-based pricing begins with knowing the customer’s willingness to pay based on the perceived value of your product. You can charge less than a customer’s willingness to pay, and they feel like they’ve received an

OTHER ArticleS

The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.
Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Subscribe

Subscribe

Training on Your Schedule

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

First Name*
Last Name*
Email Address*
Phone
Company
Job Title
Location
How can we help you?
Preferred method of contact
Privacy Policy*
Map Your Message to Its Audience with the Communication Compass
Map Your Message to Its Audience with the Communication Compass
Ensure your message hits the mark. This eBook helps you visually map communication styles so you can tailor your design story to a stakeholder or business partner.

Download Ebook

Demystifying Data Projects: A Guide for Business Leaders
While data science is a competitive advantage, data isn’t magic. Learn how to make magic happen by partnering more effectively with data professionals. This eBook delves into types of data projects, sample questions, tools and methods, key points and cautions—so stakeholders like you can initiate data projects with real business impact.

Download Ebook

Define Ebook Thumbnail
What’s the difference between a successful data analysis project and one that falls flat? 

Before you begin working with the data, you need to understand what you’re solving for. Gathering context and aligning around goals with your stakeholders from the outset will help you avoid disconnects and deliver actionable insights. Discover the most vital questions to ask before embarking on a data analysis project in our in-depth guide, “Define: Laying the Foundation for Successful Data Analysis.”

Download Ebook

Download Now