Leading Product Design Teams from Problem to Delivery

Leading teams through a process.

This is not to diminish the value of really skilled individual designers, but no individual designer can outperform a poor process at scale. In my experience, “bad” design teams are not held back by bad designers, but by bad processes or poor implementation of those processes.

The most common design process framework is called the Double Diamond, which represents what happens before and after the problem is defined. There are many variations and alternative ideas to this framework, but the overall structure of properly defining the problem before working on the solution is sound. With the Double Diamond in mind, I'm going to focus on the second diamond – the process after the problem is defined.

Most design processes from this point on are separated into two general phases: Exploration and Execution. During the Exploration phase, the goal is to generate as many ideas and concepts as possible for solving the defined problem. In some cases, the problem may be well enough defined that the Exploration phase is short.

Once enough viable solutions have been identified, the selection process must be informed by heuristics, user testing, and input from subject matter experts and delivery partners (writers, engineers, analysts, localization experts, etc). The design solution will not have every detail figured out. There will still be unanswered questions, but the general layout, functionality, primary content, and acceptance criteria will be solidified.

After that comes the Execution phase where designers have an approved design solution and begin to refine it. During this stage, they iron out the details, account for all the scenarios, and produce a well-documented design that can be delivered to engineers. There are little tweaks and things to figure out, but overall this phase is straightforward as the strategic and conceptual work is largely completed.

So, how do you lead the design team through these phases? What do designers need to be successful? How do you get past hurdles, stay on schedule, and get to the end product you’re after? It comes down to balance.

What makes design teams hard to lead?

Certainty vs. speed

The most challenging aspect of leading design teams is balancing certainty with speed. These two desired outcomes are typically at opposite ends of a spectrum. A lack of clarity around priorities will lead to poor results.

The more certainty that is needed, say for a new feature, then the more time will be required for exploration, iterations, stakeholder input, research, testing, and collaboration.

The more speed that is needed, say to deliver a critical feature improvement, then the less time there will be for the above-mentioned activities. The uncertainty that’s created can be mitigated by a lot of pre-existing knowledge or from a "ship first" perspective that acknowledges that the risks of launching something imperfect are lower than the risk of not launching something at all.

Design tasks are too broad or too specific

Contrary to popular belief, designers don't actually want an unlimited canvas to play in. To be effective, designers need to understand the challenge that they are solving. The creativity and power of a design team come from their ability to solve defined problems with both the objectives and the constraints in mind.

The flip side of this is being too prescriptive. When a design team is told to solve a problem in a specific way, they will skip exploration and focus on execution. This is totally acceptable for very tactical tasks, but when this approach is applied to new features with a high level of uncertainty, it will yield only the most obvious solutions. There is no room for “design magic” to happen.

Approving work is subjective

There's often no purely objective way to say "this works.” Design relies on approvers to decide when something works, and that decision must be informed by all the things that can be known at the time— goals, history, analytics, common patterns, testing, input from others, etc. The design process can really stall if it's unclear who is making these decisions and what those decisions are.

Feedback like, “It's not quite there yet, let's keep working on it,” signals to a designer that they have not presented the right solution. But sometimes that’s not the case and approvers are just reluctant to accept the work because they want a level of objective certainty that may not be possible.

When approvals are not decisive and timely, design teams end up getting blocked, causing the perception that the design team is not working at an appropriate pace.

Design visualizes thinking from many other departments

Design is a powerful tool for exploring ideas and building consensus, but it’s also a double-edged sword as non-design issues are often uncovered during the design process. Since design is a way to conceptualize thinking from many parts of the product team—like marketing, customer success, and engineering—a lack of clarity can cause challenges.

Frustration occurs when there isn't a clear understanding of whether an issue uncovered in the design process is in fact a design issue or if it's an issue with strategy, operations, dev, marketing, content, or another discipline. Because of this, design teams are often asked to solve problems that are outside of their skillset and knowledge, which is never ideal.

What can you do to support designers?

Providing context

Because design visualizes thinking from many other disciplines, it's critical that designers understand the broader context of their work.

This means:

• clearly communicating the challenge you are trying to solve
• share the marketing, business, operational goals that their task is meant to address
• sharing information about the user and their goals (useful tools and user stories, JTDB framework)
• sharing what has been done to address this in the past, what worked and what didn't

Defining requirements

Requirements create the boundaries or guardrails within which design teams can exercise their creativity. There's no sense in exploring concepts that are not feasible.

This often looks like:

• stating constraints from ops, business, engineering, etc.
• distinguishing between what we know and what we don't know
• defining what the design must achieve
• defining what fidelity of deliverable is required
• identifying the key stakeholders that we need to provide feedback and approve work
• adjusting the timeline and time boxing if there are significant scope changes

Timeboxing

Time is a constraint, but it's such an important one that it deserves mentioning again. Because design is almost infinitely iterative, timeboxing becomes one of the most effective ways to hit deadlines and determine when something is ready to deliver. Timeboxing at both macro and micro scales is necessary.

This often looks like:

• building a schedule that captures every required stage of your design process
• defining a deadline for each major stage, not just the final delivery
• including and respecting the design team's estimates
• identifying dependencies outside of design decisions that would block progress
• giving time boxing for approvals as well - "we need a decision by X date or this entire schedule shifts out"
• if using sprints to create time boxing, ensure that tasks are realistically achievable within the sprint

Conclusion

Leading design teams is not easy and issues are rarely solved by adding “better” designers. When evaluating the performance of your design team, it’s important to ask yourself if the right people are in the right environment to create the highly performant design team that you want.

Design process is the foundation of good design work, and you’ll need a good design leader to guide that process. Once you establish the right processes, you will see returns not only in the quality of the design work, but in the satisfaction of your design team as a whole.