documenting the user experience: tools for building web sites jeffrey veen [email protected]

47
Documenting the User Experience: Tools for Building Web Sites Jeffrey Veen [email protected] http://adaptivepath.com/workshops/gospelcom/

Upload: hilary-poole

Post on 03-Jan-2016

215 views

Category:

Documents


1 download

TRANSCRIPT

Documenting the User Experience:Tools for Building Web Sites

Jeffrey Veen

[email protected]://adaptivepath.com/workshops/gospelcom/

Hi,

I'm remodeling my kitchen and buying new appliances. While researching my decisions, I visited your site to see how your refrigerators compared to other manufactures. One of the most important factors in my decision is the amount of energy the product uses -- but I couldn't find this information listed on your site anywhere. Am I not looking in the right place?

-jeff

Dear Jeff,

Thank you for visiting the Maytag Home Page. We welcome the opportunity to assist you.

Please forward your model number and we can send the energy rating for the model.

Eric

Maytag Customer Service

Eric,

I think you may be misunderstanding my query. I'm interested in buying a new refrigerator. One of my key decision-making points is the energy rating of the product. I'd like to be able to see the rating of all of your models on their respective product description pages.

-jeff

Dear Jeff,

Unfortunately, the energy ratings are not listed on the web page. Sorry for the inconvenience.

Jennifer

Maytag Customer Service

Jennifer,

Right. I realize that. That's why I mentioned it. It's a pretty crucial decision-making point for a lot of people (including me).

You should consider having your Web team add it to the standard product page.

-jeff

Dear Jeff,

Thank you for your comments regarding the Maytag.com Home Page.

In the future, please include the model number of your Maytag appliance so that we may assist you more efficiently.

Scott

Maytag Customer Service

Process and Deliverables

Research and DiscoveryPersonas and Scenarios

ArchitectureCard Sorting and Affinity Diagrams

Design and DevelopSchematics and Wireframes

ValidateUser Testing Protocol

Know Your Audience: Personas

What Is a Persona?

• A fictitious person for whom you are designing

• Represents the archetypal qualities of your audience

• Plural: “personas” not “personae”– It’s ... well ... less pretentious

Why Personas?

• Provides focus for the design– Talk about “Lori” not “the user”

• Humanizes the design

• Remarkably effective for bringing user-centered design into an

organization

Researching Personas

• Along with mental model, an output of the task analysis

research

• Market research and segmentation

• User interviews and observation

Developing Personas

Instead of building up tasks into mental models, build up various

personal attributes into personas

• Demographic– Age, Gender, Occupation

• Psychographic– Goals, tasks, motivation

• “Webographic”– Net usage and experience, gear, usage habits, favorite sites

Personalizing Personas

• Name them

• Have photos of them– Stock images, images.google.com

Personas Are Not:

• Demographic ranges– “18-34 year old college educated females making $50K”

• Job Descriptions– “IT managers in Fortune 1000 with purchasing power for routers”

• Your CEO– “Mr. Burns wants to be able to use his WebTV on the site”

Personas Are:

• Stereotypes– This isn’t an exercise in politically correct thinking– Edge cases can lead you off track, e.g. male nurses, frequent

flyers

• Design targets, not sales targets

• Tools for thinking about features and functions, not character

studies

Persona Chart

Steven Joy and Eric

Age27

OccupationManager, Aetna Insurance

Net usage5 hours per week, cable modem,

my.yahoo.com, cnn.com, theonion.com

GearDell Pentium III, 750Mhz, 17”

Trigger for actionWeekend project: install surround speaker

system

Ultimate Goalintegrated home theater system

Familiarity/AnxietyDo-it-yourselfer, last project: new deck

How Many Personas?

• 3 or 4 usually suffice

• Focus on one “primary” persona– Not necessarily the primary business target– The persona whom, if satisfied, means others will more likely be

satisfied

Personas in the Organization

• Turn personas into big posters, place throughout organization

• Encourage people to think about specific personas, not

“users”

Scenarios

• Stories of personas engaged in tasks or achieving goals

• Narrative structure enforces “making sense”

• The flow of writing feels more “real” than the discrete

collections of tasks and attributes

Writing Scenarios

• Keep the task focused – 4 to 5 paragraphs

• Incorporate the persona’s environment

• Make them messy

• Try not to design while writing

• Write three or four scenarios per persona

Benefits of Scenarios

• Allows for a holistic description of the user’s experience– Context, context, context– From inside the user’s head to the environment surrounding them

• Excellent communication tool – all humans understand stories– Works well across multi-disciplinary teams

• Fleshes out persona’s “existence”

Potential Pitfalls

• The Scenario Where Everything Works Like Magic

• Digressing too much

• Too much response from a designed system

Using Scenarios

• Help others understand users’ needs and desires

• Continually referenced throughout the design process– Keep your designs ‘honest’

• Provide a personal context to user research and design

Architecture

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

Home Office

WhereTo Buy

Business

Card Sorting

• Write key features and concepts on index cards

• Let users sort them by category, then importance

• Effective for testing before any design or code is done

• Results expressed through affinity diagram

Affinity Diagram: Step 1

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

Home Office

WhereTo Buy

Business

Affinity Diagram: Step 2

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

Affinity Diagram: Step 3

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

Affinity Diagram: Step 4

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

Affinity Diagram: Step 5

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

Affinity Diagram: Step 6

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

Affinity Diagram: Step 7

Products

Support Downloads About Contact Us

HomeWorldwide

Site Map

Developer Reseller

Supplier

Search

Legal InfoPrivacyPolicy

Labs

HomeOffice

WhereTo Buy

Business

1

2

3

4

56

Design: Wireframes and Schematics

Flow Diagrams

• Use standard symbols

• Include a Legend explaining the symbols

• Avoid crossing lines

• Include meaningful labels for all lines that need them

• Include error cases

Visual Vocabulary: http://www.jjg.net/ia/visvocab

• Follow all pathways to their natural end, OR

• Clearly mark where your flow connects with another flow

• Use good visual design principles

Schematics

• Make schematics that correlate to the flow diagram

• Use standard symbols to represent interaction devices

• Show all functions

• Use consistent names and labels across all flows and schematics

• DO NOT include any visual design direction

• Use call-outs to describe any functionality that isn’t self-explanatory

• Use good visual design principles

• One schematic can serve multiple pages

Usability Testing

Recruiting Users

• For a simple test, find 3-4 people similar to your site’s

audience– Friends, family, coworkers from other departments

• Personas should determine your test group

• Start immediately: the better the subjects, the better

the outcome

Recruiting Users

• Determine target audience– demographic/webographic/psychographic

• Seek them out– Existing user base, customer support inquiries, advertise

on existing site– User groups, email discussion lists– Traditional means: classified ads, etc.– Use a recruiter: Charge per user based on how specialized

your population needs to be

Developing a Protocol

• What is your site about?

• What five features are most important?

• Create a list of “tasks”– Two sentence mini-scenario for each feature

• For more focused tests, do a feature prioritization

exercise– Map feature importance with implementation difficulty

More on Tasks...

• Testable tasks should be:– Reasonable– Specific– Doable– Described as end goals– Appropriately sequenced– Domain neutral– Not too long, not too short

Running the Test (Mechanics)

• Have the room ready– Computer set up in a generic state– Have appropriate start pages bookmarked

• Make users comfortable– Describe how the test works and what they’ll have to do– Be clear that they are testing a product, they’re not being

tested themselves

Running the Test (Interview Style)

• Ask the right questions– “Describe this.”– “What do you expect?”– “Did that surprise you? Why?”

• Don’t offer help– If a task is too difficult for the user, tell them to stop and

ask them to describe what happened

Logistics

• Record the session with a camcorder arranged to

capture both the screen and user

• Have a partner take notes throughout session

• Convince decision makers of the value of watching the

tests – from coders to marketing to the CEO

Timing Activity

t –2 weeks Determine test audience, start recruiting immediately

t –2 weeks Determine feature set to be tested

t –1 week Write first version of guide, discuss with team, check on recruiting

t –3 days Write second version of guide, recruiting should be completed

t –2 days Complete guide, schedule practice test, set up and check equipment

t –1 day Do practice test in the morning, adjust guide/tasks as appropriate

t Test (usually 1-2 days, depending on scheduling)

t +1 day Discuss with observers, collect copies of all notes

t +3 days Watch all tapes, take notes

t +1 week Combine notes, write analysis

t +1 week Present to team, discuss and note directions for further research

Usability Test Timeline

http://adaptivepath.com/workshops/gospelcom/

[email protected]