---

The Participatory Design Process

The challenge of designing usable computer-mediated tools
What is participatory design?
Steps in the participatory design process

General Description of the System and its Organizational Environment
Task Analysis
Comparing Usability Targets and System Performance
Revising/Creating the System

Challenges to evaluating interfaces in networked environments
Concurrent vs. linear models of design
Problems with participatory design today
Bibliography

The Challenge of Designing Usable Computer-Mediated Tools

• The complexity and power of computer-mediated tools -- "Computer-mediated tools, as compared with traditional technologies, can be extremely powerful and complex, doing a vast array of different things with enormous speed." Users must learn to use a vast array of features, with some functions requiring multiple choices and some tasks having multiple ways to accomplish them .  The power and complexity also lead to a higher probability that costly errors will be made.

• Emphasis on users with unusual abilities -- These tools emphasize individual differences in ability more than do traditional technologies.  There is far greater variability among users on performance with computer-mediated tools than when traditional technologies are used.  This variation is traced to differences in cognitive abilities as well as training, leading some to suggest that perhaps a significant portion of the population not ordinarily designated as disabled or disadvantaged might not possess the basic abilities necessary for effectively using computer-mediated tools.

• Sophistication of computer hardware and software designers and their discipline -- The designers of these tools are both sophisticated computer users and tend to have characteristics and abilities that are good for effectively using computers but which set them apart from the bulk of "ordinary" users.  It is extremely difficult for them to have good intuitions about what is useful or usable for ordinary users, especially novice users.

---

What is Participatory Design?

• Participatory design focuses more on relationships than things

"Focus more on relationships than things. Information technology can and should change relationships among people; that is where its chief value lies.  Information technology that changes the nature of relationships can change the fundamental features of a given complex system." (Computer Science and Telecommunications Board 1998)
 
• Participatory design honors emergent behavior

"Honor 'emergent behavior.' The new theories of complex adaptive systems hold that the adaptability of any system greatly depends on the "genetic variance" -- or pluralism of competing models --  within it. Therefore, information technology should allow the emergence of competing agents (or models or schema) and enhance their interrelationships."  (Computer Science and Telecommunications Board 1998)
 
• Participatory design produces "under designed" systems

Under designed systems "let new truths emerge. It is a mistake to set forth some a priori notion of truth or to try to design in totality (which requires an infinite intelligence in any case). Rather, one should under design a system in order to assist the emergence of new ideas." (Computer Science and Telecommunications Board 1998)
 
• Participatory design aims at producing usable systems

What is usability?  Usability is "[a system's] capability in human functional terms to be used easily and effectively by the specified range of users, given specified training and support, to fulfill a specified range of tasks, within the specified range of environmental scenarios" (Shakel quoted in Dillon 1994)

Notice the word "specified" in the Shakel quote. If the system or service to be designed is to be usable, the criteria for judging the system to be "usable" must be specified in advance: Which users will be supported? for doing which tasks? in which contexts? with what kind of training and support?

Participatory design is task(function)-centered

The user's focus is primarily on getting things done, not on "information search and retrieval". The user does not want to have to think about the process of search and retrieval, and designers should keep this in mind.

• Participatory design is an iterative process

We can outline a series of stages in the design process (see below), but design is a complex phenomenon which involves generating ideas, testing them, revising ideas, testing these, etc.

• Participatory design involves taking the attitude that you, the designer, do NOT understand what tasks should be performed or how to perform them. Only the clients understand this, and your job is to learn from them.

 

 
 
 
 
 
 
 

This attitude is of fundamental importance for doing participatory design. You must see the clients as the knowledgeable people, even if they are unable to articulate precisely what is required.  As some social scientists do when conducting research, you might find it useful to approach the task analysis as if you were a Martian:  question everything.  Don't assume that you know "why" people are doing what they do.  You can reassure yourself as to your competence by demonstrating your skill in eliciting from clients the insights you need in order to design a usable system!  Your clients are your equal partners.
 

• Participatory design involves users' participation throughout the design process

 

 
 
 
 
 
 
 

An important part of iteration is in users' involvement in the process. You do not simply study users' needs prior to the design phase and then forget about them until it is time to test the system or service. Translating the needs analysis during the design process involves a great deal of interpretation, which can lead designers off into directions which are not in the user's best interests. Users need to be consulted throughout the design process.

---

Top of page
Bottom of page

Steps in the The Participatory Design Process

While there is an overall linear order to the design process (from understanding users' needs to designing a system to meet those needs), it is important to keep in mind that it is also an iterative process.  The Neale and Kies article gives you a glimpse of how it is difficult to proceed in a strictly linear order when using participatory design.  Professional designers might be able to work from the general to the specific, first identifying broad categories or lists of users, tasks, and environments and only then focusing more narrowly on the details of items in these categories (steps 1 & 2).  Ordinary users, however, are more likely to feel comfortable communicating in terms of "microscenarios", where they describe vignettes or stories about what they want to do with the system.  You should use methods of discussion which your users feel comfortable with rather than forcing them into thinking in ways that are foreign to them.  Your goal is to understand how THEY think and feel about things, and the stories they tell should provide valuable details about the kinds of information system they need.

As a result of not forcing your clients into creating abstract lists which do not mean much to them and which you do not understand because you do not appreciate the context in which these categories occur in their lives, you may feel that you are being "drowned" in details without having the "big picture" about users' needs.  It will be up to you to generalize from the specific, if necessary, going back and forth from level to level until you have a full picture of what is involved.  For example, as you try to get a general picture of users, tasks, types of information, etc., record their "microscenarios" for future use in finding details about the scenarios, but try to verbally generalize from the story, asking for feedback about whether this is a correct interpretation.  Later, you can go back, when doing detailed scenario descriptions (see below), and use details from the microscenarios to complete the descriptions.  Meanwhile, the microscenarios will have given you important understanding of why certain tasks are important, how the user views his/her role vis-a-vis the task, elements of the task's environment, etc., all of which you will need as you proceed toward building a prototype of your system.  It is a delicate balance to keep on track and moving forward with your analysis while not stifling the natural expression of important contextual information.  See the Methods Learning Guide for more discussion of these issues.
 

General Description of the System and its Organizational Environment

Name and Location -- What is the name of the organization that is responsible for the system?  Where is it located?

Mission -- What is the mission of the organization?

Identification of Stakeholders --

Stakeholders are those people who have a stake in getting and using the information from the system you are designing. Identifying these stakeholders is critical to the success of the design process. In most cases, there will be several types of people -- inside and outside the organization -- who rely on certain types of information, and they may all need the information in slightly different formats, time frames, or levels of detail. As a designer, you need to know who these people are and what are their needs and expectations. If you only focus on a narrow idea of the user, you cannot hope to design the system so that it meets the organization's needs.

For example, let's say the chair of a department in a public library has asked you to design a system to help her/him produce monthly reports about departmental activities. You will need to know the expectations of all those people who need or want access to those reports: other library managers, members of the department in question, members of the library's governing board, government oversight committees, members of the public, etc.

This all seems so obvious, right? Then why are we surrounded by stories of how stakeholders are ignored in the design process? Here's a recent, real-life example: A physician in Indianapolis is puzzled by the fact that so many of his patients are not paying their bills. He begins to investigate the problem by asking his office manager to show him a sample of the bills which are sent to patients. When he gets one, he studies it and is unable to understand what it is telling the patient to do. He asks the manager to explain the bill to him, and is told that, to do this, the manager will have to call the record up on the computer. Why? Because there the print is big enough to read, and the information is not compressed into an unreadable format!  Why, the doctor asks, doesn't the manager buy other software? Because, he is told, they just bought the system they have! When patients are queried, they indicate that they were so frustrated by the bills that they shrugged their shoulders and tossed them in the wastebasket. Now why, you might wonder, would the needs of customers be ignored in a system which is designed, among other things, to communicate with them and whose compliance is necessary for the continued existence of the organization?

Environment --

What are the organizational, economic, political, social, and disciplinary  environments within which the task takes place? The task needs to be accomplished in a way which is in accordance with social, economic, political and disciplinary context and standards.  To illustrate how the environment of a task is important, think about your own class project and the environment in which you are undertaking it:

Organizational -- The main participants are you and your clients.  You are functioning within certain organizational constraints in terms of settings, people, expected or valued patterns of problem-solving and communicating (cf. Taylor's IUE).  In fact, you and your client probably both bring to bear on this "task" performance a host of organizations -- professional and personal -- which will affect how you accomplish your "task".

Economic -- You do not have unlimited economic resources for accomplishing this task, nor does your client.  You have limited access to money for travel, supplies, equipment, communications, etc.  Also under this category would fall time resources.  You have to get the project done by a certain date, and you and your client both have limited amounts of time to devote to it.

Political -- Take this term in a broad sense, as the ability to exercise power of any sort, which always involves the ability to martial people and material resources to suit your needs.  You have little power over whether or not you do the project (sorry!), but you have some power over how much help you get from other students, the Instructor, your spouse or coworkers, the clients or their colleagues, etc.  You may also have the power to get some time off from work to work on the project or to juggle your schedule so that it fits with accomplishing this task.

Social -- Outside of their roles in the organization, you will need to interact with a number of people in order to accomplish your goals.  How you interact with them will be dictated by a number of social codes, including how to interact with members of the opposite sex (according to the gender codes you and they adhere to) or of other ethnic, religious, age groups, etc.  These social codes and relationships cannot be ignored when designing an information system.  Information is communication, and there is no such thing as socially neutral communication.

Disciplinary -- You are expected to meet certain disciplinary standards in doing this project, standards set by the LIS field (standards such as the Customer Service Philosophy, professional participatory design practices, etc. These standards play a role both in determining how you accomplish the task and what constitutes a proper RESOLUTION or completion of the task.  (Their criteria for success may not be the same as yours!)

Task Analysis

Ah, the hidden complexities behind that seemingly simply word task!  A task is something people do because it overcomes obstacles to attain some value that is desired by the group.  With most organizational activities, there is a hierarchy of goals and steps taken to reach those goals.  On each level, a task can also be seen as a goal, and a goal as a task.

Should the determination of what "tasks" need to be supported by the information system come from the top of the organization?  the bottom?  customers?  Top-down development has the advantage of assuring that the tasks will be in keeping with the overall goals of the organization and that the information system which supports them will have the backing of the organization's leaders.  On the other hand, tasks identified as crucial by those at the top may be seen as insignificant by those who ultimately will carry them out.  Bottom-up development, where workers at the bottom of the organization generate the ideas for the tasks to be addressed by the information system, is more likely to be adopted by workers but may not have the support of those at the top, and the tasks identified may be too narrow or in conflict with higher-level organizational objectives.

Your work in identifying and describing tasks and environments will be made more simple by the fact that most people will, on an everyday level of existence, focus on performing discrete tasks such as creating and distributing a newsletter, researching and writing a report, sending out publicity about an event, etc.  While some of your system evaluation will involve the analysis of such discrete tasks, however, you must also understand the broader context of the problem-solving and value-seeking that frames these specific tasks if you are to design a system that will truly be user-centered.

During the preceding stage, you learned something about what the system is supposed to help different stakeholders do.  In this stage, your goal is to understand in detail:
 
• the tasks that the system is supposed to support
• how stakeholders interact with the system
• how stakeholders evaluate the system
Start with a description of the most important tasks and work down to the less important ones.  Answer the following questions for each task:
 
1. What is the name of the task?
2. Why is the task important to stakeholders (mission)?

 

 
 
 

What are the broader goals of the stakeholders regarding the task? The level of generality is relative, of course, ranging from the types of goals stated as the "mission" of the organization down to "objectives" to achieve the mission and "activities" to achieve the objectives.  Make sure you understand the hierarchy of values being expressed here.  You need to know WHY a task needs to be performed.

Continuing with the example of your own project, what are your broader goals in doing this project?  (Learning how to do something? Getting a good grade?  Finding out more about your clients or improving your relationship with them?  Proving to yourself that you can be an information professional or finding out if LIS is for you?) What about the goals of your clients or other stakeholders (for example, the Instructor)?  How do these goals shape the way the task should be done?  Which of the goals is more central to the task than others?  You need answers to the questions like these if you are to understand the task and know how to design a system to complete it.
 

3. What stakeholders are involved with performing this task?
1. Where is the task performed (= setting)?
1. What special resources are needed this task (economic, political, social)?
1. What sub-tasks are required to complete the task?

 

 
 
 

Let's take you as an example again.  The general task is to design an information system for your client.  What more specific tasks are involved in doing this?  Your list will include tasks such as "evaluate the system"  "redesign the system", "prepare a report", etc. For better or for worse, the Instructor has designed an information system to help you accomplish some of these tasks but not others.  For example, this information system offers quite a bit of support for understanding how to analyze the client's information assets and design the system.  However, less information is available for  supporting preparing reports and revisions.  This is based on the assumption that graduate students will be in quite experienced in preparing reports so that the system does not need support those tasks.
 

2. What information acts are involved in performing this task (= locating, acquiring, using, storing, retrieving, or evaluating information; information strategies and tactics necessary to complete the task)?
What actions aimed at locating, acquiring, using, storing, retrieving, or evaluating information, including information strategies and tactics, are necessary in order to complete tasks?  You might be surprised by how many information acts go into even a quite specific task.  Interviewing, for example, entails locating people to interview, finding out when and where you can meet with them,  discovering what form of recording medium can be used at the interview site and whether the client will agree to recordings, learning how to construct an interview protocol, explaining the rules of the interview to the client, asking questions, recording responses, evaluating answers to determine what follow-up questions to use, deciding what strategy of questioning to use in the interview, etc.  What support from the course information system is provided for these tasks?  There is not much support for helping you record your interview data so that other students and the Instructor might access it in order to offer helpful suggestions.  This was not done because of the confidentiality of the interview data, but could it have been arranged while protecting the interviewees?  Would the sharing of reports via a class web page or print copies have been helpful?
 
1. How do stakeholders interact with the system to perform the task (= system interaction)?

 

 
 
 

How must the stakeholders actually interact with the system, assuming that it is only one of possibly many information sources, a tool in information acts?  This question assumes that your "system" is only a computer.  In this class, we are assuming that your system design will include different types of media in  addition to computers, depending on the needs of your client.  The telephone is the most common form of Information Technology, after all, and most people use a variety of information sources in accomplishing tasks.  It is important that your design shows the interrelationship between different types of resources.  One of the common errors information professionals make is in assuming that the computer could and should be used for most if not all parts of the task performance, and not enough attention is paid to the seamless integration of different media.

 
Getting back to your project example, the seemingly simple act of "calling for an appointment" will involve interactions with the phone system such as:  looking up a number in a print directory, storing the number for future reference, engaging in an interchange about times and places, recording that information, etc.  Your research may take you to the web site of your client, in which case you will want to record some of the site's information which you find useful in your analysis.  Or you may engage in email exchanges with the client, which you need to store and analyze.  How could the class information system have supported all these information acts?  Would it have helped to have a personal web page for your report, containing a linked data base in which you could both get ideas about types of information to put in it and ways to organize and analyze that data?
 
2. What do stakeholders view as a successful outcome for this task (= resolution)?
1. How do stakeholders evaluate the effectiveness of their use of the system for various tasks ( = evaluation)?

 

 
 
 
 
 

Usability Criteria

So far, we have discussed usability primarily from the point of view of utility -- the usefulness of a system to help the user get his or her work done. However, you will want your system to be "usable" in other ways. Jacob Nielsen has defined four categories of usefulness (cited in Balasubramanian 1994):
 

2. Utility -- This is a measure of whether the system actually helps a user perform the intended task.  What will your utility target be?  What has to occur for the task be considered to be successfully completed?
1. Integrity -- This is a measure of how complete the system is - whether it provides information which is up to date, accurate, and if it is easy to maintain. What will be the criteria for determining that the information provided is current or accurate or that the system is easy to maintain.
1. Aesthetics -- How pleasing is the system to use?  Aesthetics comes last in Nielsen's list of usability criteria. Much of the work on information systems assumes a rationalist model of the user, where speed and accuracy are preeminent. But Carroll and Thomas (1988) rightly point out that people are not simply focused on "outcomes", but also attend to the experience of using a system. If ease of use and learning imply simplicity, fun requires some complexity.  Optimal human experiences appear to involve a balance of novelty: too little and we experience boredom; too much and we become anxious (see, e.g., Mihaly Czikszentmihalyi 1990).  Carroll and Thomas discuss some of the ways in which the techniques of computer games might be applied to more practical tasks in order to improve performance and increase the likelihood that people will use information systems.
How pleasant should the system be, and how will you determine when the requisite level of pleasure has been reached?
 
1. Usability -- Usability can be measured as a combination of these factors:
• Ease of learning -- How fast can a user start learning and using the system?
• Ease of use -- How fast can a user locate information?
• Error handling -- How many errors do users make and how easy is it for them to recover from such errors?


If possible, set numerical values as the targets for each task.

Top of page
Bottom of page

Comparing Usability Targets and System Performance

By now you have a good idea of what tasks are needed and why, the environment in which they take place, and how stakeholders evaluate the system in terms of performing tasks.  Based on this knowledge, and working with your stakeholders:
 
1. List the usability targets for each task, including targets for:
• Utility
• Integrity
• Aesthetics
• Ease of learning
• Ease of use
• Error handling


If possible, set numerical values as the targets for each task.

Based on your research so far, take each task and describe the usability targets that stakeholders have noted are desirable ones if the system is to be considered successful.  These targets should be as specific and measurable as possible.  Vague targets (e.g., "should be easy to use") will not be helpful when it comes time to describe how you would evaluate the system.  The more specific you can be, the better.

Setting targets sounds simple, but it is a complex and difficult task, especially since you are likely to be working on a multi-disciplinary design team where different members may disagree about the issues.  Your client stakeholders will also have different ideas about which kinds of usability are more important, and where targets should be set. Tognazinni (1992) provides some suggestions about techniques that can help the design team set usability targets.
 
1. Compare system performance with usability targets.

 

 
 
 

Based on your observations, how close does the system come to meeting all the targets on the list?  In what ways do they fall short? Why?

Top of page

Revising/Creating the System

[Your class may be limited to describing on paper how the system should be revised.  If so, what follows is for your edification for future projects, when you must actually revise a system or create a new one.]
 

Iteration Through Prototypes (Models)

Now that usability targets have been set, you can begin creating a prototype or working model of your system revision or creation.  Tognazinni describes two types of prototype:

• Horizontal prototypes - They display most or all of the full range of the product without going into depth on any one part. Use to test the overall design concepts.

• Vertical prototypes - They take the user deep into the behaviors of specific parts of the system. Use them when dealing with new design concepts and technology.


This means, simply, that you start with a rough sketch of the basic elements of the system, test that, then, gradually, work toward a full working model.  Because of the time limitations for this class, you will not have time for multiple iterations of models.  However, it is advisable that you start with a crude sketch on paper to begin with, especially if your project involves a lot of database or html coding.  It is a lot easier to cross something out on a piece of paper than to do a lot of recoding.

Hint:  This is advice that most students do NOT want to follow.  When they don't, what usually happens is this: They spend a lot of time among themselves, busily coding.  With so much time gone by and deadlines approaching, they hurredly test the model with stakeholders.  They find that there are sometimes fundamental errors that reveal some basic miscalculations about the system or misunderstandings of users.  They are faced with having to go back almost to the beginning, and now have little time to make the necessary changes.  Panic and depression set in.

A prototype is a tool for testing your ideas, so do not think that it has to be slick or professional looking.  "Prototypes can and should be created in a matter of days, not weeks and months" (Tognazinni 1992: 82).  Find a technique that is easy to modify as your ideas develop.  Possibilities include poster board with post-its, a notebook with replaceable and rearrangeable sheets, 3 x 5 index cards, or a page layout program where objects may be quickly moved around.

You should be thinking of the usability targets as you develop the prototype.  Which arrangement will make it possible to meet those targets?

This is slow and tedious work, and you will go through numerous revisions until you have what you think is a testable first version of the prototype.   Allow yourself plenty of time for this stage, and be patient.

While working on your prototype, keep in mind Donald Norman's (1988) 7 design principles for addressing achieving usability:
 

1. Use both knowledge in the world and knowledge in the head.

Provide the user with a clear mental model of the system and how it works. Make the principles of system operation observable. All actions should be consistent with the conceptual model of the system. The visible parts of the system should reflect the current state of the system.

1. Simplify the structure of tasks.

The user should not be required to remember more than about five unrelated items at one time because of the limits of short-term memory (STM), Information should be integrated into some conceptual framework because of the limitations of long-term memory (LTM).

Methods for simplifying tasks include:

Keep the task much the same, but provide mental aids.

Use technology to make visible what would otherwise be invisible, thus improving feedback and the ability to keep control.

Automate, but keep the task much the same.

Change the nature of the task.

1. Make things visible: Bridge the gulfs of Execution and Evaluation.
1. Get the natural mappings right. Make sure the user can determine the relationships between:

Intentions and possible actions

Actions and their effects on the system

Actual system state and what is perceivable by sight, sound, or feel

The perceived system state and the needs, intentions, and expectations of the user

1. Exploit the power of constraints, both natural and artificial.
1.  Design for error. Support, do not fight, the user's responses. Treat the interaction as a constructive dialog.
 
1. When all else fails, standardize.
Top of page
Bottom of page

---

Continuous Evaluation and Redesign Until Design Targets Are Met

"Test your prototype with your client.  One of the great myths of our time is that user testing is so time-consuming, expensive, and divisive that it should be primarily discussed, rather than actually undertaken. The truth is that user testing can be really, really cheap and really, really easy to do. It can even save you money -- lots of it....Inexpensive testing should be done by members of the design team as part of a cooperative effort to produce the best [product] possible." (Tognazinni 1992: 79, 81)

Some quick and inexpensive methods of evaluation include:

• Observations of users interacting with the prototypes and "thinking aloud" while they work. This results in a concurrent verbal protocol which can be studied to see where users are having problems.  (See Think Aloud Observations and Building a Prototype.)
• Observations of users interacting with the prototypes and interviewing them as they are work.  This participant observation method allows the designer to form hypotheses about what is going on and test them immediately, through questions.
Some of your readings provide examples of other types of evaluation.

Stop testing when your prototype meets the usability targets you established and the scenarios you have chosen to support are fully supported.  For example, if you are developing a system to support career counseling for MIS students and one of its targets is to enable prospective MIS students to apply for admission and financial aid through the SLIS home page, without any additional communications to other IU offices, and without having to go through more than three screens of information, then you stop testing when this scenario is fully supported using your prototype.

Be prepared to find many errors even after several testing cycles. Landauer 1995 provides numerous examples of how it can take many, many iterations before a system meets usability targets.

Implementation, Use, User Reinvention

Many descriptions of the design process stop with the last step, implying that the designer's job is done once the system is built and delivered to the client.  Especially in the dynamic and complex environments of networked systems, however, the implementation, use and user reinvention of the system are critical to the ultimate usability of the system.  Even the best information assets analysis and prototype testing can not anticipate all of the factors that will come to bear on the use of the system in the real world over time.  Implementation involves a complex process whereby the new system or service is introduced into the existing environment of the organization.  "During implementation, the new  technology must be adapted to work in particular user settings even as users must learn new behaviors and change old ones to take advantage of it....the effectiveness of the implementation process itself has a substantial impact on the usability and usefulness of social applications somewhat independently of their design features" (Computer Science and Telecommunications Board report 1998).  Any new information service or system will entail the learning of new behaviors and/or attitudes and accommodation to new social relationships.  This is never easy, and must be carefully attend to in order to assure the usability of the product or service.

Because of the severe restrictions of time and experience we face in this class, you will not be involved with the project beyond the testing of your working model.  You should be aware of the importance of the steps we are omitting from the design process.

Top of page

Bottom of page

Challenges to Evaluation of Interfaces in Networked Environments

• The social nature of network computing -- Much of research on user-centered design has focused on planning for specific applications which are to be used by a single individual.  As the Internet has become increasingly important in our society, however, it has become increasingly important that computer-mediated tools be tested in networked environments, where widely different groups of people are collaborating.  The Internet is essentially a social medium, and adds an extra layer of complexity to the design process.  Users are widely distributed physically as well as intellectually, and are thus more difficult to include in the participatory design process.

Interdependency and critical mass -- "Unlike computer applications for individual use, groupware not only presupposes but also requires a multiplicity of users for its functionality to be experienced and evaluated."  A critical mass of users must adopt such applications if they are to provide benefits to individuals, and this adoption by communities of users is slow and difficult to study.  Evaluation also involves study of different kinds of broader social benefits.

Concurrent vs. Linear Models of Design

In the types of networked design environments mentioned above, the authors of the Computer Science and Telecommunications Board report (1998) make a strong case for the replacement of a strictly linear design process, especially for the development of networked systems.  The design process described above describes design and evaluation, but does not mention implementation and use of the system, implying that these processes are discrete steps, which take place in a linear order rather than concurrently.  These authors argue that new, networked computer-based technologies emerge too rapidly to allow the leisurely use of "research with representative population samples to ensure the usefulness and usability of social applications before their implementation and use".  In such a situation, it would be better to think of the various design steps (DESIGN, INTERATIVE TRIALS, REDESIGN, IMPLEMENTATION, USE, USER REINVENTION) as concurrent or overlapping.  Beta testing of some software products takes uses an overlapping design model, taking advantage of the real-world experiences of hundreds of users while the system is still being designed.  Concurrent engineering "builds on rapid prototyping approaches that draw no sharp boundaries between prototype trials with representative users, field pilot projects, and early-stage implementation processes (...). Finally, it takes into account the unfeasibility of 'getting it right the first time' as a guiding principle for NII applications." Computer Science and Telecommunications Board report 1998).  This is another way of saying that the designer has to adopt the attitude that the design proces is never static or "finished".  Development is constant and rapid.

For the purposes of this class, with its severe time limits and lack of prior design experience of students, we are going to adopt a pedagogical -- and linear -- approach to the class projects.  While keeping in mind that real professional design of an information system or service should take a concurrent or overlapping approach, for these first design experiences we will simplify the process.  First you have to learn a few simple scales before you can perform a symphony!

Problems with Participatory Design Today

Some of the problems practicing user-centered design today include:

• A lack of appreciation of the benefits of user-centered design by designers or those to whom designers report (e.g., when supervisors reward designers for the speed of product development rather than the degree to which the product meets customers' needs).

• A lack of training in user-centered design methods (e.g., when designers employ poorly planned ethnographic methods or use only methods which do not supply information about context).

• Adoption of a narrow understanding of what user-centered design is (e.g., when developers extract information through market surveys and then design without further input from users).

• Cultural values which emphasize designer creativity or bravado rather than empathic understanding of the user (e.g., when "creativity" and intuition take precedence over understanding and communication).

• Poor communication between design team members, or between users and designers (e.g., when engineers will not listen to those in direct contact with customers).

• Product development is technology- rather than user needs-driven (e.g., when new features are added to software although this actually leads to declines in usability).

Top of page
Bottom of page

---

Bibliography

Carroll, John M. (1995). The scenario perspective on system development. In J.M. Carroll (ed.), Scenario-based Design: Envisioning Work and Technology in System Development. New York: John Wiley.

Carroll, John M. and John C. Thomas (1988) Fun. SIGCHI 19(3): 21-24.

Computer Science and Telecommunications Board (National Research Council) (July/August 1998) Design and evaluation: A review of the state-of-the-art. D-Lib Magazine http://www.dlib.org/dlib/july98/nrc/07nrc.html

Czikszentmihalyi, Mihaly 1990 Flow. The Psychology of Optimal Experience. New York: Harper & Row.

Dillon, Andrew (1994) Designing usable electronic text: Ergonomic aspects of human information usage. London: Taylor and Francis.

Dillon, Andrew (1995) Artifacts as theories: Convergence through user-centered design. http://www-slis.lib.indiana.edu/PrePrints/adillon-artifacts.html

Eason, K. (1988) Designing the technical system for human use, ch. 8 in Information Technology and Organisational Change, pp. 129-156. London: Taylor and Francis.

Erickson, Thomas (1996) Design as storytelling. Interactions 3(4) (August).
HCI95: People and Computers (UK) Conference.

Holtzblatt, Karen and Sandra Jones (1993) Contextual inquiry: A participatory technique for system design, ch. 9 in Douglas Schuler and Aki Namioka (eds.), Participatory Design: Principles and Practices, pp. 177-211. Hillsdale, NJ: Lawrence Erlbaum Assoc.

Landauer, Thomas K. (1995) User-centered design methods & User-centered development, chs. 12 & 13 in The Trouble with Computers, pp. 277-322. Cambridge, MA: MIT Press.

Lewis, Clayton and John Rieman (1995) chs. 1-2 in Task-Centered User Interface Design: A Practical Introduction, ftp://ftp.cs.colorado.edu/pub/ cs/distribs/clewis/HCI-Design-Book/HCI95;URL: http://www.hud.ac.uk/events/hci95/tutorials.html

Neale, Dennis C. and Jonathan K. Kies (1996) Scenario-based design for human-computer interface development. (6 pp.)

Nielsen, Jakob and Darrell Sano (1994)  SunWeb: User Interface Design for Sun Microsystem's Internal Web.   http://www.sun.com/sun-on-net/uidesign/sunweb/ 

Norman, Donald R. (1988) The psychopathology of everyday things (ch. 1) & User-centered design (ch. 7), in The Design of Everyday Things, pp. 1-33, 187-217. New York: Currency Doubleday.

Sano, Paul (1996) Limitations & constraints for users, in Designing Large-Scale Web Sites, pp. 66-77. New York: John Wiley.

Tognazinni, Bruce (1992) Brainstorming & Scenarios, chs. 13 & 14 in Tog on Interface, pp. 67-78. Reading, MA: Addison-Wesley.

Tognazzini, Bruce (1996) Tog on Software Design. Reading, MA: Addison-Wesley.