Review of the Collaborative Prototype Design Process (CPDP)

Ok my fellow designers; let’s talk about prototyping.  It’s time to bust out of your singular shell and dive into the concept of… wait for it… team prototyping!  In the never ending quest for all of us to squeeze out every ounce of insight and productivity in our teams I submit to you my review of an interesting article I recently stumbled upon:

Collaborative Prototype Design Process (CPDP) by a large group of designers at Texas Tech University, Lubbock:

CHRISTOPHER ANDREWS                        ELIZABETH E. POHLAND

DEBRA BURLESON                                    DANIELLE SAAD

KRISTI DUNKS                                            JON S. SCHARER

KIMBERLY ELMORE                               RONDA L. WERY

CARIE S. LAMBERT                                 MONICA WESLEY

BRETT OPPEGAARD                               GREGORY ZOBEL

Yes, CPDP is yet another acronym to file away into your brains.  You’re welcome.  Hang in there with me, I think you’ll enjoy this concept as much as I did and hopefully allow you and your team to bring new insights from your users to your UCD goals.

So what is this CPDP you speak of?  Here is the high level abstract from the authors:

“To build upon user-centered design methods, we used a collaborative and multi-modal approach to involve users early in the design process for a website.  The CPDP is an innovative approach to user-centered website design that emphasizes collaboration, iterative testing, and data-driven design. The CPDP balances the power and needs of users with those of designers and, thus, enables design teams to test more tasks and involve more users. “

Here is my 30 second elevator pitch on the method:  Towards the beginning stages of your prototyping process, break your team up into small groups, let them tackle it individually, then regroup and share the findings with each other.  You’d be surprised at the depth of insights this group of designers found on this project.

Here is diagram they came up with for the CPDP process:

One of the “light bulb” moments I had when reading this article was how this process could help alleviate some of the obstructions common to teamwork (e.g., groupthink, brainstorming problems, domineering personalities, and cognitive tunneling).  By breaking people up into teams you minimize these problems over the entire team as opposed to individual teams.

Now that you’ve seen the high level, let’s take a look at the process, methods used and results of their findings in a real world example.

The design team in this article was tasked with creating a website for a group of doctoral students who attend an annual two-week education seminar.  Their version of the CPDP process was broken down specifically as follows:

One team of 12 designers that divided into three independent design teams to separately:

• identify the user group

• develop and test three independent paper prototypes for the same website

• evaluate and interpret data

• create three wireframes of a website

• test those wireframes for usability with representative samples of users

• gather and analyze data per team and collaboratively across teams

• merge designs to create one final, user-driven prototype of the website

So let’s follow through on the four stages proposed in CPDP:

  1. Define your user group.  The users in this example were a very diverse group of people that would be attending this seminar from various countries with vastly different perspectives.  The teams spent considerable time conducting surveys and interviewing users to better understand them.
  2. Paper Prototypes Developed.  Three four-person teams each created low fidelity paper prototypes like the following examples:

Team
A’s paper prototype: whiteboard technique.

Team B’s paper prototype: poster technique.

Team
C’s paper prototype: sticky-note technique.

3. Developing and Testing Wireframes.  After testing their paper prototypes each team then built a wireframe based on their observations.  They then created a number of task based exercises to put in front of target users, using their completed wireframes.  The following Venn diagram illustrates some of those tasks:

The three teams used a variety of facilitation methods during the testing of their wireframes.  Personally I found these extremely helpful and plan on implementing them in the testing of not only the team project that I’m working on for HCDE 518 but for the usability work I’m leading at my current employer:

“The three teams used a variety of facilitation methods: TAP, Active Intervention, and Retrospective Recall. TAP [24], as previously defined, is a method in which the user speaks throughout the test to explain his or her thoughts and justifications for actions in relation to the tasks. During Active Intervention, a protocol defined by Dumas and Redish, one member of the team sits with the user during the test and prompts him or her with open-ended questions to encourage the user to explain his or her thought processes [25]. In Retrospective Recall, the user completes the tasks in the test, and then one team member questions the user about his or her experiences during the test.”

4.  Developing Final Prototype Testing.  Each team analyzed the data from their independent testing of their wireframes then came together as a group to make comparisons and discover the unique insights they generated.

Results

This is the really fascinating part. I think the authors of this article did a great job illustrating how the three independent wireframes were merged into one final prototype.   By working independently but on the same project each team came up with entirely different results by using CPDP.  Below are screenshots of the team’s findings:

This screen shot you see below is the result of the three independent teams not influencing one another by combining the most important pieces of their individual work into the final prototype:

Overall I think CPDP has great promise for larger teams. One aspect that I wish would have been addressed was how the authors felt this could be adapted for smaller teams.  For myself, working in a startup with a small team I would be curious if they had any research that supports their model in that setting.  This would apply to my 4 person team currently testing our mobile app.  How would that translate?

Although I had many great take aways from this article the one that resonated with me most with CPDP is the potential for minimization of group think and dominating personalities.  My experience in the world of team design is that UCD has the potential of being negatively impacted by people “going along with the team” or giving in to the loudest person in the group.

CPDP is one of many processes we as designers have in our arsenal to defend well thought UCD.  The authors of this article supplied us with some compelling evidence on why we might want to give it a try.

Enjoy, Tony

Advertisements

One thought on “Review of the Collaborative Prototype Design Process (CPDP)

  1. Hi Tony,
    Thanks for the kind and thoughtful review. I know that I and other co-authors were happy and grateful to read your review.

    While we did not test smaller groups (like four or five as you indicate), I think you could safely break down four people into two pairs. I don’t think that having three or four solo operators would work nearly as well; pairs is cutting it a bit close, but it could still work.

    An essential element in creating the effective group work was the consistent work and collaboration (at least 4-6 hours per day six days a week). This intensity helped gel groups, surface problems/issues, and move things along quickly.

    Best,
    gz

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s