I think the term “Participatory Design” is somewhat self explanatory—design that includes the participation of all stakeholders. However, I think that the significance of a participatory approach deserves some further exploration. In Chapter 1 of Observing the User Experience (2003), Kuniavsky put forth a fable that I think beautifully illustrates the importance of stakeholder participation in the design process. In this story, a company decides they will design the next big media advance. They spent a lot of time, effort, and money developing “Typhoon.” They were convinced it was going to blow people away. Before releasing Typhoon, they decided to test it out with a few users just to placate the executives. The results of these tests were disastrous. Users didn’t understand what it was for or how to use it. To make a long story short, Typhoon was a major flop (Kuniavsky, 2003, 3-8).
As designers, we often think that we know exactly what a user wants. The Typhoon fable demonstrates that that is not necessarily the case. Throughout this course, we’ve learned about many different methodologies for collecting feedback from the user (e.g. surveys, focus groups, interviews, ethnographic research, etc.). Participatory design utilizes several of these approaches (particularly focus groups and interviews) in an iterative process that includes stakeholders in multiple feedback cycles throughout the design process (Kuniavsky, 2003, p. 468).
This philosophy originated in Scandinavia as an attempt to involve workers in the design of systems they’d be using in the workplace. Its original name “Cooperative Design” was changed in the United States to Participatory Design because managers wanted to keep themselves aloof from the workers they managed. In other words, they wanted to keep the hierarchy in place while still collecting feedback from the workers (Participatory Design, 2010).
I found an interesting article by Kenneth Fleischmann (Florida State University) that suggests participatory design should actually be more “cooperative” as the original title suggests. He provides two case studies that illustrate that eliminating the hierarchy between designers and users, and thereby creating a hybrid user-designer can be very effective (Fleischmann, 2006). Kuniavsky states that one of the weaknesses of the participatory approach is that the users begin to think like designers and no longer provide insight from outside the design box (2003). Fleischmann’s examples contradict this claim and support the potential for users to be integrated into the design team.
Both of the case studies deal with the development of learning simulation software (frog dissection in a K-12 setting and cadaver dissection at medical schools). In the frog case, the design team was made up of former biology teachers who had become simulation designers. The cadaver dissection team was made up of a combination of gross anatomy instructors and simulation designers. One member of the cadaver project team said that it was essential to have a hybrid team made up of both users and designers. “Through such collaboration…anatomy instructors with no simulation design expertise and simulation designers with no anatomical instruction expertise can work together to create useful tools for the classroom” (Fleischmann, 2006, p. 94).
I think that part of the reason this article resonated with me is because in many ways it reflects my own experience in the design process for this class. As a former Geometry teacher, I would consider myself—as Fleischmann terms it—a hybrid user-designer. My technical knowledge of the math has helped our team ensure that our design accurately represents a real-life application of trigonometry. I also think our team has found it helpful to have a former teacher on the team to provide unofficial feedback throughout the design process relating to how a teacher might use the app in the classroom. (After holding a focus group with several teenagers last week, I think it would have been helpful to have one of them on the team as well!) I have been convinced by Fleischmann that Participatory Design should indeed be more “cooperative” – that an integrated team of user-developers can create an effective product, especially when designing for a technical content area.
Works Cited
Fleischmann, K. (2006). Do-it-yourself information technology: Role hybridization and the design–use interface. Journal of the American Society for Information Science and Technology , 87-95.
Kuniavsky, M. (2003). Observing the User Experience. San Francisco: Morgan Kaufmann Publishers.
Participatory Design. (2010). Retrieved March 27, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Participatory_design
Design+Research 
Great posting Bethany! I wanted to comment on a specific effort that has developed at work, and has failed due to the e-learning team not participating in a participatory design approach.
One of my co-workers created a course, and did not have any of the stakeholders reviewing the material. When the course was completed, it was shipped out to the stakeholders and government for review. The stakeholders and government did not approve of the course. Now, the team is working diligently to save the course and to make the stakeholders and government happy.
If only the stakeholders would have worked with the team in the creation process, this particular e-learning project would and could have been successful.
I agree, when creating any project, the stakeholders, review team, and any other members of the project should have reviews per each step of the development phase. This saves time and effort, ensuring everyone is on board with the project from start to finish.
By: miller451 on March 30, 2010
at 3:01Z03
I believe particpatory design is essential to the design process. I’ll even go as far to say that I think all stakeholders should have some type of role in the decision-making and problem solving aspect of a product rather than soley being involved in the evaluation.
Although, I think participatory design can have some shortcomings. Sometimes it doesn’t work, specifically in the corporate environment, because of politics and policy. Sometimes the policy making of a few individuals or departments can affect the entire design and other stakeholder input is considered null. I’ve worked on projects where existing policies in place affected the design of the course, even though the main users suggested something otherwise.
By: Alison on April 1, 2010
at 3:01Z04
I love the idea of participatory design the way it was meant to be – with several stakeholders involved – users, designers, decision-makers, etc. I don’t like it when a design involves a dictator. Someone I know told me at their workplace, there is no time allotted to gather feedback from actual users – just the decision-makers.
This one-sided form of participatory design greatly resembles scope creep because in many cases feedback from decision-makers varies and the general direction of a project changes which creates more work. While a change in direction can be beneficial to the final product, it can also be not such a good thing if the additional changes and new ideas are thrown out or scrapped for the original idea which at times results in wasted time, effort, and resources.
By: J on April 7, 2010
at 3:01Z04
By: Jesse
By: Jesse on April 26, 2010
at 3:01Z04
April,
It’s too bad that your team has had that experience. It seems like the standard ADDIE model leaves the revies/evaluation to the end of the process, but as your example demonstrates, getting stakeholders involved earlier in the process allows feedback to be incorporated early in the design process so that changes can be made before development is complete.
By: Bethany on April 9, 2010
at 3:01Z04
I enjoyed reading Bethany’s article about participatory and cooperative research. Like Bethany, I am a former teacher and approach instructional design from that perspective. I too have noticed how it gives me a different perspective from team members that have not had hands-on experience in teaching. So I can relate to the importance of including people in design that are directly involved in the learning process – both teachers and students. I think that the way that the stakeholders are included – whether it is more as peers (cooperative) or more hierarchical (participatory) – is usually related to the broader philosophy of the organization. So to change that for any specific workplace, you would probably have to get into the sphere of organizational development and change for the company as a whole – not an easy task!
By: Judith S. on April 17, 2010
at 3:01Z04
In my day job, my company frequently deals with DoD and defense contractors who build information technology (IT) tools and systems for warfighters with little to no input from the warfighter. Without significant warfighter input, many IT tools and systems (ranging from improvised explosive device [IED] databases to command and control [C2] systems) are developed in a user-void by defense contractors who convince DoD they have a “better mouse-trap.” When DoD fields one of these new tools or systems, the warfighter who had no input frequently finds the tool or system irrelevant, difficult to use and nearly useless. We have repeatedly found that the most useful DoD IT tools and systems are best designed and developed with the full participation of the end user – the warfighter.
In these days of tightening budgets and fiscal accountability, DoD is slowly learning that the best tools for national defense include participatory design by the end-user.
By: Jeff on May 10, 2010
at 3:01Z05