ARTICLE NO. 763    November 08, 2011

Design Studio and Agile UX : Process and Pitfalls

We are often asked how and when Design Studio should be used in a startup or enterprise whose product team embraces agile. We hope this article answers some questions about how to effectively use Design Studio (as well as variations on it), and to avoid potential pitfalls so those practicing some flavor of agile UX will be better armed to solve difficult problems in their work.

The description of Design Studio in The Design of Design Studio was meant to serve as the canonical example, and is best suited for the beginning of a significant series of projects focused around one theme, or a set of themes. The output of such a design studio session may span many iterations. There are, however, many variations of Design Studio that can be employed to good effect for the smaller problem spaces within agile processes. For example, a Scrum team may need to explore a more targeted problem space that they identify during iteration planning prior to a sprint.

This should not imply, however, that we use Design Studio during what is sometimes called “Iteration 0,” although there is no reason why it couldn’t be used then. We don’t happen to follow the “staggered sprints” model popularized by Desiree Sy and Lynn Miller at Autodesk. Instead, we solve problems as whole Scrum teams and bring the ideation, design, and development phases as close as possible to the same kickoff point so the concepts can inform story-gathering and estimation sessions.

Project Team

Using Design Studio with Agile UX

There are several things that happen even before iteration planning or Design Studio:

  • Definition of the problem statement and its scope
  • Selection of who will be involved, and which Scrum team(s)
  • Determination of which stakeholders will be able to provide the most insight and direction

These decisions usually involve the director of product or a product manager and a UX designer, who must also decide whether there’s need for a Design Studio. Based on the research, problem statement, and potential scope, product managers and UX work to decide the best use of Design Studio, assuming it’s appropriate at all. Here are some examples:

Large-scope efforts

For some larger projects, e.g., before kicking-off a completely new product, we have held multi-day Design Studios where the first day focuses on various brainstorming techniques. This helps all the stakeholders and team members explore the nature and scope of the project to be undertaken as well as to generate many ideas about the potential market, audience, and business goals that will need to be addressed. A great resource of activities is Dave Gray and Sunni Brown’s Gamestorming, which we have used to help gain alignment between the team and stakeholders.

Day two of a large-project kickoff may include an all-day or partial-day Design Studio with a post-mortem. We’ve also used these larger efforts to tackle multiple “slices” of the same problem statement, looking at it from different product lines’ points of view. From here, it may be okay for the UX designer to move ahead with the concepts, but being careful not to overdesign any one concept. Although technically, this is “designing ahead,” for large problem spaces where there need or opportunity for innovation. In Anders Ramsay’s article Designing Ahead: The Good, The Bad, and They Ugly, he offers some sound advice:

Try to treat the innovation work like a UX spike, i.e. a short and intensive exploration. Just don’t turn it into an excuse for doing weeks or more of mockups and sketches. The goal should always be to find the shortest path to start to confront your ideas with something real.

The other reason you may need to further explore concepts from a larger Design Studio through a “UX spike” is that the concepts being explored will require organization buy-in, will impact many stakeholders, or will cause a disruption in your organization’s business strategy. Just be mindful that they concepts should not be treated as final designs in the waterfall sense, but simply conversation starters to have between the Scrum team and stakeholders.

Medium-Scope Efforts

For medium-scope efforts, especially ones where the solution may only require two iterations to accomplish, a half-day Design Studio has proven to be more than appropriate to achieve the primary goals described in Introduction to Design Studio Methodology, which include:

  1. Collaboratively work to understand the problem space.
  2. Allow ideas from various perspectives to percolate up.
  3. Turn ideas and, especially, unstated assumptions into sketches that can be discussed.
  4. Create a culture of shared ownership.
  5. Generate a lot of ideas in a very fast time frame.
  6. Allow open and honest critique.
  7. Have some share understanding of potential solutions.
Smaller-Scope Efforts

In our experience, a rapid, small, three-hour Design Studio can be used effectively to explore a problem the Scrum team will be facing in their next iteration. These tend to happen on a Friday afternoon, immediately followed by story-gathering and estimations. This usually means the team does perhaps two rounds of sketches and critiques, settles on a potential solution, and can immediately estimate the scope.


For these smaller-scale efforts, we may not even produce wireframes since the Scrum team’s art director would have been in the Design Studio, and the only visible UX artifact could be a visual design comp or some working front-end code. It all depends on the scope of the problem space, the balance of the team, and the potential needs for more organizational buy-in.

Potential Pitfalls of Design Studio

We have witnessed a number of instances when Design Studio was a failure, or at least a huge waste of time for all those participating in it. We also admit that some of those failures were ours in not properly educating stakeholders as to when Design Studio is and is not an appropriate way to explore an opportunity and generate new ideas.

Successful organizations have discovered that shared and collaborative leadership, rather than heroic and authoritarian management, is what unlocks the potential of organizations. Organizations that operate from the authoritarian, hierarchical, command and control model, where the top leaders control the work, information, decisions, and allocation of resources, produce employees that are less empowered, less creative, and less reductive.

- Journal of Strategic Studies, Creativity and Innovation: The Leadership Dynamics.

Pitfall 1: Having a solution before Design Studio starts

In this scenario, product management and UX have already explored the problem space and designed a solution, and are only running the Design Studio to gain development buy-in to the process. Why is it bad? If the ideas generated in the Design Studio don't manifest in the solution itself, developers will lose trust in their contributions being valued, and resent product and UX for wasting their time.

Developers love to solve problems. Don't waste their time, and don't disenfranchise them or you will lose their respect. The goal of Design Studio is to include the entire team in solving the problem. Anything less, and the Design Studio becomes meaningless.

Pitfall 2: Not adequately scoping design studio to meet the problem

When Design Studio is improperly scoped for the problem statement being addressed, more often than not it is shortchanged. This can happen for a number of reasons, but the most prevalent is difficulty with scheduling. “We really should do an all-day Design Studio, but it’s impossible to schedule all the necessary people for an entire day.” Think about this for a moment. If you’re addressing an opportunity that could generate a new product concept with the potential to upset your revenue streams or generate millions in additional revenue, what’s one day in the grand scheme of things? You don’t design the scope of Design Studio to match people’s schedules, you scope it to address the market potential of the solution you hope to create.

Pitfall 3: Introducing blockers and business rules too early

Sometimes members of the team (often well-meaning stakeholders) will block or critique ideas at the beginning of or during Design Studio based on existing business rules serving existing business needs according to old or current market conditions. This should be highly discouraged during Design Studio itself. It guarantees that no innovation happens in the Design Studio.

But that is not nearly as bad as opening a Design Studio by stating that the goal of the day is to create X solution as dictated by Y organizational stakeholder (who happens to not be in the room). Instead, begin Design Studio with a clearly articulated problem statement and then let ideas percolate up, refining them throughout the course of the day. The end of the day, when refined ideas are articulated to stakeholders, is the appropriate time to discuss potential business rules and make decisions about whether the designs should be changed to accommodate the rules, or whether the rules are no longer important. I have seen a number of situations where hard-and-fast rules turn out to be not so, and were in fact completely flexible or arbitrary. Enter Design Studio with an open mind lest you crush the opportunity for innovation.

Pitfall 4: The invisible hand of the absent stakeholder

If you're not part of Design Studio, you don't have much voice in the ideation process of a solution. If a business stakeholder has already defined the solution to a problem that was explored offsite by an executive team, Design Studio is not appropriate, and in fact can be counterproductive. Executives should simply hand the designs to a product manager to draft detailed requirements and let the product/development teams implement it. Offsite “design by executive stakeholder” is neither empowering nor Agile, for that matter. This goes back to the principle of not wasting people’s time.

We have seen instances where a team was gathered across the organization, the problem space was explored, and new and creative ideas were hatched, all to be crushed by a stakeholder who isn’t even in the room and has not participated in any of the discussions, brainstorming, or ideation phases. This disenfranchisement crushes morale and ultimately means that the project, while potentially successful, ends up nowhere near as disruptive or innovative as it had the potential to be. It also sours team members to the value of future Design Studios and creates a culture not only devoid of the passion necessary to innovate but one that is, in essence, is afraid to innovate.

Whiteboard Sketch


Will you always be successful in avoiding these pitfalls? Of course not. We work in the real world and navigating the minefields of organizational dynamics is a difficult and complex skill. We just hope that by sharing these with you, you will be able to get the most out of your next Design Studio. The Design Studio methodology provides a collaborative, pragmatic process of illumination, sketching, presentation, critique, and iteration leading to a shared vision of the problem space, uncovering of tacit knowledge, and discovery of unique and potentially elegant solutions. Design Studio can also save time and effort because there are less meetings to discuss designs created in a black box or an offsite. The team is empowered to actively collaborate on the solution, instead of passively absorbing the completed design specifications.

Are there any rules, then, as to how far ahead of a Scrum team’s next iteration and how large the Design Studio should be? The short answer is “no.” The scope of the problem space, the number of scrum teams involved, and the potential number of stakeholders across the organization who will need to provide some level of input are all salient issues that will impact how you choose to run the Design Studio. Use your best judgment, knowing that you will fail a number of times in the process, but at least keep these pitfalls in mind as you plan your next Design Studio.

Good luck and we hope to hear from you.



Add a new comment

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as clickable links.
Thanks for writing such a good post. I do came from web design and web development field including 3D modeling and love to read fresh posts on this topics. Thanks for writing such a valuable and informative post. I am now your regular subscriber
  • Showing 1-1 of 1