1. Overview of the Design Process
Avoid Bad Design, Use UCD
Good vs. Bad Design
User-centered Design (UCD) process
- Individual steps

2. Agenda Good vs. bad design User-centered Design (UCD) process
Individual steps
Fall 2002
CS/PSY 6750

3. Good Design (reminder!)
“Every designer wants to build a high-quality interactive system that is admired by colleagues, celebrated by users, circulated widely, and imitated frequently.” (Shneiderman, 1992, p.7)
…and anything goes!…
Let’s start by broadening out concept of “application”, and recognizing that we could be designing anything from a tractor to a PDA application. So our motto from this point is, “ANYTHING GOES!”. Anything, that is, which satisfies all the requirements and constraints as outlined in our design process.
Fall 2002
CS/PSY 6750

4. The Good…
First, let’s quickly look at a range of designs, in a variety of fields. Some of them are good, like this seat adjustment system. What makes it good?
Fall 2002
CS/PSY 6750

5. The Good…
What about this one? What are some of the features that makes this a good design?
Fall 2002
CS/PSY 6750

6. The Bad…
Not all designs end up being good… Seriously, wat went wrong with this design? Someone made it thinking it would be very easy to use. No one INTENDS to make an awkward design… but how do we avoid it?…
Fall 2002
CS/PSY 6750

7. The Bad…
Even designs that we consider “classic” or “standard” can be bad, for one reason or another. “It has always been done like that” is NO EXCUSE for a poor design!!
What are two things that could be improved here? (S-R compatibility of controls; reaching over the burners to get to the controls)
Fall 2002
CS/PSY 6750

8. The Bad…
Much of what you will be designing is visual…software is largely visual, Web pages, signs, and so on. So you need to pay extra attention to the visual world you create.
This is from a road in Mexico. You can see this, and other examples at baddesigns.com. So which way should you go?
Quick, quick!
It really means do not go to the right.
Fall 2002
CS/PSY 6750

9. The Ugly…
This is an actual intersection in California. Ugly. Just ugly. But what makes it so bad?
Clutter, small signs, competing signals. If you were turning left, which light is “yours”?
Fall 2002
CS/PSY 6750

10. The (really) Ugly… Fall 2002 CS/PSY 6750
Uhh, this is an actual web page! It’s not even fake!
What do these people sell?
What is their address?
And what is up with that background image?!!
Fall 2002
CS/PSY 6750

11. But What Makes it Good?! Functionality Speed & efficiency
Reliability, security, data integrity
Standardization, consistency
USABILITY !
So what is it that makes a design GOOD?
Functionality
Speed & efficiency
Reliability, security, data integrity
Consistency,
BUT MOSTLY, USABILITY
Now, how do we get there?!! How can we make good designs?
Fall 2002
CS/PSY 6750

12. Closer to Fine: A Philosophy
…The human user of any system is the focus of the design process. Planning and implementation is done with the user in mind, and the system is made to fit the user, not the other way around….
It starts with a PHILOSOPHY that puts the human in the center of the design, regardless of what the product or application is. Somehow, somewhere, a human will be affected by your design.
Fall 2002
CS/PSY 6750

13. “Good Design” Means
Systems are built for humans; must be designed for the user
Recognize individual differences; appreciate design implications of these human factors
Recognize the design of things, procedures, etc., influences human behavior and well-being
Emphasize empirical data & evaluation
Rely on the scientific method
Things, procedures, environments, and people do not exist in isolation
There is a secret society known as Human Factors professionals. Some of us are engineers, some psychologists, some work in other fields.
We all share a common set of principles (and a secret handshake), that include the following:
Systems are built for humans; they must be designed for the user
Recognize individual differences; appreciate the design implications of these factors
Recognize the design of things, procedures, etc., influences human behavior and well-being
Emphasize empirical data & evaluation
Rely on the scientific method and test hypotheses
Things, procedures, environments, and people do not exist in isolation
Fall 2002
CS/PSY 6750

14. Good Design Is Not… NOT just applying checklists and guidelines
These can help, but UCD is a whole philosophy
NOT using oneself as the model user
Know your real users; recognize variation in humans
NOT just common sense
Knowing how to design a fire alarm so it will be heard over background noise is not something we all know.
The HF specialist knows where or how to get the information needed to answer design questions
Now, many people claim us use Human Factors in their designs… and many do.
But let me say a few words about what Human Factors is NOT:
NOT just applying checklists and guidelines
These can help, but USD is a whole philosophy
NOT using oneself as the model user
Know your real users; recognize variation in humans
NOT just common sense
Knowing how to design a fire alarm so it will be heard over background noise is not something we all know.
The HF specialist knows where or how to get the information needed to answer design questions
Fall 2002
CS/PSY 6750

15. Design (Sidebar) Start reading Don Norman’s DOET
We’ll return to design as a focus topic in few weeks
Fall 2002
CS/PSY 6750

16. User Centered Design
A way to force yourself to identify and consider the the relevant human factors in your design
Helps reduce the number of decisions made out of the blue, and helps focus design activities
Helps document and defend decisions that may be reviewed later
User Centered Design is a way to help you identify the human factors that will be important in your design.
It is not foolproof. It does not replace training, experience, and practice.
But it can help. It will drastically reduce the amount of things you need to consider in your design. It will help you focus. And it will document your design process, which may be needed if you have to hand the project off to someone else, or if you ever have a problem with the product. You can go back and retrace the design decisions
Fall 2002
CS/PSY 6750

17. The Tao of UCD DESIGN IMPLEMENT USE & EVALUATE Fall 2002 CS/PSY 6750
As I mentioned, User Centered Design is a philosophy, a Tao, a Way, a path.
It is a circular path, including the original design, an implementation of the design, use and evaluation of the design, and further changes to the design.
There is no real starting or ending point. You may think that Design is the first thing. Ahh, grasshopper, you would be mistaken. See, even when you create the first design of something, you bring into that all the previous experience you and other users have with other things in the world. So which comes first, the design or the implementation or the use and evaluation?… I’ll leave you to meditate on that…
USE &
EVALUATE
Fall 2002
CS/PSY 6750

18. UCD: 9 Step Overview Define the Context Describe the User
Task Analysis
Function Allocation
System Layout / Basic Design
Mockups & Prototypes
Usability Testing
Iterative Test & Redesign
Updates & Maintenance
There may not be a start or a stop to the Tao of UCD, but there are some steps to help you get through it.
Here is an overview. I’ll quickly describe each step, and then come back to this summary. Remember that I am flying through all this. This is merely an introduction to the concepts here. You’ll get a chance to practice all these things in your homework assignment, but don’t feel like you need to know it all right now.
Basically, you must learn by doing.
Here we go:
Define the Context
Describe the User
Task Analysis
Function Allocation
System Layout / Basic Design
Mockups & Prototypes
Usability Testing
Iterative Test & Redesign
Updates & Maintenance
Fall 2002
CS/PSY 6750

19. Design Implications
At each stage, consider how the details of your discovery process affect your design
Fact
Implications
Users yrs
Range of text sizes
Range of grip strength
Some French speakers
Multilingual interface
Astronaut users
Extensive training available
Military context
Aesthetics less of an issue
Ruggedness is critical
Fall 2002
CS/PSY 6750

20. 1. Define the Context Context: the “type” of uses, applications Market
Life critical systems, applications
Industrial, commercial, military, scientific, consumer
Office, home, entertainment
Exploratory, creative, cooperative
Market
Customer (not the same as the User)
…Design Impacts?…
First off, you need to determine what the context is.
Note that this is not the specific local environment, but rather the larger type of world that your system needs to exist in. …
And most importantly, WHAT ARE THE DESIGN IMPACTS OF THE CONTEXT?!!!
Fall 2002
CS/PSY 6750

21. 2. Describe the User (!!)
Physical attributes (age, gender, size, reach, visual angles, etc…)
Physical work places (table height, sound levels, lighting, software version…)
Perceptual abilities (hearing, vision, heat sensitivity…)
Cognitive abilities (memory span, reading level, musical training, math…)
Personality and social traits (likes, dislikes, preferences, patience…)
Cultural and international diversity (languages, dialog box flow, symbols…)
Special populations, (dis)abilities
Next, describe your user. Know your user.
This is certainly the most crucial step, and in your homework, the step that I want you to spend the most energy on.
Consider their:
Physical attributes (age, gender, size, reach, visual angles, etc…)
Physical work places (table height, sound levels, lighting, software version…)
Perceptual abilities (hearing, vision, heat sensitivity…)
Cognitive abilities (memory span, reading level, musical training, math…)
Personality and social traits (likes, dislikes, preferences, patience…)
Cultural and international diversity (languages, dialog box flow, symbols…)
Special populations, (dis)abilities
Fall 2002
CS/PSY 6750

22. 3. Task Analysis
Talk to and observe users (NOT customers) doing what they do
List each and every TASK
Break tasks down into STEPS
ABSTRACT into standard tasks (monitor, diagnose, predict, control, inspect, transmit, receive, decide, calculate, store, choose, operate, etc.)
Once you know the Context and have described the User, you need to know what the users actually do in relation to this system.
In a professional system, this is a critical element, since it is often the case that no one person can describe what goes on. And certainly the Human Factors engineer or the designer may not know in detail what a fighter pilot or assembly line worker, or a kid interacting with a new GameBoy does.
Remember that this is about the USER, not the customer. Often the customer is very different from the USER.
You observe, take notes, videotape, use computer keystroke and mouse movement software, eye-tracking, etc. It can be a big deal.
You list all the things the person and system does, then try to abstract it into generic tasks. This lets you know what is going on.
Fall 2002
CS/PSY 6750

23. …Don’t forget the design implications!…
4. Function Allocation
Consider the whole system!
Decide who or what is best suited to perform each task (or each step)
e.g., system remembers login id, and reminds the user, but user remembers the password
Base this on knowledge of system hardware, software, human users’ abilities, culture, communications protocols, privacy, etc.
Allocation constraints: Effectiveness; Cognitive/affective; Cost; Mandatory
…Don’t forget the design implications!…
Then, once you know the tasks that are occurring, you can decide what needs to be done by the various parts of the system. Remember to think outside the box, and to feel empowered to re-allocate tasks that have traditionally been allocated to a particular part of a system.
Base your allocation on what you know about the system elements. Most importantly, include what is known about human abilities and limitations. For example, the complex task of exploring and navigating may be best left to a human, but the task of remembering a long series of numbers may be best left to a computer system. Don’t forget the requirements of the Context, such as cost, failsafe behavior, minimum performance, and so on.
Fall 2002
CS/PSY 6750

24. 5. System Layout / Basic Design
Summary of the components and their basic design
Cross-check with any Requirements Documents; Human Factors refs; Hardware specs; Budgets; Laws (ADA); etc.
Ensure that the system will support the design and comply with constraints
(Verification and Validation, in the language of software engineering)
At this point you create a summary of the system components, often with an overview of the larger system in which they fit. If you were designing a spreadsheet, you might describe the whole office suite briefly. Then you get into the elements of the spreadsheet components.
You create a basic design, and layout.
You then cross check this with the specs that you have, the constraints, requirements, and so on.
Fall 2002
CS/PSY 6750

25. 6. Mockups & Prototypes “Informed Brainstorming”
RAPIDLY mock up the user interfaces for testing with real people
Pen and paper or whiteboard to start
Iterate, iterate, iterate!!
Increasingly functional & veridical
List audio & visual details at same levels of detail in the prototypes
(i.e. don’t forget either of them)
Based on the layout, you can create simple prototypes of the system. If it is visual, you can sketch it. If it is a physical object, you might quickly build it out of clay. Sounds can either be described, or mocked up as well.
The point is speed, and not accuracy. You are building a prototype, not a finished product.
Crude methods are just fine !! Pen and paper, whiteboard, whatever.
Fall 2002
CS/PSY 6750

26. 7. Usability Testing
Get real (or representative) users to do what they do, using the prototypes
Subjective and objective feedback. Sometimes users “want” features that actually yield poor performance
Video tape, lots of notes
Be rigorous wherever possible (stats, etc.)
Feedback into the iterative evaluation & redesign of the system
“Discount” usability testing can be very effective, using fewer subjects, more rapid results
Then you have people use the system prototypes, as best they can. You can do a sort of wizard of oz thing where you work with them to make believe what would happen if they clicked a certain button, or moved a joystick in a given direction.
You take lots of notes, videotape, and so on, and try to get all the reactions you can. Encourage the person to talk aloud as they do this. Try not to interfere, as much as that is possible.
Note that very useful information can be gathered from a very small number of users, at this stage. Later on you will need more people, but for now, just a few is fine.
Again, I am not going into all the details of how to conduct usability testing here. This is not a course in that. The main thing you need to know is that it exists, that you should use it, and that it is helpful.
Fall 2002
CS/PSY 6750

27. 8. Iterative Test & Redesign
Repeat cycles of testing and reworking the system, subject to cost/time constraints
Focus on Functionality First !
Plan for several versions during development
Then you go back and do it all again!
Plan to do several iterations of testing, redesign, and more testing.
Of course, in the real world you need to live within the limits of cost and time, but fight to include a few iterations at the very least in your design process.
Fall 2002
CS/PSY 6750

28. 9. Updates & Maintenance
In-the-field feedback, telemetry, user data, logs, surveys, etc.
Analyze and make iterative redesign/test recommendations
Updates and maintenance plan as part of the design!
(design it so it can be fixed or updated)
One last point that is often overlooked is including updates and maintenance of whatever you design.
Be clear about how you will evaluate your system once it is out in the wild, how you will design it to be upgraded, and so on. Fo rexmaple, if you know that web browsers are changing constantly, then figure out how your design will accommodate that.
Fall 2002
CS/PSY 6750

29. Design Implications?!! UCD: 9 Step Overview Define the Context
Describe the User
Task Analysis
Function Allocation
System Layout / Basic Design
Mockups & Prototypes
Usability Testing
Iterative Test & Redesign
Updates & Maintenance
Okay, so here is the overview again. These are listed in the handout, and these slides will be available on your web site.
Design Implications?!!
Fall 2002
CS/PSY 6750

30. UCD: Focusing Your Efforts
There are real-world constraints
Cutting out steps is not the way to economize!
Optimize the efficiency of each step
Here: Focus on the context and the user, to get the most value for the time spent
A few final points about focusing your efforts in UCD.
There are real-world constraints
Cutting out steps is not the way to economize!
Optimize the efficiency of each step
Here: Focus on the context and the user, to get the most value for the time spent
Fall 2002
CS/PSY 6750