Draft
This post was co-written with my co-worker, Jeff Gothelf, a fellow UX Designer who has been writing and speaking about both Agile and Lean in the context of user experience design for a while now.
“I’m curious, when you are using [design studio] during the Agile process. Iteration 0?” is a question that was recently posted by Virginia Cagwin (@Vcagwin), to my article on “The Design of Design Studio“. She brings up an interesting question, and one that Jeff (@jboogie) and I have discussed at length, so we teamed up to write about some considerations when deciding to use Design Studio in an Agile company.
The description of design studio written about in “How to Design the Design Studio”, was really meant more to serve as the canonical example, and is best suited at the beginning of a significant series of projects focused around one or a set of themes. The output of such a session may span many iterations in an Agile UX company such as TheLadders. Labeling it “Iteration 0” intimates that we follow the “staggered sprints” model popularized by Desiree Sy and Lynn Miller at Autodesk – which we don’t. Instead we opt to solve problems as whole scrum teams and bring the ideation, design and development phases as close as possible to the same kickoff point.
Design Studio For AgileUX
Sometimes, a rapid 3-hour design studio will happen on a Friday afternoon, immediately followed by story gathering and estimations. Sometimes design studio may happen weeks before the scrum team is ready to begin estimating or developing the solutions. It really depends on the scope and nature of the problem statement.
As described in the article, the first thing that happens even before iteration planning or design studio is a definition of the problem statement and its scope; who will be involved; which scrum team; as well as which stakeholders will be able to provide the most insight and direction. After this problem setting is done, usually involving the director of product or a product manager and a UX designer, a decision is made as to the possible need for a design studio. For some larger projects, e.g., kicking off a completely new product, we have held multi-day design studios where day one focuses around various brainstorming techniques so that all the stakeholders and team members are able to 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. 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.
For much smaller efforts, especially ones where the potential scope is a solution that may span two iterations to accomplish, a half-day design studio has proven to be more than appropriate to achieve the primary goals which was explain in “Introduction to Design Studio Methodology,” which includes:
- Collaboratively work to understand the nature, opportunities, and constraints of the articulated problem space
- Allow ideas from various perspectives and insights to percolate up between team members.
- Turn “ideas” and especially unstated assumptions from tacit or verbal states into cognitive artifacts that can be shared, evaluated, and iterated upon.
- Create a culture of shared ownership around future product vision.
- Generate a lot of ideas in a very fast time frame – usually no less than 3 hours, and sometimes as long as 10 hours.
- Allow open and honest critique of various concepts.
- Engage participants to defend their concepts and negotiate with other team members.
As important as it is for us to tie design studios to the beginning of an iteration, there are many pitfalls that can diffuse the positive effects and success of this tactic
Potential pitfalls
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
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, development will lose trust in their contribution and resent product and ux for wasting their time. #ProTip: 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
Another pitfall I have run into is when the design studio is improperly scoped for the problem statement being addressed. More often than not, design studio is shortchanged. This can happen for a number of reasons, but the most prevalent is difficulty 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 create an entirely new product generating 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.
This pitfall is when members of the team, sometimes well-meaning stakeholders, 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, though this is not nearly as bad as opening a design studio by stating that the goal of the day is to create an X solution as dictated by Y organizational stakeholder (who happens to not be in the room). Begin design studio with a clearly articulated problem statement, and then let ideas percolate up, refining them throughout the course of the day. At the end of the day, when refined ideas are being 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 set in cement 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 to 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 who drafts up detailed requirements and lets the product/development teams implement. This goes back to the principle of not wasting people’s time. I have seen instances where a team is gathered across the organization, problem space explored, new and creative ideas 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 some concepts explored during design studio. 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, afraid to innovate.
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 set. We just hope that by sharing these with you, you will be able to get the most out of your next design studio.
Conclusion
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, uncover tacit knowledge, as well as discover unique and potentially elegant solutions. Design studio can also save time and effort because there are less meetings to discuss designs that were done in a black box or an offsite – the team is empowered to actively collaborate on the solution, versus the old process of passively absorbing the completed design specifications.
Are there any rules, then, as to how far ahead 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 that 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 judgement, knowing that you will fail a number of times in the process, but at least keep in mind the the pitfalls innumerated above as you plan your next design studio.
Good luck and we hope to hear from you.
Comments
Will and Jeff – great post on the art and science of design studio!
Since starting to make design studios part of my practice some years back, I had to wonder how my practice had been able to function without it up until that point. What I realized was that I–as many traditional designers–had been expending tons and tons of my own energy to try to come up with design solutions and present them to passive team members, when I in fact was surrounded by an incredible source of creative power, in the form of that very same team. IMO, any UX’er today who isn’t incorporating design studio is really losing out.
That said, it is just as important to point out that the design studio described in this post is only _one_ of many variations on this technique. In my practice, I use three variations of design studio.
The first is what I call the “Ideation Clearinghouse” model. In contrast to the above design studio, which is convergent (i.e. the goal is to narrow your exploration to a small number of good ideas), this is a divergent form of design, in which I want to uncover the range of ideas that the project stakeholders have about the product.
This is perfect for doing with business sponsors at the project outset, to capture the product they are seeing in their minds, such that when the team then goes to work to design the real product, they can do so with an awareness of that. Knowing what execs and others who fund the project are imagining the end product to look like is worth nothing less than gold when presenting your own ideas to them. (If not, you may present something that is strong, but because it was not what they expected, you’ll get a thumbs down.)
Then there is the convergent model which you describe and is super-powerful as an activity for the team itself.
Then there is what I call an ad-hoc design studio. This is great for when the team is in the throes of the sprint and some unexpected issue comes up. At that point, a few team members grab some sheets of paper and markers, agree on what the issue is (e.g. something developers thought would be easy to build has turned out to be much harder, so they’ve proposed a different technical solution which in turn will require a very different UI), and do a 5-minute or maybe even 3-minute sketching timebox (sketchbox?), followed by discussion of the ideas proposed. I’ve done sessions like this in under 15 minutes – which brings me to my last point.
From your description of design studios, someone with no experience with them, would get the sense that you need hours and hours to be able complete them. This is simply not true. Yes, for certain models and certain situations, 3-4 hours or more can be time very well spent.
But a design studio can also be much more *lean* than that, i.e. you can also do them in an hour or less, and I think that should be front and center when describing this powerful technique to anyone who is new to it.
Excellent series of articles on Design Studio. I am wondering if you have ever applied this outside of the realm of digital media and UX design. For example have you ever applied it to problems involving the redesign of a service or business process? Do you think it is applicable in this area?