The Many Meanings of Design-Led

Jon G. Temple
Jan 10 · 10 min read

Co-written by Jon G. Temple and Patrick Commarford, both from CIO Design at IBM.

In recognition of the importance of design to product success and adoption, many companies have been positioning themselves as “design-led.” Yet, there is little consensus about what it means to be design-led, and how it is defined may depend critically on who you ask. But no matter who are you, design-led should mean doing something different than before, stressing the importance of design and end users as key success factors.

Increasingly, designers are working within an agile development framework.This plays a big role in how one might define design-led. Agile has emerged as the dominant way to develop solutions, and it has for good reason. Agile fosters teams to decompose proposed functionality into bite-sized pieces and to deliver them rapidly, while also affording flexibility to make necessary changes without the need for convoluted request processes, updating complex documentation, or rewriting the entire codebase because it was delivered in a monolithic unit. Agile software development is a huge improvement over older delivery methods characterized by extensive and rigid planning, documentation, design, delivery, and test phases.

Agile as a major force arose many years before design grew to its current prominence in the enterprise.In most of its traditional forms, agile assigns no special role to design or user research. In scrum, the core roles include the product owner, the development team, and the scrum master, recognizing that development team members may have individual focus areas, such as testing or operations. This can create some challenges for organizations that are seeking to lead with design in a traditional agile context.

To explore some of the complex issues around what is meant by being design-led in an agile context, we have created four “archetypes.” During the course of a long-term project, it is possible to see more than one of these archetypes at play, depending on fluctuating stakeholder support for design, the team composition, and the team’s agile maturity.

Table summarizes the 4 archetypes described in this article
Table summarizes the 4 archetypes described in this article
Table listing our 4 archetypes

The Body Shop

This first archetype is more of a cautionary tale for a project that is not design-led but whose leadership may nonetheless seek to represent the project in those terms. Body shops typically recruit a range of designers and researchers to staff a project without giving them a seat at the strategy table.Rather, designers spend a lot of time doing layout and making things look visually attractive.

In a body shop, the UX strategy is typically dictated to the designer by leadership, stakeholders, or the product owner. This is similar to the way an external design agency might work.When the clients hire them to design a bridge, specify that it needs a sidewalk through the middle, and that it should be bright pink with lime green polka dots, that’s precisely what the agency designs. In the enterprise, designers are supposed to be an integral part of the team, not hired to design an interface with specific attributes for a pre-specified solution.

While UX research may be included and leveraged by the designers themselves to decide fine design points for the few elements they control, the research rarely informs the product strategy, except when it already supports the leadership vision. Body shops may play lip service to the idea of design-led, but in reality, this is stakeholder — or executive-centered — design.

The Body shop Archetype: Image of people in a line climbing up a hill towards a prescribed destination
The Body shop Archetype: Image of people in a line climbing up a hill towards a prescribed destination
The Body Shop Archetype. Illustration by Michelle Lee

The Committee

The Committee archetype is inspired by popular methods of integrating design into agile, which focuses on the whole cross-functional team building a shared understanding of the problem space and the user needs. Research and design responsibilities may be shared among the entire team, not just by the professional designers and UX researchers. The Committee approach to design seeks to have the entire team feel invested in the users and their experiences, and to promote a rapport that improves team cohesion, minimizes the need for documentation, facilitates communication, and fully leverages the varied perspectives of the full cross-functional team to create an improved product.

The Committee archetype can be invaluable on projects where there is no dedicated designer assigned, which may be necessary for some solutions with user interfaces that can only be minimally altered (for example, an internal deployment of a vendor solution with minimal configuration). Every team is better off with a design mindset even if they cannot afford designers. On projects that seek to solve more complex problems, designers may be facilitators or lead the design and research efforts, but do not fully own them. In this model, designers who insist on owning the user research, the vision, and the user interface are usually described as “heroes” — and not in a good way.

There is a lot to like about the Committee approach, which tries to inject the importance of design into the very DNA of agile itself. On a project where the entire team is devoted to ensuring the design is successful, design-led becomes more of a shared value system than a leadership attribute. However, as beneficial as it is for the entire team to focus on and feel invested in the user experience, there are also plenty of challenges with this model. Do developers, for instance, have spare bandwidth to be deputized designers or researchers, practicing the wide range of design activities necessary to produce and validate seamless, delightful experiences? Or, will the user experience suffer because developers are asked to perform design responsibilities in addition to their core role?

UX research and design are specialized skills that, arguably, not just anyone can or even should do, even with a trained UX practitioner overseeing the effort. For example, there are many poor ways to collect user data.These include:asking leading questions, treating preferences as a substitute for task-based data, generalizing from outliers, believing your introspections to be true of all users, misclassifying stakeholders as representative users, or failing to recognize that what users literally say may be the result of an inadequate technical vocabulary and must be paired with behavioral observation to put into context.

Similar danger exists in democratizing design, where a novice may use dated design patterns (e.g., everything must be above the fold), fail to create more than one design alternative, copy a known pattern without consideration to its use, treat stakeholder feedback literally and as mandatory, devalue the importance of visual design, or require users to read the manual because it simplifies code.

The Committee Archetype: image of people gathered around a table
The Committee Archetype: image of people gathered around a table
The Committee Archetype. Illustration by Michelle Lee

The Whisperer

In agile scrum, the product owner has the ultimate responsibility of ownership of the product strategy and outcomes, occupying a privileged space between the developers, stakeholders, the business, users, and is empowered to make self-directed decisions. This level of autonomy is crucial to strike the appropriate balance between all of the groups they represent. Careful thought must also be put into the selection of product owners, including recruitment from design itself, or from the business they represent.

UX designers and researchers also have a lot to offer in evolving the product strategy. UX research brings valuable user insights into what kind of solution should be built; user evaluations validate assumptions and whether the design meets user expectations. Designers are quite adept at crafting a full vision for a product, how it may evolve past the Minimally Viable Product (MVP) to something more feature rich.

In this model, the main way that designers can influence the product strategy is by promoting a trust-based relationship with the product owner, becoming “the whisperer”. This can be mutually beneficial to both roles.Designers and researchers have unique insight into their users, and are capable of visualizing improvements to the user experience as a core competency. A product owner paired with a designer is going to be much better at prioritizing the features most likely to improve the user experience and in evolving the product strategy. Likewise, designers paired with a product owner who seeks this value gain benefit by acquiring an indirect seat at the strategy table.

With the right personnel, the Whisperer archetype can be very strong, but the model jeopardizes user experience by placing all team leadership responsibilities in the product owner’s hands, providing only indirect opportunity for UX Design leadership. The success of the Whisperer model depends heavily on a product owner who indeed seeks and values UX insights as a driving strategic force, as well as a strong designer who is satisfied with an influencer, rather than direct leadership role.

The whisperer: Image of someone whispering to another person
The whisperer: Image of someone whispering to another person
The Whisperer Archetype. Illustration by Michelle Lee

The Anointed One

In the Anointed One archetype, the executive leadership trusts that the designer has the skills to figure out what users need, design the right solution to meet those needs, and course correct based on user feedback. The product strategy is primarily guided by the UX team. Without a doubt, this is design-led, and for many designers, this is the dream. Respect!

However, being a designer on a big agile project can keep you very busy, especially if you coordinate the UX research as well. As the primary decision maker, the Anointed One should probably also lead release planning, prioritization of the backlog, and attend all agile ceremonies. The Anointed One will certainly need additional UX staff to ensure all design and research continues unabated. Another challenge lies in how priorities are set. As important as it is to lead with design, all efforts are in vain if the team doesn’t actually ship enhancements and value to users. That means balancing design priorities against those from development, the business, and the stakeholders, as well as accounting for technical feasibility and debt. This balance requires insights and leadership from those in key positions outside of design. Related, if the design lead is the sole decision-maker and the product doesn’t do well in the real world, the Anointed One will be the one — the only one — to blame.

There is another problem. If the Anointed One is the sole decider of every feature, resentment may build among the stakeholders and the developers that they do not get a seat at the table. The ultimate solution to giving designers a seat at the strategy table should not be taking seats away from the other key roles. Team cohesion is vitally important to delivering a successful product and everyone must feel invested in it.

The Anointed One Archetype: Show a designer with crossed arms and a halo
The Anointed One Archetype: Show a designer with crossed arms and a halo
The Anointed One Archetype. Illustration by Michelle Lee

Building a Better Archetype

Each of these archetypes represent different ways teams commonly position themselves as design-led. Design leadership may run the gamut from nonexistent to distributed to direct leadership by designers.The one thing they all have in common is that establishing and sustaining design leadership is fragile. What is needed is a middle ground that incorporates the best of each archetype without its corresponding weaknesses. Drawing from each archetype, we would like to propose an alternative model:

  • The project is fully-staffed with dedicated and skilled UX designers and researchers.
  • UX researchers engage techniques such as immersion, observation, interviews, surveys, and task analysis, to help the whole team build a clear understanding of, and empathy for, their users.
  • UX, Product, & Engineering have co-equal voices and partner to ensure that user research, along with other key inputs such as market viability, business needs, and technical feasibility, drive product strategy and agile decision-making.
  • The entire project team is dedicated to the success of their users. All members provide ideas and input into the overall UX vision and actively contribute ideas each sprint.
  • The UX team is ultimately responsible for curating ideas, exploring multiple conceptual approaches, continuously collecting feedback from real users, refining the experience, and for keeping the project team informed as to the rationale behind design decisions.

You cannot be truly design-led without staffing your project with designers, and becoming design-led is going to be an uphill battle without the entire project team sharing core values that incorporate the importance of design and talking to users. This means taking steps to review design decisions before they are finalized and encouraging an atmosphere of openness.

The biggest challenge for agile teams is accepting that the design team is closest to the end users and their needs, and therefore must have a coequal voice with the product owner. Agile is not a religious dogma. It is meant to make development faster, more flexible to change, and better able to meet user and stakeholder expectations. There isn’t just one way to be agile; if you need to change your implementation to better support your design-led mission, don’t hesitate.

One common formulation of this coequal relationship is called “two in the box,” where the product owner is paired with a design lead. Another variation is “three in the box,” that includes the lead architect. Decisions are reached jointly by this small team, but only after soliciting feedback from users, stakeholders, and the entire project team. This ensures cross-functional representation, and the key players all have a seat at the strategy table. Strong, collaborative relationships are key, as well as dedication to user success and business needs.

Jon G. Temple is a Senior UX Designer at IBM, CIO Design, based in Southbury, CT; Patrick Commarford is a Design Principal at IBM, CIO Design, based in Daytona Beach, FL; and Michelle Lee is a Visual Designer at IBM, CIO Design, based in New York City.

The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.

Jon G. Temple

Written by

Jon Temple is a Senior UX Designer at IBM, with over 20 years of UX experience. A graduate of Vassar College (BA) and University of Cincinnati (MA & PhD).

Design at IBM

Stories from the practice of design at IBM

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade