UCD: Focusing Your EffortsThere are real-world constraintsCutting 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
Lets 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.First, lets 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?What about this one? What are some of the features that makes this a good design?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?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)Much of what you will be designing is visualsoftware 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?
It really means do not go to the right.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?
Uhh, this is an actual web page! Its not even fake!
What do these people sell?
What is their address?
And what is up with that background image?!!So what is it that makes a design GOOD?
Speed & efficiency
Reliability, security, data integrity
BUT MOSTLY, USABILITY
Now, how do we get there?!! How can we make good designs?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.
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 userRecognize individual differences; appreciate the design implications of these factorsRecognize the design of things, procedures, etc., influences human behavior and well-beingEmphasize empirical data & evaluationRely on the scientific method and test hypothesesThings, procedures, environments, and people do not exist in isolation
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 guidelinesThese can help, but USD is a whole philosophy NOT using oneself as the model userKnow your real users; recognize variation in humans NOT just common senseKnowing 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 questionsUser 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 decisionsAs 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? Ill leave you to meditate on thatThere 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. Ill 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. Youll get a chance to practice all these things in your homework assignment, but dont feel like you need to know it all right now.
Basically, you must learn by doing.
Here we go:Define the ContextDescribe the UserTask AnalysisFunction AllocationSystem Layout / Basic DesignMockups & PrototypesUsability TestingIterative Test & RedesignUpdates & MaintenanceFirst 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?!!!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
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.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. Dont forget the requirements of the Context, such as cost, failsafe behavior, minimum performance, and so on.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.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.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.Then you g...