Documenting the User Experience: Tools for Building Web Sites

1
Documenting the User ExperienceTools for
Building Web Sites

• Jeffrey Veen
• jeff_at_veen.com
• http//adaptivepath.com/workshops/gospelcom/

2
(No Transcript)
3
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
4
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
5
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
6
Dear Jeff, Unfortunately, the energy ratings are
not listed on the web page. Sorry for the
inconvenience. Jennifer Maytag Customer Service
7
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
8
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
9
Process and Deliverables
10
Know Your Audience Personas
11
What Is a Persona?

• A fictitious person for whom you are designing
• Represents the archetypal qualities of your
  audience
• Plural personas not personae
• Its ... well ... less pretentious

12
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

13
Researching Personas

• Along with mental model, an output of the task
  analysis research
• Market research and segmentation
• User interviews and observation

14
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

15
Personalizing Personas

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

16
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

17
Personas Are

• Stereotypes
• This isnt 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

18
Persona Chart
19
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

20
Personas in the Organization

• Turn personas into big posters, place throughout
  organization
• Encourage people to think about specific
  personas, not users

21
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

22
Writing Scenarios

• Keep the task focused 4 to 5 paragraphs
• Incorporate the personas environment
• Make them messy
• Try not to design while writing
• Write three or four scenarios per persona

23
Benefits of Scenarios

• Allows for a holistic description of the users
  experience
• Context, context, context
• From inside the users head to the environment
  surrounding them
• Excellent communication tool all humans
  understand stories
• Works well across multi-disciplinary teams
• Fleshes out personas existence

24
Potential Pitfalls

• The Scenario Where Everything Works Like Magic
• Digressing too much
• Too much response from a designed system

25
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

26
Architecture
27
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

28
Affinity Diagram Step 1
29
Affinity Diagram Step 2
30
Affinity Diagram Step 3
31
Affinity Diagram Step 4
32
Affinity Diagram Step 5
33
Affinity Diagram Step 6
Site Map
Search
Home Office
Where To Buy
Products
Home
Worldwide
Business
Support
Downloads
About
Contact Us
Developer
Reseller
Labs
Supplier
Legal Info
Privacy Policy
34
Affinity Diagram Step 7
1
3
2
4
5
6
35
Design Wireframes and Schematics
36
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

• Follow all pathways to their natural end, OR
• Clearly mark where your flow connects with
  another flow
• Use good visual design principles

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

37
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
  isnt self-explanatory
• Use good visual design principles
• One schematic can serve multiple pages

38
Usability Testing
39
Recruiting Users

• For a simple test, find 3-4 people similar to
  your sites audience
• Friends, family, coworkers from other departments
• Personas should determine your test group
• Start immediately the better the subjects, the
  better the outcome

40
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

41
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

42
More on Tasks...

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

43
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 theyll have
  to do
• Be clear that they are testing a product, theyre
  not being tested themselves

44
Running the Test (Interview Style)

• Ask the right questions
• Describe this.
• What do you expect?
• Did that surprise you? Why?
• Dont offer help
• If a task is too difficult for the user, tell
  them to stop and ask them to describe what
  happened

45
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

46
Usability Test Timeline
47
http//adaptivepath.com/workshops/gospelcom/

• jeff_at_veen.com