Show & Take — the collaborative parallel design process

Genetic algorithms inspire a cross functional co-design process.

Linus Pauling said, “The best way to a good idea is to have lots of ideas.” An assertion backed up by research. Yet we often latch on to the first decent idea that comes along and refuse to let go. Also, those few ideas tend to come from a small group of people with similar perspectives.

The question is, how might we…

• Generate lots of ideas?
• Do so in a short time boxed format?
• Be inclusive to all stakeholders without barriers to participation?
• Inspire and be inspired by one another?

The Show & Take collaborative parallel design process is one solution.

I first learned about parallel design some years ago when I read “Shortening the Human-Computer Interface Design Cycle: A Parallel Design Process Based on the Genetic Algorithm,” by John McGrew of Decision Process Consulting. By that time, I had been involved with a couple of products that used genetic algorithms for optimization, so I was intrigued by the concept of leveraging a similar approach in user interface design.

Genetic algorithms essentially mimic evolutionary biology to find optimal solutions.

Initially, they select a population of solutions based on some evaluation criteria, then use a subset of that population (the fittest members) as breeding stock for the subsequent generation. This process continues for multiple generations, each getting closer to an optimal solution.

This article describes my experience with parallel design, and how you can use it to generate ideas and build consensus with a group.

What Is Parallel Design?

According to McGrew, parallel design mirrors genetic algorithms by starting with a large pool of ideas, evaluating these ideas using a set of heuristics, then selecting the fittest ideas to create a new generation of ideas. Along the way, you can add completely new or derivative ideas — similar to genetic mutations in natural evolution. You then evaluate these new ideas using the same fitness criteria. If only the fittest traits of any given generation inspire the next generation of ideas, presumably the end result is an overall population of ideas that is more robust and optimal than its predecessors.

At the most basic level, the parallel design process breaks down into these steps:

1. Design independently.
2. Present all designs.
3. Evaluate the designs.
4. Repeat this process, building on what you’ve learned during the last design, presentation, and evaluation cycle.

How does that apply to UX?

Typically, a UX design group goes through a minimum of four such design, presentation, and evaluation cycles; at which point, independent designs should begin to converge on a common solution.

While this seemed like a potentially effective way of generating many design ideas quickly, I had found it difficult to incorporate this approach into my design projects. For one thing, I had initially understood this process to be a tool for UX designers — meaning all participants would be UX design professionals. Later, I discovered that McGrew had actually conducted parallel design sessions with non-designers, including project managers, subject-matter experts, technical writers, and users. Even so, my fortuitous oversight inspired me to reach my own conclusions on how to expand parallel design into an inclusive and collaborative process.

McGrew’s process also called for ten people to participate over one or two days. I knew it would be difficult to regularly fit a process requiring the participation of ten people for two full days into most project schedules. I needed a lightweight process I could use early and often.

An evolution of parallel design

In a typical design cycle, internal and external stakeholders evaluate design proposals from a product designer or a UX design team. The feedback from these evaluations influence design revisions. This iterative process can take days, weeks, or longer. It continues until a team reaches consensus and agrees upon a design approach. I wanted a way to compress an iterative design cycle into a half-day collaboration session. By including participants from other disciplines on a product team, as well as users, we could incorporate their expertise, different points of view, and feedback into the final design.

The parallel design process also frames the task of designing solutions as a collective one, which is not solely the domain of UX designers. Teammates from outside a UX design organization can become active participants in the design space. This builds team consensus around design solutions. Plus, participating in a creative activity together helps participants from different disciplines better understand one another’s viewpoints.

This emphasis on cross-discipline participation caused me to question the need for the usability fitness function in McGrew’s process — which is a set of up to 30 heuristics a team uses to evaluate and collectively score every design after each design cycle. The higher the score the fitter a design. This evaluation process encourages group discussion and provides an opportunity for communicating human-factors engineering principles. Though I think this can be a valid approach, it’s a potential bottleneck.

First, one cannot assume non-design professionals participating in a parallel design session know how to conduct a heuristic analysis. While one could use a parallel design session as an opportunity to teach participants that skill, I didn’t see that as the best use of time. I wanted to focus on idea generation rather than evaluation. Additionally, scoring every design in each generation on up to 30 heuristics would be very time consuming. For example, ten participants in a collaborative parallel design session that produces four generations of designs might need to consider as many as 1200 individual scores! So, even though heuristic analysis is useful, I wanted an alternative approach that would allow the design process to focus on maximizing idea generation. The approach I decided to take was twofold:

1. Limit the evaluation criteria to a very small set of clear requirements.
2. Do no group evaluation during the design and presentation cycles.

Now I had the components of what I call collaborative parallel design.

Facilitator participation: In collaborative parallel design the facilitator is also a participant. As a facilitator, I keep time and enforce rules when needed, but otherwise I’m an active participant in the process.

Show & Take — collaborative parallel design process

The collaborative parallel design is comprised of the following steps:

1. Define the problem to work on.
2. Gather together a team of participants.
3. Review the requirements and evaluation criteria for a design problem.
4. Design independently for 10 minutes.
5. Each participant in turn gets 5 minutes to present their design ideas to the group. Others may ask clarification questions, but this is not a review session. Instead, evaluate through iteration.
6. Repeat the design/presentation cycle (steps 4 & 5) three or more times, ensuring each participant builds on at least one idea of someone else.
7. Have a group discussion about the final designs.

Conceptual model of the collaborative parallel design process.

Define the problem

It’s critical to clearly communicate requirements. I’m not going to go into detail here about what makes good requirements, but in short, they should be

• Clear and understandable to all participants.
• Free of explicit or implicit design or implementation recommendations.

Requirements for a collaborative parallel design session should be concise. A How Might We question is an excellent format to use, but others can work just as well. That said, with only 10 minutes of design time, no one can consider and satisfy a litany of complex requirements. You should prioritize requirements, so when conflicts arise, it’s clear which requirement it’s more important to satisfy. Also include information about any limitations, such as issues you don’t want to consider or technical constraints for the project.

Participants should also know the audience for the product they’re designing. Even though you’re asking participants to develop and share their ideas, all of them should still be aware of the user profile or persona for the product. Share requirements, personas, and other information relevant to the problem with them before the session as prep material.

Gather participants

I’ve found four to eight people is a good number of participants for a half-day, collaborative parallel design session. That’s enough to get a good cross-section of ideas, but still small enough to keep things moving along at a reasonable pace. If you want to work with a larger group, consider running multiple sessions, or extend the session to a full day.

Participants need time and information to prepare for a collaborative parallel design session. They need to understand both what to expect from the session itself and the requirements surrounding the design problem, especially if this is their first time participating in one.

When inviting people, briefly explain the steps of the collaborative parallel design process outlined earlier. Note that participation is voluntary. People need to know from the start that their opinions are valued, so I let everyone know that the team is intentionally diverse. This is some example wording from one of my invitations:

I’ve picked people with a range of expertise to participate. If you’re thinking, “I’m not a designer,” that’s the intent. Your ideas are important to the project’s success.

Finally, tell everyone this process does not guarantee specific outcomes for a product plan. Ideas transform, business demands fluctuate, and change is constant. It’s impossible to say when, how, or if an idea from an ideation exercise will ever get implemented. I want to assure participants that the process is important, even if it’s not apparent how it may influence the final product.

Create an environment conducive to design thinking

Collaborative parallel design process focuses on harvesting the ideas of individuals. It is not an open discussion forum. Group dynamics are often not conducive to getting all ideas heard, and our goal is to maximize idea variety and quantity.

When I conduct a collaborative parallel design session, in the room I post IDEO’s brainstorming rules along with the following points for participants to keep in mind throughout:

• Good ideas can come from bad designs. Don’t throw away any of your ideas. There is no telling how ideas can inspire.
• Part of an idea is also valuable. Maybe you can’t see a solution to the whole problem, but have a thought about how to solve one part of it. Capture that thought. Exploring it may lead you or someone else to a complete solution.
• Listen, learn, and be inspired. For collaborative parallel design to work, each generation of designs must inspire the next. This means it’s essential for you to be an attentive observer while others are sharing their ideas. Keep an open mind and take notes.
• Feel free to fail. People continually self-edit, because they want to avoid being wrong, but we learn the most from failure. A collaborative parallel design session is an environment in which everyone should feel free to fail.
• Have fun!

At the end of most every session I’ve been part of everyone said what fun they had. Done right, collaborative parallel design really should be an enjoyable experience all around.

Tools

Participants capture their design solutions on paper (8.5 x 11 or similar) during the session. Hand sketches are both easy to create and permanent. Whiteboards are okay, but with paper it’s much easier to share and review the designs after each iteration, and even compare them with earlier iterations.

A pile of paper, a bunch of sharpies of varied colors, pens, pencils, tape (to post sketches on a wall or whiteboard), and a timer are all you need.

Kickoff

The problem is defined, room prepared, team gathered, and you’re ready to begin. If this is the first time for some participants, or if not everyone knows one another — take the time to explain what to expect, and have everyone give a quick introduction.

Since you sent out the prep material everyone should know what the requirements and objectives are, but it’s still best to review them as a group.

Rules to emphasize and enforce as the facilitator during the session:

• Design time is quiet time. Everyone works independently in silence for 10 minutes. This is not a group session lead by the loudest voices in the room. Talkers should be reminded to be quiet until time is up.
• No judgement during presentation time: While someone is presenting your job is to understand their idea. You may ask a clarifying question if you really don’t understand something someone said, but you are not allowed to ask judgement questions. Judgement questions sound like: Why didn’t you do this? Did you consider that? They impose your perspective on the problem. Ideally everyone should simply listen to the person presenting. If a lot of questions are being asked, that’s a problem.
• Be present: That means NO electronic distractions! You can schedule breaks to check emails and such, but but the devices away when in session.

Designing Solutions

The design phase is fairly self explanatory. Having reviewed and understood the requirements, each participant spends 10 minutes designing a solution. How they do this is completely up to each individual. They can create sketches, narratives, feature lists, flowcharts… whatever works for them.

There are only three rules around designing:

1. Identify your work. Have each person put his or her initials and the design-cycle number on each piece of paper, for example — on the second iteration I (Mike Myles) would write MM2 on my papers. This makes it easier to trace the evolution of ideas later.
2. Don’t throw away any ideas. There is no telling how one person’s idea might inspire another. Collaborative parallel design is about maximizing idea generation. Ask people to present all of their ideas, even if they change their minds and don’t like something they thought of. What they think is a bad idea might inspire others or it might go nowhere, but leave it to the process to figure that out.
3. Be quiet: I said it before, but it bears repeating. Work individually and give others the space to do the same. You’ll get your chance to talk when you present your ideas.

Presenting Designs

The presentation of the designs is incredibly important to the success of a collaborative parallel design session. It’s here the cross-pollination of ideas takes place. Presenters must feel they have everyone’s attention and can speak without interruptions. You want presenters to focus on communicating a clear vision, while observers listen attentively to what they’re saying.

Each person gets up to 5 minutes to present what they have to the group. To facilitate successful presentations, I ask that observers limit themselves to clarifying questions that ensure they understand a design properly. Observers should feel free to take notes, but their primary focus should be on listening and understanding what a presenter is showing.

The goal is for observers to understand the ideas others are presenting and build upon those that inspire them. Evaluation occurs naturally, as part of this process. Each successive generation amplifies the strong ideas and casts off the weak ones.

Here are some tips to help keep presentations on track:

• Plan how people should share their designs. Whether taping designs onto the wall, displaying them on an easel, or spreading them out on a table; work this out and test it ahead of time to ensure you can keep things moving. Keep presentations as low-tech as possible so less can go wrong.
• Have participants stand and gather around the presentation area. It’s more engaging for everyone to mingle around a presentation area, standing face to face with a presenter rather than sitting far away from the action. This should feel like an informal exchange of ideas. Like a conversation between colleagues.
• Absolutely no multitasking. If someone cannot be without a computer or mobile phone for a little while, this is not the right activity for them. When it’s someone’s turn to observe, they need to actively look and listen, getting inspiration for the next round of design from what other presenters have shown. If people aren’t being attentive, they won’t receive the inspiration that is essential to this process.
• Defer non-clarifying questions. If questions go from clarification to criticizing a design, step in and remind everyone that the presentation phase is about gaining understanding, not evaluating designs. Instead, you’ll implicitly evaluate designs with each successive generation.
• Mix up the presentation order. Most people don’t want always to go first or last, so mix the presentation order up with each round. As the facilitator, I usually present first during the first cycle, just to break the ice. That’s not essential, but it’s probably a good idea, especially if this is the first collaborative parallel design session for everyone.

It’s also a good idea to periodically photograph the team’s progress.

Repeat, repeat, repeat…

The power of this process comes from iteration. After each presentation another design cycle follows. The group should repeat the design and presentation cycle at least 4 times.

With each iteration participants can either refine their designs or start anew, but they must build upon at least one idea someone else presented (more than one is fine). This natural selection process mimics genetic evolution, where each generation inherits some traits from the last. The intent is for this evolutionary process to filter out the weaker ideas and amplify the fittest.

As the team starts each successive design iteration, all participants should use their own judgement to guide their design direction. They should consider the requirements and any other information relating to the problem they’re solving for, but ultimately everyone should rely on their own judgment.

Analyzing Designs

Once you’ve completed four or more generations of designs you may find that individual designs have begun to converge around one or more similar solutions. Now it’s time to analyze the resulting ideas.

I find it’s useful to conclude each collaborative parallel design session with a relatively informal group discussion about the resulting designs, as well as the process itself. This is a good forum for considering the results and next steps. You may find a strong consensus has emerged and the path forward is fairly obvious, but that may not always be the case. The results may show that participants still have a poor understanding of the design problem, or major issues might have arisen that people hadn’t previously considered. Perhaps your findings indicate further research is necessary.

While reviewing the results, be sure to revisit the requirements you started with. Do the proposed solutions address the requirements? Were some needs overlooked? Did you learn anything from this session that may cause you to rethink the requirements?

If you want, you can also use this time to prioritize the resulting ideas as a group using any of a number of approaches, such as dot voting, MoSCoW method, a 2D prioritization matrix, or any other you like.

Variations on the process

Here are some ideas for variations on the collaborative parallel design process that you can use to generate more ideas during a session, or further refine designs beyond what a single 4-hour session can accommodate.

• One team, multiple sessions: Have the same team meet for multiple sessions over several days, allowing them to complete more rounds of design and presentation. This also gives participants an opportunity to sleep on ideas.
• Multiple teams on the same problem: Use the same requirements with different groups and compare the results. They may generate totally different ideas or converge on some common ones.
• Multiple teams building on prior results: First, run a collaborative parallel design session with one team. Then run a session with another team, but rather than starting from scratch, share the findings of the last team to seed the new team’s session with ideas. Repeat this process as many times as necessary. This allows the process to build on past work, but still bring in fresh thinking from other participants.
• Concurrent collaborative parallel design sessions: Have multiple teams of six people participate in independent collaborative parallel design sessions simultaneously, focusing either on the same problem or different components of a larger problem. After 4 hours, have all teams come together and present their findings. Follow up with a large group discussion of the collective results.

For distributed teams, try the multiple-team variations so each colocated group can work together. Small groups of team members in distributed geographic locations can concurrently conduct collaborative parallel design sessions and share their results. In this way, each group has the advantage of running a session in person, while still being able to leverage the expertise of the larger distributed team.

While it’s possible to conduct collaborative parallel design with a remote group, it is much simpler to do in person. If working remote, expect the process to take much longer and be prone to technical snags.

Conclusion

I’ve found collaborative parallel design or Show & Take to be an excellent way of generating a wealth of design ideas quickly.

The genetic inheritance model that collaborative parallel design uses is a powerful mechanism to bring about cooperation and drive consensus. It ensures that everyone involved in a session is listening to, understanding, absorbing, and using the ideas of others, because the process compels them to incorporate others’ ideas into their own designs.

Collaborative parallel design engages stakeholders in the design process by asking them to participate in design, not just inform it. It’s empowering for non-designers and enlightening for UX professionals. It forces the members of a multidisciplinary team to work on a common problem in a structured and nonjudgmental way — one that requires them to see the best in other’s work.

Acknowledgement- Illustration by Tammy Schatz Myles.

Previous version published at https://www.uxmatters.com (April 2010)