Web Design 1: Designing the Complete User Experience

1
Web Design 1 Designing the Complete User
Experience
Adaptive Path www.adaptivepath.com/presentations/u
e2001/ jeff_at_adaptivepath.com, janice_at_adaptivepath.
com
2
Defining Web Design

• Mastering applications
• Understanding technologies
• Techniques and methodologies for creating more
  effective design solutions

3
Defining Web Design

• Functional Design
• The design of systems that support end-users'
  tasks and goals
• User research
• Information Architecture
• Interaction Design
• Communication Design
• The design of how these systems are expressed to
  the user
• Interface design
• Visual design
• Content strategy

4
The Adaptive Path Perspective

• There is no One True Way or Four-Step Process
• The separation between functional design and
  communication design is messy at best
• The Web may have best practices for user
  experience design, but it is too early to depend
  on them exclusively

5
Three Places Web Design Shows Up

• Operating a site day to day
• Adding features weekly/monthly development
  process
• Big projects significant redesigns, yearly
  research

6
Overview
7
About the Project

• iRemodel.com leading home improvement portal
• Features
• Tutorial Content for users new to home
  improvement
• Idea File
• Product database with comparison engiine
• Contractor/architect locator
• Budget estimator
• New features
• Kitchen design center
• Contractors management application

8
Internal Discovery
9
What Is Discovery?

• Useful and often overlooked tool for
  understanding business needs and context (rather
  than user needs and context)
• An early opportunity to head off problems before
  they happen
• Answer important questions about the project
• Why do it? (Business/Marketing purpose)
• What does it do? (Scope/Definition)
• Who cares about it? (Stakeholders/Decision
  Makers)

10
If you dont do discovery youll regret it.

• Its like starting the movie without finishing
  the script, the casting, hiring a caterer

11
10 Ways Projects Can Bite Back

• Project gets bogged down in approvals
• Your assumptions about the goals of the project
  are way off base
• You discover half-way through that the scope is
  much greater than you imagined
• Feature creep
• Disenfranchised people become obstacles
• Nobody listens to youeven though youre
  supposedly in charge
• Nobody understands what youre saying (maybe
  because you dont have the same understanding of
  the project)
• Someone important and powerful (e.g., the CEO)
  hates the final solution a week before launch
• Your final solution, though cool, doesnt solve
  the original problem
• Your proposed solution cant be implemented

12
Purpose of Discovery (Soft)

• Understand the context in which you are working
• Political landscape
• Stakeholders
• Decision structures (who/how/when)
• Business mandates
• Technologies
• Build relationships
• Introduce yourself
• Explain what you do
• Get to know everyone involved (listen)
• Communicate your goals internally as well as
  externally

13
Purpose of Discovery (Concrete)

• Define project criteria
• Stakeholders
• Definitions
• Scope
• Business mandate
• Formulate strategies
• Resources
• Methods
• Process
• Schedule
• Budget

14
How this Affects You

• Overcoming denial
• Explicit acknowledgement explicit approach
• Your project can fail from the outset if you
  ignore or avoid these questions
• What is your relationship with your organization?
• How effectively do you communicate your value to
  the key stakeholders on your project?
• Develop valuable skills
• Learn the company language (jargon not buzzwords)
• Understand the decision-making environment you're
  working in
• Play the game (it is a game -- ironic
  detachment)

15
Potential Roadblocks to Doing Discovery

• Schedule pressure
• Stakeholders dont see the value
• Lack of access to key players (distance,
  vacation, schedule conflicts, etc.)

16
Method Kickoff Meeting

• Purpose
• Introduce yourself, team, and the stakeholders
• Explain the project
• Let stakeholders know how they will be involved
• Establish working relationships get the team on
  board
• Form Presentation and discussion
• Timing Beginning of discovery
• Content Goals, team, process, schedule, and
  deliverables
• Leave-behinds Project plan (draft only),
  presentation slides

17
Method Project Sponsor Interviews

• Who The most senior person (people) who had to
  approve the project (whos signing the check?)
  and possibly their peers
• Purpose
• Understand political context
• Define decision process
• Understand business imperative and goals
• Learn what other departments should be included
  and how
• Form One-on-one conversations
• Timing After kickoff
• Leave-behinds Project plan (draft only)

18
Method Stakeholder Group Sessions

• Who Key stakeholders
• Purpose
• Discover expectations for the project
• Discuss pain points, features
• Make people feel involved
• Establish cross-departmental communication among
  stakeholders
• Form Similar to focus groups
• Timing After kickoff
• Leave-behinds None

19
Method Stakeholder One-on-Ones

• Who All kinds of stakeholders
• Purpose
• Learn details about the project
• Let people know that they can talk to you (i.e.,
  listen!)
• Venting
• Talk through definitions, goals, methods,
  processes
• Solidify requirements and discover potential
  roadblocks
• Identify existing documentation
• Form Informal conversations
• Timing After kickoff
• Leave-behinds None

20
Method Review of Existing Documentation

• Gather and review previous materials any
  documentation that seems relevant. It might be
• Server logs
• Previous product specs
• Usability or other research
• Explanation of key technologies
• Even if theres nothing to review, showing
  interest will go a long way toward establishing
  relationships

21
Discovery Deliverables Vary

• Summarize your findings for distribution to the
  stakeholders and/or project sponsor
• Lets people review what theyve said and correct
  as necessary
• Review of docs will show that youre leveraging
  prior investments
• Contents include business goals, any mandatory
  features, assumptions, definitions
• Formal documentation MRD, PRD, Project Brief,
  etc.

22
User Research
23
You Are Not Your Audience

• You do not
• see things like they do
• know what they know
• want what they want
• work how they work
• This is critical information when designing a
  product

So how do you figure out all of these things?
24
User Research!

• The study of what makes peoples lives difficult
  and how to make them easier
• NeedsWhat people need to make their life easier
• DesiresWhat they want (does not equate to what
  they need)
• AbilitiesWhat they can understand and do
• MethodsHow they do things now

25
Three Types of User Research for Design

• Conceptual what users need
• Preference what users want
• Ability what users can do

26
Conceptual Research (need)

• Timing Early in the design process
• Purpose Investigates needs and methods
• Techniques
• Task Analysis/Contextual Inquiry
• Surveys
• Ethnography
• Outcome Raises the ceiling on design by
  encouraging innovative thought at the very outset
  of design

27
Preference Research (like)

• Timing Mid-process
• Purpose Investigates desires, expectations,
  priorities
• Techniques
• Surveys
• Focus Groups
• Interviews
• Card sorting
• Outcome Raises the floor by ensuring that
  design solutions appeals to the desired audience

28
Ability Research (do)

• Timing End of the process (and the beginning of
  the next iteration).
• Purpose Investigates abilities and reactions
• Pre-Launch Techniques
• Prototypes (paper and mockup)
• Usability Testing
• Post-Launch Techniques
• Log analysis
• Customer feedback analysis
• Outcome Raises the floor by ensuring that
  design solutions are usable for the desired
  audience

29
User Research Tips

• Test often
• No matter what stage your product is in, there's
  always some research you can do
• Test whats testable
• Time the research for the needs of the product
  and the abilities of the development team
• Example Don't research label wording before you
  know whether the audience wants the function it's
  naming
• Avoid research paralysis
• It's OK to make decisions without first asking
  people, just dont make all your decisions that
  way
• Dont get distracted by research and forget the
  product
• Be open-minded

30
User Research in the Design Process - Ideal

• Highly iterative
• Many small steps, rather than a few giant ones
• Research at every step

31
User Research in the Design Process Practical

• Linear process
• One big step for each type of user research
  (conceptual, preference, ability)
• Handed off at the end, as opposed to beginning
  the cycle again

32
Personas and Scenarios
33
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

34
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

35
Researching Personas

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

36
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

37
Personalizing Personas

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

38
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

39
Personas Are

• Stereotypes
• This isnt an exercise in politically correct
  thinking
• Edge cases can lead you off track, e.g. male
  nurses, private pilots
• Design targets, not sales targets
• Tools for thinking about features and functions,
  not character studies

40
Persona Chart
41
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

42
Personas in the Organization

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

43
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

44
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

45
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

46
Potential Pitfalls

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

47
Using Scenarios

• Help others understand users needs and desires
• Continually referenced throughout the design
  process
• Keep your designs honest
• Provide a personal context to task analysis

48
Information Architecture
49
What Is Information Architecture?

• A structure based on the patterns
• inherent in data that allows users
• to accomplish their goals.

50
An Architecture is a Structure Based on Patterns

• IA is the means by which we get from a pile of
  stuff to a structured experience.

51
That Allows Users To Accomplish Goals

• Intuitive access means meeting user expectations.

52
Common Information Architecture Problems

• Information structures that resemble a companys
  org chart
• Your users dont care what department youre in
• Information structures that reflect a designers
  bias
• Jargon, industry standards
• Structures that are not extensible
• Making changes requires starting from scratch

53
Nobody cares how youre organized
54
Vocabulary doesnt come from users
55
Structure doesnt scale
56
Structure doesnt scale
57
Structure doesnt scale
58
How Do You Create an Information Architecture
that Users Can Understand?

• Figure out what users need develop a mental
  model
• Figure out what you have develop a content model
• Match them up
• Use it to create your IA
• Make a high-level structure based on mental model
• Make the detailed structure based on the content
  model

59
The Two Parts of IA, Diagrammed
Surface architecturecomes from Mental Model
Deep architecture comes from the Content Model
60
What is a Mental Model?

• How the user thinks about and approaches
• their tasks and goals
• (separate from a Web experience)

61
What is a Mental Model?
Talk to spouse
Look in fridge
How much time do I have?
Does the car need gas?
Look for discounts
Clip coupons
Plan meals
Prepare shopping list
Walk the store aisles
Grocery Shopping
62
What Does a Mental Model Look Like?

• Our Mental Model Diagram looks like this, with
  tasks arranged into ever-broader groupings

63
Ultimate IA Design Goal

• An information architecture that corresponds to
  your users mental models

64
Ultimate IA Design Goal

• An information architecture that corresponds to
  your users mental models
• that also meets your business needs

65
The Process Two Tracks
66
What Is Task Analysis?

• Conceptual research that produces a Mental Model
  Diagram
• A deep analysis of user tasks and goals
• Break it down, then build it up

67
Why Perform Task Analysis?

• Helps you figure out what features are important
  to your users, and what they would call those
  features
• Ensures that the design meets those user
  requirements as well as the business requirements
• Provides a way to trace back all aspects of the
  interface to the users task flow
• So that you can create a Mental Model Diagram,
  which is really cool

68
Gathering User Task Data
69
Gather Task Data Define the Audience

• Examine target market data and personas
• Gather and review data from previous research
• competitive analysis, usability studies, log data
• Form groups of target audiences with descriptions
  and priorities
• Revisit groups after task analysis
• possibly redefine as users have defined themselves

70
Gather Task Data Prepare for the Interview

• Recruit participants
• Screener
• Recruiter or friends and family
• Select a workflow to explore
• Prepare the discussion guide
• Focus on exploring all the tasks in the workflow
• The key verb is do not feel
• Dont assume the Web or other technological
  solutions

71
Gather Task Data Conduct Interviews

• Use ethnographic inquiry techniques
• Encourage open answers, rather than to lead the
  interviewee in any preconceived direction
• Use predefined questions as prompts in a
  conversation, not a verbatim script
• Allow the interviewee to direct the flow of
  conversation
• Interview about 5 people per audience type
• Prepare verbatim transcripts
• End Result Detailed notes from a series of
  interviews

72
Next We Analyze the Transcripts
73
Transcript Analysis What Is It?

• An extremely detailed analysis of what your users
  said they do to accomplish their goals
• A depersonalized way to understand your target
  audience
• All users within a particular audience set are
  lumped together
• Less concerned with sequential order of tasks
  than with sensible grouping of tasks

74
Transcript Analysis How Do You Do It?

• Scan interview transcripts for tasks
• Copy each task to the atomic task table
• Notice patterns across users. Group similar
  atomic tasks together under one task name
• Adjust these groups as the patterns grow and
  shift
• Estimate 4 hours per interview

75
Transcript Analysis Develop Conceptual Groups

• Arrange the tasks into conceptual groups based
  on
• Steps the users described
• Similarity of tasks
• Do this for each audience, if there are multiple
  audiences
• Compare results between audiences and combine if
  appropriate
• Alphabetize conceptual groups for easy reference

76
Transcript Analysis End Result

• A set of conceptual groups and their constituent
  tasks for each audience
• An appreciation for which tasks are common and
  more important

77
Leading To a Diagram of the Users Understanding
78
A Portion of a Mental Model Diagram
79
Mental Model Diagram What Is It?

• A simple visualization of how users think about
  the workflow you explored in the interviews
• With transcript analysis, you broke activities
  down into their most basic elements
• With the mental model diagram, you build them
  back up into meaningful groups
• Meaningful groups are presented left-to-right,
  across a landscape

80
Diagram Mental Model How Do You Build It?

• Copy all the tasks and conceptual groups into a
  drawing tool (we use Visio)
• Gather these groups into increasingly general
  super-groups
• Arrange the super-groups into a meaningful order,
  if possible
• Name your super-groups with verbs, not nouns
• Make it a team effort one person makes a first
  draft, but team members and clients should
  participate in refining it

81
MeanwhileSomeone Soaks in the Content
82
The Content Audit

• A content audit is an analysis and inventory of
  all the content and functionality on the current
  site, or otherwise available to the project
• Doesnt need to be detailed, but does need to be
  thorough
• This inventory is crucial for the next step in
  the process
• Ideally developed by another member of your team
• (We will review this in detail tomorrow)

83
So We Can Compare What We Have To What Users
Want
84
Comparison of Mental Model to Available Material

• This is where it begins to come together
• Slot content, functionality, and business goals
  where it supports audiences mental model
• Make sure to address every significant content
  area
• If the project is from scratch and there are
  not many explicit features, etc., use the mental
  model to drive product requirements

85
Comparison Very Much a Team Effort

• Clients and stakeholders are essential in this
  process
• Need domain expertise to ensure completeness

86
Comparison Gap Analysis

• Ideal Every task in the audiences mental model
  is served by content and functionality
• Practical That is never the case

87
Gap Type 1 User Needs Not Supported by Content

• Could be an important oversight in the content of
  the site
• Could be be an activity not appropriate for web
  content

88
Gap Type 2 Content Available But No User Need

• Could be extraneous content not worth maintaining
  (R.O.T.)
• Could be an important way to empower the user

89
Lets Look at What We Have

• A diagram depicting the audiences mental model
  across the top, and the companys supporting
  material beneath it
• Fuzzy user data has developed into a solid,
  rigorous model
• A foundation from which to build the information
  architecture

90
And Now We Can Put It All Together
91
Q So how do we get from the pile of content and
features to a meaningful structured experience?

92
A Let the mental model guide the way.

• How To Develop a High-Level IA In 2 E-Z Steps
• Organize information according to user
  expectations
• Label content areas using familiar language

93
Task-based Information Architecture Step 1

• Mental model super-groups become highest level of
  navigation

94
Task-based Information Architecture Step 2

• Conceptual groups become the second level

95
Task-based Information Architecture Step 3

• Slotted content and functionality from the
  Comparison is placed in appropriate area

96
Task-Based Information Architecture Why Do It?

• Makes certain that your sites architecture
  responds to your visitors goals and tasks
• Helps achieve business goals by presenting
  marketing-oriented content (e.g., cross-sells,
  up-sells) in a meaningful context

97
Task-Based Information Architecture - Caveats

• Its a first-pass at the information
  architecture
• Deep structures must come from content analysis
  (Tomorrow)
• All of it will need refinement
• Some tasks dont directly translate to navigation
  nodes
• Limited in its depth

98
Things To Remember And Forget

• Remember
• Everything needs to have a place in the
  architecture but not necessarily only one way
  to get to it.
• Formality of this process is up to you
• Forget for now
• How content is produced
• How your company is structured

99
Tomorrow

• Designing the deep structures
• Competitive analysis, content inventory,
  low-level IA
• Prioritizing features
• Interaction design
• With notes on visual design
• Prototyping, process, patterns in design
• Usability testing
• Design in the organization

100
www.adaptivepath.com/presentations/ue2001/
janice_at_adaptivepath.comjeff_at_adaptivepath.com