Company and Customer Insight for Information Architects

1
Company and Customer Insight forInformation
Architects
Adaptive Path www.adaptivepath.com/presentations/i
nsight/ Jesse James Garrett ltjjg_at_adaptivepath.comgt
Peter Merholz ltpeterme_at_adaptivepath.comgt
2
The Adaptive Path Perspective

• There is no One True Way
• The success of a project requires not only a firm
  understanding of users needs, but an
  appreciation for the business requirements and
  processes

3
Overview of a UCD Process
Goal Mapping and Mental Model
Task Analysis
IA Interaction Diagrams and Prototypes
Define the Audience
Align MM Content
Initial
Audience
Diagram
Mental Model
Validate
Discovery
Definition
Prototype
Prioritize
Current State Analysis
Content Audit
Prioritiztaion
4
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

5
Internal Discovery
6
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)

7
If you dont do discovery youll regret it.

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

8
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

9
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

10
Purpose of Discovery (Concrete)

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

11
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)

12
Potential Roadblocks to Doing Discovery

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

13
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

14
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)

15
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

16
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

17
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

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

19
Current State Research Figure Out What You Have
20
Four Things To Look At

• Content
• Architecture
• Interaction
• Technology

21
Content - What To Do

• Walk through the existing site
• Pay attention to details of implementation
• Dont think like a user but dont forget the
  user either
• Ideally developed by another member of your team

22
General Rules

• Use existing documentation
• Use the knowledge in peoples heads
• Do all four activities concurrently
• Final Goal Blueprints of the existing site

23
Exploring Content

• Content audit looks at broad categories
• Sampling of pages
• Sufficient for most projects
• A more detailed content inventory looks is more
  thorough
• Make a big list of every piece and its URL
• Give each piece a unique ID
• Use this for CMS and other migration projects

24
Identify Broad Types of Content

• Typical Examples
• Executive biographies
• Press releases
• Product descriptions
• Product documentation
• Contact information
• Tutorials
• Case studies

25
Content Audit - Basic Questions

• For each piece of content on the site, ask
• What is it about?
• Who is it for?
• What type is it?
• Where does it come from?

26
Content Audit - Strategic Questions

• Check for content ROT
• Is it redundant?
• Is it outdated?
• Is it trivial?
• Is it in line with current thinking?
• Does it have historical value?
• --gtIn other words... can we get rid of it?
• Traffic analysis can help answer these questions.

27
Content Audit - Final Result

• Spreadsheet with hundreds or thousands of lines,
  one line per page

28
Architecture

• Q Can you automate the architecture review?
• A Not really.

29
Typical Site-Mapping Tool Output
30
What You Actually Need To Know
31
The Desired Result
32
Interaction Review

• Walk through existing interactive functionality
• Registration process
• Shopping cart
• Newsletter signup
• Etc.
• Play out scenarios with a test account
• Document interaction
• Think like a QA tester try to generate errors

33
Documenting Interactions

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

34
Technology Review

• Identify technologies during walk-through
• Server-side technologies such as Cold Fusion,
  JSP, PHP, etc.
• Client-side technologies such as DHTML,
  JavaScript, etc.
• Talk to the technical people
• Dont be afraid to ask dumb questions
• Ask Whats that connected to?

35
Current State Analysis Deliverables

• Content Audit Spreadsheet or database showing
  content by type and topic
• Architecture Outlines or diagrams of site
  structure
• Review
• Interaction Review Diagrams, notes, lists
• Technology Review Technical brief

36
User Research
or... Theres No You in User
37
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?
38
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

39
Three Types of User Research for Design

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

40
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

41
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

42
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

43
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

44
User Research in the Design Process - Ideal

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

45
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

46
Goal Mapping and Mental Models
47
What is a Mental Model?

• How the user thinks about and approaches
• their tasks and goals
• Within a defined system of interaction
• (distinct from a Web experience)

48
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
49
What Does a Mental Model Look Like?

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

50
What Is Goal Mapping?

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

51
Why Perform Goal Mapping?

• 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

52
Gathering User Task Data
53
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

54
Gather Task Data Prepare for the Interview

• Recruit participants
• Screener
• Recruiter or friends and family
• More on this tomorrow...
• 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

55
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

56
Next We Analyze the Transcripts
57
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

58
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

59
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

60
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

61
Leading To a Diagram of the Users Understanding
62
A Portion of a Mental Model Diagram
63
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

64
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

65
Personas and Scenarios
66
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

67
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

68
Researching Personas

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

69
Developing Personas

• Building up various personal attributes into
  personas based on existing market research and
  segmentation, plus any user interviews and
  observation youve done
• Demographic
• Age, Gender, Occupation
• Psychographic
• Goals, tasks, motivation
• Webographic
• Net usage and experience, gear, usage habits,
  favorite sites

70
Personalizing Personas

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

71
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

72
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

73
Persona Chart
74
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

75
Personas in the Organization

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

76
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

77
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

78
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

79
Potential Pitfalls

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

80
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

81
The Process Two Tracks
IA Interaction Diagrams and Prototypes
Content Model
Prioritize Features
Current State Research
Competitive Review
Content ModelDiagram
82
Comparing What We Have To What Users Want
83
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

84
Comparison Very Much a Team Effort

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

85
Comparison Gap Analysis

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

86
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

87
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

88
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

89
Prioritizing What do we do firstsecondnever?
90
Prioritize the Features
91
Step 1 The Big List

• Content Analysis and Content Map
• Ten people in a room for an hour or two
• Talk through scenarios
• Blue sky
• Focus on what it should be (brainstorming rules)
• General Rule People dont have any problem
  telling you what they want, as long as they dont
  have to make it or pay for it.
• Real Challenge Choosing which features to build

92
Step 2 Identify Dependencies and Baseline

• What things must happen first? What are the
  mandatory groupings?
• What is baseline? What are the Must-Haves that
  you cant launch without?

93
Step 3 Have Stakeholders Figure Out

• Feasibility easy or hard, expensive or not,
  short or long to implement
• Rate each item in the list
• 1 low feasibility
• 5 high feasibility
• Importance to business, to user
• Rate each item in the list
• 1 low importance
• 5 high importance

94
Step 4 Graph the Findings
High importance Low feasibility Watch for
new technology
High importance High feasibility Do Now
HI
Importance
Low importance High feasibility Consider
Low importance Low feasibility Dont Bother
LOW
LOW
Feasibility
HI
95
Thanks!

• http//adaptivepath.com/presentations/insight/
• info_at_adaptivepath.com