The Sociable Literacy Project masthead

contextual inquiry

contextual inquiry

collaborative design

collaborative design

paper prototyping

paper prototype

sticky note session

iterative prototyping

sticky note session

presenting ideas

sticky note session

interface exploration

post it note session

sticky note session

Participatory Design

An intensive form of user-centered methodologies, participatory design holds that a tool's intended users can and should have a productive say in its development. Because the design team includes some members who may have little knowledge of the technologies to be used and little experience with interaction or interface design, the team employs a number of techniques to elicit ideas from all its members. Developers turn the team's ideas into prototypes which are then brought back to the designers for iterative re-working. Some of our core techniques are described and illustrated on this page.

Contextual inquiry: after helping our young design members learn some basic techniques for observing and interviewing, we went into the habitual contexts in which reading among young adults takes place: public libraries and in children's homes. The photo shows some of our design team members visiting a child in her home, looking at her room, and asking her to tell them when and where she reads. Showing is a big part of the process also. The video clip below this paragraph shows a small team conducting a contextual interview in a high school student's home. The adult member of the team initially takes the lead but the younger design partners both ask relevant questions. The cat no doubt helps the young man write his paper for school. [1.6 MB, 1 min., Quicktime]

Collaborative design and brainstorming: activities vary. In one of the pictures on the right, the team is brainstorming about what a group of icons might look like. We were looking for metaphors that could be visualized to represent the different types or moods of annotations the team had earlier decided it might want to make available to readers. The key word or concept was represented in a word or two on a square of paper. Four blank squares were taped below. One team member sketched a concept on the first square and then went on to work on another 3 concepts. Thus each problem had 4 different approaches from the various team members and each team member contributed visual ideas to at least 4 of the concepts. We then reviewed all the ideas as a group, discussed the various ways the design concepts would work and the challenges of specific concepts given the resolution of screens and the size the icons would need to be, and tried to reach some consensus around 1-2 approaches for each concept. The results were conveyed to a trained designer for refinement and the designs were then reviewed by the group to see which ones they thought would work well.

Paper prototyping: In this example, we were working on specific questions both about functionality and interface representations for annotations. We provided small groups with interface elements we'd printed from screen shots of the current prototype. We also made an assortment of other art supplies available. Team members were asked to use the materails to build paper prototypes of additional interface elements. Groups then presented their design ideas and as much as possible demonstrated how their proposed interfaces would function. [1.1 MB, 30 sec., Quicktime]

Prototype investigation and use: Once some aspect of the application had been coded, design team members played with the resulting interface and functionality using a variety of both structured and unstructured explorations. Adult team members often discussed problems they were perceiving with their younger colleagues to elicit suggestions for improving the interfaces. [1.6 MB, 42 sec., Quicktime]

Sticky-notes sessions and analysis: Almost every activity, especially exploratory and evaluative ones, ended with a "sticky-note session." All team members were asked to write at least three notes in each of three categories of response: things he or she liked; things he or she did not like; suggestions for further development (new features, different interface designs). The whole team would then review the collection of notes and group them into piles of similar topics or ideas. Application developers would then take the rich feedback and work up a plan to make use of the most helpful suggestions and feedback. Finding out what people didn't like was really important in guiding the development of the application.