UserCentered Design Dr Jonathan Lazar CIS 435 UserCentered

User-Centered Design Dr. Jonathan Lazar CIS 435

User-Centered Design n n We always talk about understanding the user, but we can’t just assume we know what the users want, or guess it We MUST involve the user in the design process, one way or another If you don’t understand the users, whatever you build will not meet their needs! “KNOW THY USERS FOR THEY ARE NOT YOU!”

About UCD n n User-centered design: a series of structured activities to involve the user in development of computing systems Also known as: n n Human-Centered Design Usability Engineering Inclusive design (w/ underrepresented users) Different from: n n Usability Testing (one step of UCD) Experimental Design/Research Design

About UCD-core principles n n Early focus on users and their tasks Empirical measurement n n n Measure quantitatively (not “did you like it? ”) Determine trends…is user performance going up after each iteration of an interface? Iterative design n n Have multiple potential designs; there are millions of potential designs, you need to try different approaches! Design is not an optimization problem!

Why do UCD? n n The earlier you discover a problem related to the interface, the cheaper it is to fix! Large interactive systems take a lot of time and money to develop n n But small techniques to clarify user needs related to the interface and to the tasks, can result in big return on investment Lessen the likelihood of project failure, or user rejection!

But you can find lots of different models of UCD (From Hartson and Pyla, the UX Book)

Here’s another! From http: //www. ilink-systems. com/portals/0/uxdesignlifecycle-img. jpg

And here’s another! From: https: //s-media-cache-

And yet another! From: https: //www. linkedin. com/pulse/20140702065138 -9377042 engineering-and-design-processes-usability-engineering-vs-usability-design

UCD in your other classes? n n n Systems Development Lifecycle (SDLC/ Waterfall Model--CIS 379/ITEC 411) Web Development Lifecycle (CIS 475) Community-Centered Design (Preece) Scenario-Based design (Carroll) All include user involvement in different stages

Understanding human-centered design (technology isn’t even mentioned!) n Understand specify the context of use n n Specify the user requirements n n n n Develop outline design proposals with multi-disciplinary input Make the design solution(s) more concrete using simulations, mock-ups, etc. Show the design solution(s) to users and allow them to perform/simulate tasks Evaluate designs against requirements n n n Provide a clear statement of the human-centered design goals Set appropriate priorities for the different requirements Include and statutory or legislative requirements Provide measurable benchmarks against which emerging designs can be tested Produce design solutions n n the characteristics of the intended users and other stakeholders the tasks the users will perform the environment in which users will use the system Assess whether user and organizational objectives have been met Provide feedback to improve design. Iterate the process until design objectives are met

Hesitation n There may be some hesitation in involving users: n n n Not previously done in the organization Developers do not have experience with UCD Developers are not comfortable with users There are costs involved (and as we know, the benefits can sometimes be hard to measure) Contracts did not specify it, so there is no way to enforce it Not sure how to do UCD

How complex a situation are you designing for? From Hartson and Pyla, the UX Book

User involvement n n Users must be involved in the development of any type of computer interface Don’t use proxy users, use real users In the past, users weren’t always involved in systems development This led to many failed IT projects (some estimates are 70% of IT projects fail)

Benefits of user involvement n For designers and developers… n better understand system and UI requirements n n n include all essential features don’t include superfluous features (feature creep) For users… n n gain a sense of ownership (it’s harder to reject something that you helped to build!) have realistic expectations of the system being developed

Are customers always users? n n n People who make IT procurement decisions may be customers, even though they may never actually use the product! Parents often purchase educational software for their children Ask yourself if the users are different from the customers who make the purchasing decisions!

Stages of user involvement n There are many different methods for user involvement and UCD activities n n n Early-stage involvement Late-stage involvement All-stage involvement

Requirements Gathering n It is important to understand who the users are, and what they need n n Put another way: n n Users Tasks Environment/context Functional requirements, data requirements, environmental (social/org/context) requirements, user requirements Without UCD, you may have a bad interface with the right tasks, or vice versa

Druin’s Model of User Involvement

One way to think of it… n n n User involvement activities are the “ingredients” Lifecycle models are the “recipes” You have to balance the user needs and the business needs n n n But you first have to understand the business needs No business will knowingly do something that hurts What are constraints? Political issues? Technical challenges? Privacy/policy challenges? User complexity?

Example- Healthcare info systems n n Most designers don’t really understand what goes on in a hospital Doctors are often against full computerization of records (change!), but the Affordable Care Act (Obamacare) is starting to require this There are multiple privacy laws Did you know that patients are often referred to by bed number, instead of name?

You’ve heard this elsewhere… n Something like 70% of information technology projects fail n n Never make it to completion OR Are rejected by the users Even scope creep is sometimes due to not understanding the needs You must really understand who users are, what they want to accomplish, and what environment/context they are in

Early-stage Involvement n n n n n Surveys Focus Groups Interviews Ethnography Time Diaries Scenarios Personas Analyzing existing documentation JAD sessions-Meetings with all stakeholder groups Cultural probes

Surveys n n n Can be paper, web-based, or e-mail Good at getting shallow data from lots of people Must pick a good sampling methodology Make sure that questions are clear and unambiguous Lots of web-based tools to help

Focus groups and interviews n n n n Good for getting deep data from few people Focus groups: multiple people Interviews: one or two people Must have an experienced moderator Be willing to change line of discussion Focus groups: synergy is good, domination by one group member is bad Anonymity is especially important

Ethnography n n n Traditionally used in the social sciences Needed when the context of usage (groups, organization, politics, environment) is complex Spectrum of participant/observer Use when there is a high chance of failure In HCI, used most often in understanding homes, workplaces, and schools

Contextual Inquiry n n n Gathering detailed descriptions of user or customer work processes and environments Interviews with users/customers AND Observations of work practice occurring in real-world context The user is more in control, and helps interpret the observations Think of MTV’s “the Real World”

Scenarios n n Scenarios are day-in-the-life stories of what happens when users perform typical tasks (storyboarding) Scenarios can represent common or emergency situations, novice or expert users Help define user requirements, or help users understand what is possible, or help other stakeholders understand important issues Scenarios are typically fictional, use cases/best practices are similar, but usually real

Example of a Scenario n A seventh grade social studies teacher is teaching a unit on the industrial revolution. He wants to make use of primary source material that would illustrate the factors that facilitated industrialization, the manner in which it occurred, and the impact that it had on society and on the built environment. Given his teaching load, he only has about four hours total to locate and package the supplementary material for classroom use.

Example of a Scenario n Marissa, a 10 th grade physics student, is studying gravity and its role in planetary motion. She goes to the virtual science lab and navigates to the gravity room. In the gravity room, she discovers two other students, Randy and David, already working with the alternate reality kit, which allows students to alter various physical parameters (such as the universal gravitational constant) and then observe effects in a simulation world.

Do a storyboard of a scenario!

Personas n n Personas are rich descriptions of the typical users of the project, to help the designers understand who to design for Not real users, but a synthesis of a number of real users who have been involved in data gathering You may have multiple personas if there are multiple targeted user groups Includes user skills, attitudes, tasks, and environment

Example Personas

UCD doesn’t need to be formal or expensive (from Druin and Kids. Team) n n Start with an interface that needs redesign Give users post-it notes, and ask them to write 3 notes for each: n n What you like about the current design What you don’t like about the current design Ideas for the next design Facilitator organizes them into common theme areas

Informal post-it note sessions n n Moderator takes the post-it notes and groups them into common themes, and they are discussed Users are broken into a few groups, given a bag of arts and crafts, and asked to make non-technical prototypes Moderator takes the best ideas from each of the prototypes ALWAYS BE OPEN TO DIFFERENT IDEAS!!

Medium-to-Late Stage Involvement n Paper Prototyping n n Card Sorting n n Or other cheap mock-ups Used to discover user mental models Both focus on information structuring Both are known as “guerilla HCI” or “quick and dirty usability” Cheap methods to gain useful feedback

Card sorting n n n Card sorting helps developers understand how users structure information in their own minds Card sorting is quick and cheap Get a pack of index cards List each content item (web site), or each command (application) on a separate card Number the cards 5 -10 users? No more than ~50 -60 cards?

Card sorting n n n Shuffle the deck of index cards Ask the user to sit down and sort the cards into piles of related items (use rubber bands or clips) Then ask the user to give a name to each pile, using post-it notes Users can create as many piles as make sense to them Look for commonalities (do a cluster analysis or just eyeball it) How often are items placed together? That tells you how information should be structured!

Prototyping n Low-Fidelity n n n Medium-Fidelity Electronic n n n Somewhat interactive Include simple widgets High-Fidelity Electronic n n n Abstract (paper, poster board, sticky notes, etc. ) Very general feedback about terminology and navigation More interactive Include complex widgets Purposes of each are different

Low fidelity: paper prototyping n Provides substantial user feedback, rapid iterative development, maximum feedback for minimal effort, when it’s still easy to change the entire approach

Medium-fidelity prototyping tools n n n Looks technical but is not fully functional! Wireframes: more for designers than users Whatever is fast and easy n n Flash Visual basic Powerpoint Developer tools n n Adobe Illustrator (in our labs) Cloud-based such as n Balsamiq, Mockingbird

Late stage involvement n n n Users need to be involved before this, to understand what they need You can’t build it if you don’t understand what they need Major type of late-stage involvement is in Usability Testing n n n Various different forms of usability testing (e. g. “Wizard of Oz technique”) Usability testing is a separate lecture

Basics of usability testing n n Representative users performing representative tasks Task-based, not inspection-based Can take place with early prototypes or fully functional versions Can have more impact, with early versions of interfaces, and early usability testing, when it’s easier to make changes n Major changes won’t be made at the last minute!

The caveat… n n n Realize that you won’t use all of these methods There is a limit in terms of time and cost And also user patience… You figure out, in advance, which methods are the most useful Those were the various ingredients, each UCD lifecycle model might use different amounts in different proportions

All-stage Involvement n Participatory Design (PD) n n n Users are involved in all stages of design, on the design team Originated in the Scandinavian countries Commonly used when: n n n Tasks are not well-understood Application/interface is life-critical or mission-critical for an organization Special user population (e. g. users with severe impairments)

Participatory Design n Reasons used in Scandanavian countries and US are different: n n n Worker rights (Europe) High-risk projects (healthcare, education, nuclear power plants, etc. --US) Used rarely in the US, but very interesting when it is used

Evaluation n n Evaluation is very important Different usage of the term: n n n Evaluation before the finished product (e. g. usability testing) Evaluation after the finished product (e. g. consumer surveys, feedback form, more usability-like testing) When people talk about evaluation, they often mean after-the-fact, but it doesn’t necessarily mean re-design

Evaluation after the fact n n n n Are users satisfied? Are users productive? Were any major problems uncovered? Has the user base itself changed? Has traffic (for a web site) changed? Does it still meet the needs? Periodic evaluations are necessary Important to look at the people NOT using it to determine why not

User support n n User support should not be an afterthought (as it usually is!) It should be included as part of requirements gathering e. g. : n n n Wizards Context-sensitive help Searchable help Help videos Online help documents (used less often)

Re-design of interfaces n n n Many times now, we’re not building a new interface, we’re re-designing an existing interface It’s a good opportunity to get good UCD practices in place (you’re never far from another new development cycle) Example: MTA web site, first re-design in 7 years (2003/2010)

MTA web site in NYC re-design

New MTA web site design

UCD: It’s never too late! n n n If a site wasn’t built with good UCD practices originally (or if it just hasn’t been updated over time), insert the good UCD practice during the next re-design Each re-design becomes a new lifecycle Even if an interface isn’t usable now, even if nothing’s being re-designed, start talking about UCD for the next lifecycle

Cost-justifying usability/UCD n n How do we cost-justify usability? The costs wind up being easy to measure and are incurred today The benefits are harder to measure, and are realized in the future We do a cost-benefit analysis and estimate some potential benefits, in terms of actual dollars

Cost-justifying usability/UCD n n n Figure out how a usability improvement might impact user task performance time on a commonly-used screen or device Be conservative Figure out, over a year, how often that screen is viewed throughout the organization

Different types of costjustification n Internal organizational systems n n Off-the-shelf products n n Increased sales of items on the site (fewer dropped carts) Informational web sites n n Increased sales of the software or hardware E-commerce web sites n n The value of employee time Fewer phone center calls, fewer paper materials Classic book on cost-justifying usability, Bias and Mayhew, 1994, updated in 2005, check out Marcus article on Blackboard