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

  • Published on
    29-Dec-2015

  • View
    216

  • Download
    1

Embed Size (px)

Transcript

  • Overview of the Design ProcessAvoid Bad Design, Use UCD Good vs. Bad Design User-centered Design (UCD) process- Individual steps

  • AgendaGood vs. bad designUser-centered Design (UCD) processIndividual steps

  • 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!

  • The Good

  • The Good

  • The Bad

  • The Bad

  • The Bad

  • The Ugly

  • The (really) Ugly

  • But What Makes it Good?!FunctionalitySpeed & efficiencyReliability, security, data integrityStandardization, consistencyUSABILITY !

  • 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.

  • Good Design MeansSystems are built for humans; must be designed for the userRecognize individual differences; appreciate design implications of these human factorsRecognize the design of things, procedures, etc., influences human behavior and well-beingEmphasize empirical data & evaluationRely on the scientific methodThings, procedures, environments, and people do not exist in isolation

  • Good Design Is Not NOT just applying checklists and guidelinesThese can help, but UCD 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 questions

  • Design (Sidebar)Start reading Don Normans DOETWell return to design as a focus topic in few weeks

  • User Centered DesignA way to force yourself to identify and consider the the relevant human factors in your designHelps reduce the number of decisions made out of the blue, and helps focus design activitiesHelps document and defend decisions that may be reviewed later

  • The Tao of UCDDESIGNIMPLEMENTUSE &EVALUATE

  • UCD: 9 Step OverviewDefine the ContextDescribe the UserTask AnalysisFunction AllocationSystem Layout / Basic DesignMockups & PrototypesUsability TestingIterative Test & RedesignUpdates & Maintenance

  • Design ImplicationsAt each stage, consider how the details of your discovery process affect your design

    FactImplicationsUsers 16-80 yrsRange of text sizesRange of grip strengthSome French speakersMultilingual interfaceAstronaut usersExtensive training availableMilitary contextAesthetics less of an issueRuggedness is critical

  • 1. Define the ContextContext: the type of uses, applicationsLife critical systems, applicationsIndustrial, commercial, military, scientific, consumerOffice, home, entertainmentExploratory, creative, cooperativeMarketCustomer (not the same as the User)Design Impacts?

  • 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

  • 3. Task AnalysisTalk to and observe users (NOT customers) doing what they doList each and every TASKBreak tasks down into STEPSABSTRACT into standard tasks (monitor, diagnose, predict, control, inspect, transmit, receive, decide, calculate, store, choose, operate, etc.)

  • 4. Function AllocationConsider 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 passwordBase this on knowledge of system hardware, software, human users abilities, culture, communications protocols, privacy, etc.Allocation constraints: Effectiveness; Cognitive/affective; Cost; MandatoryDont forget the design implications!

  • 5. System Layout / Basic DesignSummary of the components and their basic designCross-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)

  • 6. Mockups & PrototypesInformed BrainstormingRAPIDLY mock up the user interfaces for testing with real peoplePen and paper or whiteboard to startIterate, iterate, iterate!!Increasingly functional & veridicalList audio & visual details at same levels of detail in the prototypes(i.e. dont forget either of them)

  • 7. Usability TestingGet real (or representative) users to do what they do, using the prototypesSubjective and objective feedback. Sometimes users want features that actually yield poor performanceVideo tape, lots of notesBe rigorous wherever possible (stats, etc.)Feedback into the iterative evaluation & redesign of the systemDiscount usability testing can be very effective, using fewer subjects, more rapid results

  • 8. Iterative Test & RedesignRepeat cycles of testing and reworking the system, subject to cost/time constraintsFocus on Functionality First !Plan for several versions during development

  • 9. Updates & MaintenanceIn-the-field feedback, telemetry, user data, logs, surveys, etc.Analyze and make iterative redesign/test recommendationsUpdates and maintenance plan as part of the design!(design it so it can be fixed or updated)

  • UCD: 9 Step OverviewDefine the ContextDescribe the UserTask AnalysisFunction AllocationSystem Layout / Basic DesignMockups & PrototypesUsability TestingIterative Test & RedesignUpdates & MaintenanceDesign Implications?!!

  • 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?

    Quick, quick!

    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?

    Functionality

    Speed & efficiency

    Reliability, security, data integrity

    Consistency,

    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...