Using a Collaborative Parallel Design Process

April 5, 2010

I first learned about parallel design several 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 some subset of that population—the fittest members—as breeding stock for the subsequent generation of solutions. This process continues for multiple generations, each getting closer to an optimal solution.

This article describes my experience with parallel design and discusses how to make parallel design more collaborative.

Champion Advertisement

What Is Parallel Design?

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:

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

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 nondesigners, 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. It would be difficult to regularly fit a process requiring the participation of ten people for two days into the schedule of most UX design projects. I needed a lightweight process I could use early and often.

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 influences design revisions. This iterative process can take days, weeks, or longer and continues until a team reaches consensus and agrees upon a design approach. I wanted a process that essentially attempts to compress an iterative design cycle into a single 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 for problems 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 can help build team consensus around design solutions. Plus, participating in a creative activity together helps participants from different disciplines to 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 and effective approach, it can also be a potential bottleneck in the process.

First, one cannot assume nondesign 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 our time. I wanted to focus on idea generation rather than evaluation—or worse, spending time teaching heuristic analysis to people who would have little use for that skill in their day-to-day work. Second, 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 I’ve often found heuristic analysis useful, I wanted to find an alternative approach that would allow the design process to focus on maximizing idea generation. The approach I decided to take was twofold:

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

At this point, I had all the components in place for what I call a collaborative parallel design process. I’ll provide more details on this approach throughout the remainder of this article.

A Collaborative Parallel Design Process

My collaborative parallel design process comprises the following steps:

Identify a problem to work on.
Gather together a team of participants.
Introduce the participants to one another.
Review the requirements and evaluation criteria for a design problem.
Design independently for 10 minutes.
Present all participants’ design ideas to the team, allowing each participant 5 minutes.

Others can ask clarification questions, if necessary.
This is not a critical review session! Instead, evaluate through iteration.

Repeat the design and presentation cycle at least four times, ensuring each participant builds on at least one idea someone else has presented.
Have a group discussion about the final designs.

Figure 1 shows a diagram of this collaborative parallel design process.

Figure 1—A collaborative parallel design process

Preparing for a Collaborative Parallel Design Session

I’ve found six people to be the ideal 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 good pace. If you find that many more than six people want to participate, consider running multiple sessions. The collaborative parallel design process focuses on harvesting the ideas of individuals, so avoid doing group design sessions. Although group design is a valid approach, sometimes the group dynamic is not conducive to getting all ideas heard, and our goal is to maximize idea generation.

Participants require 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 the session is to address.

When inviting people to participate, I briefly explain the 8-step collaborative parallel design process I outlined earlier. I also note that participation is totally voluntary. People need to know from the start that their opinions are valued, so I let everyone know that the team is intentionally diverse. The wording of one of my invitations was as follows:

I’ve tried to pick a varied cross-section of people to participate. So if you’re thinking, But I’m not a designer, that’s what I intended. Your ideas are equally important to the success of the process.

Finally, I tell everyone that this process guarantees no specific outcomes for a released product. Ideas transform, business demands fluctuate, and change is constant, so it’s impossible to say when, how, or whether an idea from a project’s early ideation phase would ever get implemented. I want to assure participants that the process is important, even if it’s not apparent down the line how it influenced the final product.

When I conduct a collaborative parallel design session, I post the following points in the room for participants to keep in mind throughout the process:

Good ideas can come from bad designs. So 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 critical for you to be an attentive observer while others are sharing their ideas. Keep an open mind.
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 our last collaborative parallel design session, everyone said what fun they had participating. Done right, a collaborative parallel design session really should be an enjoyable experience all around.

Since collaborative parallel design is simple, you can hold sessions often, so team members quickly become familiar with the process. Over time, this should greatly reduce the amount of preparation time you’ll need for each session.

Communicating Requirements

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

clear and understandable to all participants
free of explicit or implicit design or implementation recommendations

The list of requirements for a collaborative parallel design session should be short—ideally five or fewer requirements. With only 10 minutes of design time, no one could consider and satisfy a dozen or more requirements. You should also prioritize requirements, so when conflicts arise, it’s clear which requirement it’s more important to satisfy. Along with requirements, include information about any limitations—such as issues you don’t want to consider or technical constraints relating to the project.

Participants should also know the audience for the product they’re designing. Though you’re asking participants to develop and share ideas from their own individual experience, all of them should still be aware of the user profiles for the product’s target audience. Share any personas or other user information that is relevant to the problem with them.

Creating a Conducive Design Environment

For a collaborative parallel design session, participants should capture their design solutions on paper. 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, and pencils are all you need. Ask participants to write down their ideas in whatever way works best for them—sketching pictures, drawing flowcharts, writing lists, or composing narratives—anything goes. There are only two requirements:

Identify your work. Have each person put his or her initials and the design-cycle number on each piece of paper—for example, MM2. This makes it easier to trace the evolution of ideas later.
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 and evolve—or it might go nowhere, but leave it to the process to figure that out.

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—whatever works for them.

Design is iterative. After each presentation, another design cycle follows. Participants can either refine their designs or start anew, but they must build upon at least one idea someone else has presented. (More than one is fine.) This natural selection process mimics genetic evolution—each generation inherits some traits from the last. The intent is for this evolutionary process to filter out the weaker ideas and preserve the fittest ideas.

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

While participants can put themselves in the role of a user persona or build upon their previous designs, they are not required to do either. Each design iteration can be a new beginning, as long as it’s informed by something from the last round of design presentations.

It’s important to note that a collaborative parallel design facilitator is also a participant. As a facilitator, I may occasionally offer gentle reminders—asking participants to stay on task or limit their questions to those that are necessary to clarify a presenter’s design intent—but other than that, I’m another active participant in the process.

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 actively to what they’re saying.

To facilitate successful presentations, I ask that observers limit themselves to clarifying questions that ensure they understand a design properly. You expressly want to avoid questions like Why did you do that? or Did you consider…? This way, presenters need not be fearful of harsh criticism, and observers do not busy themselves thinking of questions that conform to the heuristics. This allows presenters to present and observers to look and listen unencumbered, deferring evaluation until they can do it in private, during the next round of design.

Of course, observers should feel free to take notes—recording ideas, questions, and concerns they want to consider during the next design iteration. 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 design generation amplifies the strong ideas and minimizes 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 using an overhead projector, work this out—and test it—ahead of time to ensure you can keep things moving. And keep presentations as low-tech as possible—so less can go wrong.
Ask participants to gather around each 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—a conversation between colleagues.
Allow absolutely no multitasking. If someone cannot be without a BlackBerry, notebook computer, or mobile phone for 4 hours, this is not the right process 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 nonclarifying questions. If and when questions progress from getting clarification to criticizing a design, remind everyone that the presentation phase is about gaining understanding, not evaluating designs. Instead, you’ll implicitly evaluate designs through 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 during each successive round. As the facilitator, I usually present first during the first-generation design 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 very good idea to have a camera on hand to periodically photograph the team’s progress.

Analyzing Designs

Once you’ve completed four or more generations of designs and the individual designs have begun to converge, 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.

Along with the group discussion, I’ve found it effective to chart each individual design idea people generated during a session against the requirements it satisfied. I do this by creating a Design Ideas for Requirements Checklist, like that shown in Figure 2, using a spreadsheet in which each requirement is a column and each idea is a row. Going through each design in order, I pull out each core concept, giving it a description and an ID. For the ID, I use the format Participant / Round Number / Idea Number. To carry on with my earlier example, in the first round of design, the first idea from the participant with the initials MM would get the ID MM1.1, the next MM1.2, and so on. You can expect to get 50 to 100 unique ideas from each collaborative parallel design session.

Once I’ve populated the spreadsheet with requirements and ideas, I check off each requirement we’ve satisfied with one or more ideas. There is one additional column, which I’ve labeled Other/Unidentified, for ideas that don’t directly map to one of the identified requirements. Most often, ideas that fall under the Other column relate to either general performance or usability issues we hadn’t captured in the requirements. However, they sometimes point to overlooked requirements. This is especially true if a large number of ideas fall under the Other category.

Summing each column indicates the number of ideas that address each requirement. Although a high number might seem desirable, a low number may simply indicate a requirement for which the team converged on a solution very quickly.

Figure 2—*Design Ideas for Requirements Checklist*

Variations on the Collaborative Parallel Design Process

Here are some ideas for variations on the collaborative parallel design process that you could 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 daily, 4-hour sessions over several days, allowing them to complete more rounds of design and presentation.
multiple teams, focusing on the same problem—Run more collaborative parallel design sessions involving different participants, but using the same requirements. They may generate totally different ideas or converge on some of the same ideas.
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 its best 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, use the multiple-team variations of the collaborative parallel design process. Small groups of team members in distributed geographic locations can also 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.

In Conclusion

The genetic inheritance model that collaborative parallel design uses is a powerful mechanism for bringing about collaboration and driving 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. I’ve found collaborative parallel design to be an excellent way of generating a wealth of design ideas quickly.

Collaborative parallel design engages stakeholders in the design process by asking them to participate in design, not just inform it. It is empowering for nondesigners 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. Collaborative parallel design is a very effective tool you should consider adding to your UX toolkit.

Acknowledgement—Illustrations by Tammy Schatz Myles.

In Design Process | Teamwork

4 Comments

Jujupacker

April 6, 2010 3:35 AM

We are just about to embark on some idea-generation and design-game activities for particular areas of our site, so your article was very timely and provoked a lot of thought.

Here are a few other methods you could consider trying when analyzing designs, as alternatives to the spreadsheet Mike describes.

At the end of the workshop, ask participants to add heart Post-its to designs or elements of the designs they like best. This gives you some initial feedback to digest.

After the workshop has ended, document the pros and cons of each design against the requirements, using up and down arrows on the side of each design.

Pop the sketched designs, hearts, and up and down arrows up on a wall somewhere in the studio. Encourage further feedback from the team by leaving Post-its and pens near the designs for people to add ideas or comments.

Dave Davison

April 6, 2010 8:20 AM

I am familiar with the use of collaborative parallel design, supported by a person trained in graphic facilitation techniques.

We have been testing the process with virtual teams, using Webex or GoToMeeting conference services, integrating the visual interpretations of the graphic facilitator in real time, and as an archive for post meeting review and comment.

While your focus is as a UX designer, the collaborative parallel design process has many other uses in facilitating the generation and refinement of ideas from diverse groups of participants.

Brought to your Web site by a simple tweet from Peter Morville, I find your writing and subject-matter expertise valuable, although I am not a UX designer.

You might be interested in learning more about how our graphic facilitation techniques work with distributed, virtual groups.

Joseph Querijero

January 28, 2013 12:34 PM

Is there a project-size limit to using this approach? Is there a threshold at which the process implementation itself will slow down a project?

Is there a specific type of project that fits into this approach? It’s easy to visualize implementing this approach for new design; however, about 80% of projects fall under rearchitecture and maintenance phases.

Mike Myles in reply to comment from Joseph Querijero:

December 3, 2013 10:51 AM

The initial problem space needs to be well defined and bounded to a scale that a group can take on in the time allotted. Scope can be very high level and conceptual or quite detailed, but you need pick the scope and stick to it. There will obviously not be time to go from high-level concept to detail. Even so, concepts and details may both come to light as part of the process.

As for new versus existing projects, I’ve most often used this on existing projects, which, as you state, are much more common than brand new ones. In those cases, the team may pick a specific feature or workflow to focus on.

Again, it’s critically important to start with a well-defined and bounded problem space going in, so everyone stays focused on solving the same problem.

Mike Myles

Principal User Experience Architect at AgileAssets, Inc.

Austin, Texas, USA

A software designer since the mid-90s, Mike has worked with teams who were responsible for creating a wide range of Web and rich-client applications serving many varied industries. Before joining Continuum Managed Services, he was a key contributor to design efforts at Autodesk, Oracle, Unica (IBM), Chordiant (PegaSystems), and Bowstreet (IBM). Mike studied electrical engineering and computer science prior to cultivating a career in software design. He is an active member of IxDA, ACM, and the local New Hampshire and Boston chapters of UPA. When not busy improving product user experiences, Mike is an avid performing musician and songwriter. Read More