Information architecture is the structural design of shared information environments. It involves organizing systems of information to help users find what they need. Key aspects of information architecture include site navigation systems, labeling schemes, search, and the relationships between different types of content. Information architecture provides an underlying framework that guides how users interact with and move through an information space.
3. For the Record…
• I have been doing this kind of work for over 15 years
–
–
–
–
Independent Consultant 2007-Present
Director, Usability Thomson West 2004-2007
VP IA, Wachovia 2001-2004
VP Operations, Argus Associates 1996-2001
• Experience spans innie, outie, practitioner, manager,
startupmajor corporations
• MILS, University of Michigan 1996
• Active in IA Institute (founding member,
board of directors, job board) & ASIST (IA
Summit Chair, 2009)
4.
5.
6. Service Design
GUI Design
User-interface Design
Information Architecture
Usability
Usability Engineering
Human Factors
Interaction Design
Information Design
Information Ecology
User Centered Design
7. User Experience Design
Service Design
GUI Design
User-interface Design
User Centered
Human Factors
Usability
Design
Information Architecture
Usability Engineering
Interaction Design
Information Design
Information Ecology
User Centered Design
8. User Experience Design
User Centered
Design Service Design
GUI Design
Information Architecture
User-interface Design
User Experience
Human Factors
Usability
Design
Usability Engineering
Information Design
Information Ecology
Interaction Design
UX
User Centered Design
9. Focus for today:
• Overview of user experience design, which
provides the framework for consistently
creating usable interfaces
• Deep dive into understanding users
• Primer on Information Architecture, an often
overlooked piece of the puzzle
• Explanation of the role of usability
engineering in the broader UX process
12. What is User-Centered Design?
• UCD is a web design (product/software
development) approach that focuses on the
end users of the web site (product) as a vital
component of a successful outcome
• Principles of UCD
– An early focus on users and tasks
– Empirical measurement of product usage
– Iterative Design
20. Iterative Design Process
Kuniavsky (pp 30-42)
1) Project kickoff
2) Examination: define
problem
3) Definition: Specify
solutions
4) Creation
5) Repeat loops 2-4 as many
times as needed
6) Launch
My process:
• Discovery
• Definition
• Design test, design, test,
design (RITE)
• Handoff to developers
• Conduct usability testing on
beta or
• Launch/conduct usability
testing on launch
• discovery
Observing the User Experience: A Practitioner's Guide to User Research
by Mike Kuniavsky
23. Context & Content Oriented
UCD Methods
• Stakeholder interviews— understand upper management, opinion
leaders, people who sign the checks
• Expert (Heuristic) evaluation— “rule of thumb”; done by one or more
reviewers
• Competitive/comparative analysis: gauge the state of your
competition/peers
• Web logs/web analytics— interpret the traffic on your site
• Content Inventory— detailed documentation of every page and url on your
site/every screen in your software or app
• Baseline Usability Testing-– one on one, moderated, task-based evaluation
of an interface
27. Ideal vs Real
• The challenge is to understand what our
organization’s goals are *and* to understand
who our users are and then to shape
products to best fit that intersection
– There are always tradeoffs
30. A User’s Perspective
Email
Lotus Notes
Databases
Personal Netw orks
& Colleagues
Shared
LAN drives
Printed
Resources
Special
Apps
Public
Web Sites
Mainframe Apps
Europe
Intranet
U.S.
Intranet
TV
Intranet
Portal
"Local"
Intranet
Sites
31. “Referring to people as "users" is a
custom of two professions: computer
scientists and drug dealers.”
-Edward Tufte
32. How do we learn about users?
• Examine what we already know
– Be open to the idea that what we think we know
may not be accurate
– Develop user profiles (which can lead to personas
& scenarios)
• Meet our customers face to face
– Interviews, focus groups, surveys
• Observe and interact with our customers
– wants & needs analysis, card sorting, task analysis,
diary studies, field studies, contextual analysis
• Run baseline usability tests with actual users
33. How do we learn about users?
• Examine what we already know
– Be open to the idea that what we think we know
may not be accurate
– Develop user profiles (which can lead to personas
& scenarios)
• Meet our customers face to face
– Interviews, focus groups, surveys
• Observe and interact with our customers
– wants & needs analysis, card sorting, task analysis,
diary studies, field studies, contextual analysis
• Run baseline usability tests with actual users
34. In the context of user
experience design & user
interface design SURVEYS
and FOCUS GROUPS are
usually not the most
effective or efficient
techniques for learning
what you need to know
about your users.
35. Defining the Audience
• In an environment as large as Kent State / the
population the IT dept serves, you will need to
think about audiences/user profiles at a
macro level and a micro level
– Macro all the users you serve generally
– Micro users for a specific
tool/application/interface in context
36. User Profile
• A detailed description of your users’ attributes
• Characteristics may include:
– Job title
– Experience (with your product, with the web)
– Education
– Key tasks
– Age range & other demographic details
– Their goals
37. Classification of Users
• Primary: Individuals who work
regularly/directly with the product.
• Secondary: Use the product less often or with
an intermediary
• Tertiary: Those affected by the system or
purchasing decision makers
• [anti users]
39. Users don’t operate in isolation
• The same individual likely wears many hats
(e.g., banking professional, has own bank
accounts, manages elderly parent’s accounts)
• The end user isn’t always the primary decision
maker (librarians vs lawyers)—you may need
to take into account managers, sys admins,
purchasers
40. Treat Profiling Iteratively
• In the beginning, your user profile may be sparsely
populated—and it may be incorrect!
• That’s part of what we’re learning when we do user
research
– Better to put a stake in the ground and refine than to leave
everything hazy
– Cleveland Fed: thought their primary users were
economists; we discovered they were wrong
• In my experience one on one interviews are the
fastest, cheapest, easiest* way to refine user profiles
and develop personas
*fast, cheap & easy being relative!
41. If you design for everyone, you’re
designing effectively for no one, which is to
say you are effectively designing for no
one.
42. If you only take one thing away from
today’s session…
You are NOT
like your users.
51. Caution
• People don’t always know what they will really
like and what they would really use.
• People often anticipate liking/needing features
more than they actually will. “That’s cool!”
• What people say they do and what they actually
do often differ.
• Don’t rely on a surveys and/or focus groups as
your sole source of user data for requirements
gathering.
52. It isn’t easy, but it doesn’t have to
be complicated
• Simple techniques can yield powerful results
53. I
Interviews!
• If you had to pick one research method, this would
be the one.
• Cheapest, most flexible, low-cost way to gather
*rich* qualitative information about your users
• The only down-side to interviewing, is that you’re
dealing with a small sample-size
– If you’ve got your audiences well defined and have
recruited effectively, this is a minor point considering how
much information you can get out of a 45-60 minute
interview
54. When?
• Technically, they can be done anytime in the
UCD cyclehowever, most useful early on
• This is the point at which there is the most
potential for shaping the project to meet the
users’ needs
55. Interview vs. Survey
• Cleveland Fed discovery: we don’t know our
users as well as we thought we did
• There can be a chicken-or-egg dynamic
• Often one technique is used to provide
insights, feedback or confirmation to support
the other technique
56. Interviews are good for…
• Collecting rich, detailed data
• Collecting information that will help you be
more successful with other research tasks, like
surveys, usability studies, field studies
• Getting a holistic viewalso, serendipitous
learning
57. Interviews are not good for:
• Collecting large samples—too time consuming and
expensive
• Collecting data on highly sensitive topics
• If you want do to face-to-face in a variety of
geographic locations, interviewing becomes
expensive—but phone interviews are an option
• While you can collect data more quickly from focus
groups than from interviews, I still consider
interviewing a pretty fast method for data
collection—and interviews often yield richer results
58. Moderating Interviews
• Be an active listener.
• Really listen. Do not interrupt. Do not finish
their thoughts for them. Do not put words
into their mouths.
• Endure more silence than you feel completely
comfortable with.
• Be engaged, pay attention.
• Look for markers.
• Use probes! But avoid introducing bias.
59. Unbiased Probes
• Tell me more about X. Say more about X.
• Can you say more about that?
• I think I understood you to say X, am I
following you?
• How do you feel about that?
• Do you have any reactions to that?
60. Personas
• A user profile made specific
• A short-hand way to keep the team aligned
around the most important user
considerations as defined by your team
61. Scenarios
•
•
•
•
Scenarios: Situations that online customers
face, usually constructed around the most
critical customer needs.
Scenarios are used to brainstorm “paths to
resolution” of critical customer needs.
Scenarios cannot work without personas.
Like personas, have to extrapolate to a few
core scenarios
Personas and scenarios assist in developing smarter potential designs which are then
tested with real customers.
62. Personas and scenarios: What are they not?
•
•
•
Personas and scenarios are not
representative of every customer or every
experience
They are representations of key customers
who pose design challenges where business
needs and user needs intersect.
They encourage designers to be user-centric,
reminding us to take our users into
consideration in all aspects of our design
work.
63. A typical persona project
• Created user profiles for large company’s corporate
“university”
– Began with stakeholder interviews and working session
with the team to develop deep understanding of the
project
– Identified user profiles for audiences based on job role,
region/language, expertise
• Conducted 27 interviews with 3-5 representatives of each of
the user profiles
– These interviews were conducted over the course of 3
weeks
– 2 people participated; moderator & note-taker, most calls
recorded
64. Persona project, con’d
• Interview team debriefed regularly
– Began to draft a potential model at around interview 16
– Felt pretty confident that we were on the right track by interview 22
• Analyzed notes and gathered 391 unique data points
(Edistorm, Excel)
– Refined and strengthened our model based on the data analysis
• Identified some additional persona variations that didn’t make it into the final set
but that we wanted to share with the team for more breadth
• Proposed 6 general personas
– Shared these with the team, “gut check”
• Developed and refined the personas
– Focused primarily on a description/ “Understanding X” and “How We
Can Help”
• Had personas printed and made available in variety of
formats—emphasized the importance of actually USING them
65. Typical Persona Project,
Summarized
• Spent 8 weeks from start to finish
• Two key players were devoted to the project,
one close to full time and the other part-time
• Met with the larger team approximately 4
times over the course of the project for
approx 8-10 hours total
• Developed a series of artifacts that were relied
on throughout the design phase and continue
to be used today
66. UCD Methods
• Interviews (Surveys)
• Wants & Needs Analysis: structured focus group to
gather/confirm user requirements
• Task Analysis: observing users completing tasks
• Card Sorting: open: users create categories, closed:
users put concepts in buckets
• Field Studies/Contextual Inquiry: Setting for task
analysis, method for gathering data about users’
physical space, distractions, approach to tasks
• Diaries/ongoing relationships/beta testers: way to
gather longitudinal data
79. What is interaction design?
• There is less standard agreement about the
definition of this term in part because some
define it very broadly (on par with UX) and
some much more narrowly (focusing more on
GUI design).
• I think the right answer is somewhere in
between, as I see IxD as more than the “page”
but less than the field
80. What is IA?
• The art and science of structuring and
organizing information systems to help people
achieve their goals.
• Information architects organize content and
design navigation systems to help people find
and manage information.
81. Hard Truths
• Every site has an information architecture.
• Few sites have a planned information
architecture.
• Even fewer sites have an information
architecture that was informed by UCD
research.
82. Why is IA often overlooked?
• Successful IA recedes into the background;
you only notice it when it isn’t working
• There is often a tendency to want to skip over
abstract work to get to the more tangible
aspects of the project
– In many cases organizations don’t realize they are
skipping something; IA is rarely a stand-alone role
• As with user research, the early phases of this
work tend to be messy and uncomfortable
83. Why is IA Difficult?
Use rs
Example
Pe rsonal Digital Assistant
Communication Chasm
Docume nts and Applications
Synonyms
Handheld Computer
"Alte rnate " Spe llings
Persenal Digitel Asistent
Abbre v iations / Acronyms
PDA
Broade r Te rms
Wireless, Computers
Narrowe r Te rms
PalmPilot, PocketPC
Re late d Te rms
WindowsCE, Cell Phones
84. Why is IA important?
• Cost of finding (time, clicks, frustration,
precision)
• Cost of NOT finding (success, recall,
frustration, alternatives)
• Cost of development(time, budget, staff,
frustration)
• Value of learning (related products, services,
projects, people)
85. Components of an IA
• Organization systems
• Labeling systems
• Navigation systems
– Global
– Persistent
– Local
– Contextual
• Supplementary Navigation & Search
86. Organization Systems
• Organization structures (e.g., the “shape” of
the information): hierarchy, database,
hypertext)
• Organization schemes: exact vs. ambiguous
87. Organization Schemes
• Exact Schemes
–
–
–
–
e.g.,white pages, author/title database
Everything has a place (one right answer)
Easy to create and maintain
Great for known-item searches
• Ambiguous Schemes
–
–
–
–
e.g., yellow pages, org by topic/task/audience
Messy and full of overlap
Hard to create and maintain
Great for subject searches and associative learning
89. Navigation Systems
• Elements:
– Global (site-wide, access to primary
content)
– Local (sub-site)
– Contextual (page-level)
– Persistent/universal (ancillary links from
every page, typically header/footer)
– Supplementary (e.g., table of contents,
index, guide, search)
90. Navigation Systems
• Purpose/Goals
–Provide context (Where am I?)
–Provide flexibility (Where can I go?)
–Make sense (Separate global and
local systems)
–Avoid competing with content
94. Top-down vs. bottom-up IA
• “Top-down” IA
• Birds eye view looking down on the forest.
• Tie together disparate pockets of content for improved searching
and browsing.
• Highly focused on users and information needs.
• “Bottom-up” IA
• From the ground up, looking at individual trees and leaves on trees.
• Improve searching and browsing within a single, high-volume
pocket of content.
• Highly focused on content (content model, document types and
meta-information).
• Not mutually exclusive—most projects
need both perspectives.
95. Navigation Stress Test
• Keith Instone’s navigation stress test:
http://instone.org/navstress
• The idea behind the navigation stress test is to ask some hard
questions about your web site navigation to see if it can
"pass."
– It is called a "stress test" because most pages will not pass.
The failures may be serious, or they may not matter at all,
but at least by performing the test you will have discussed
the navigation issues and made conscious design
decisions.
• The questions are detailed ways to ask about the 3 basic
concerns users often have upon arriving at a page:
– Where am I?
– What’s here?
– Where can I go?
96. Process
• “Randomly” pick a low-level page (not a home page or subsite menu page) from your site
• Print the page out without the URL listed in the header/footer
• Pretend that you are entering this site for the first time at this
page and try to answer the stress test questions
• Mark up the printed page with what you think the answers
are
• Have other members of your team, and people who know
nothing about your site, do the stress test too. Then compare
notes. Where did you agree? Where did no one agree?
97. Navigation Question
Mark up on the paper:
What is this page about?
Draw a rectangle around the TITLE of the
page, or write it on the paper yourself
What site is this?
Circle the site name, or write it on the paper
yourself
What are the major sections of this site?
Label with X
What major section is this page in?
Draw a triangle around the X
What is “up” 1 level from this page?
Label with U
How do I get to the Homepage of this site?
Label with H
How do I get to the top of this section of the
site?
Label with T
What does each group of links represent?
Circle the major groups of links and label:
-D: more detail, sub-page (children)
-N: Nearby pages within the same section
(siblings)
-S: Pages on same site, but not as near
-O: Off-site pages
How might you get to this page from the
homepage?
Write the set of selections as:
Choice 1> Choice 2>…
100. Main Page Wireframe
Header nav igation f or
site-wide f unctions.
Tabs represent major
categories of serv ices
Banner Ad or
Internal
Promotion
Logo
Home | Help | Login/Signout
Search | Site Index
Cards
Invitations
Gift Shop
Gift Certificates
Banner Ad or
Internal
Promotion
Promotions
My Cardshop
Welcome, Tim! Dad's Day is June 18th. New Cards | Most Popular | Highest Rated
Send a card for free.
Card
Thumbnail
Primary card
classif ication scheme.
Expand lev el two
channels as much as
possible.
Card
Thumbnail
Card
Thumbnail
title: text text
More Father's
Day Cards
title: text text
More Summer
Cards
title: text text
More Music
Cards
Reasons to Send
Birthday
Subchannel | Subchannel |
Subchannel
Subchannel | Subchannel | more...
Collections
Music
Promo
TV
Image
Movies
(Music)
Stationery
Teen Lounge
African American
Spanishl
Religious
Calendar
Promote searching
using the wizard on
home. Position to
catch users not
satisf ied by channels.
Channel
Subchannel | Subchannel |
Subchannel
Subchannel | Subchannel | more...
Search Assistant
Search
Assistant
Image
Don't know where to
start? I can help you SEARCH
date
date
date
date
date
date
date
date
date
date
date
date...
full calendar
Holiday
editorial
editorial
editorial
editorial
editorial
Holiday
editorial
editorial
editorial
editorial
holiday
holiday
holiday
holiday
holiday
holiday
holiday
holiday
holiday
learn more | about us | investor relations | advertise with us | privacy policy
job opportunities | contact us | terms of service
partner ad/offer space
101. Mockup
• Non-functional model
(usually to scale) for
demonstration
purposes
• High fidelity: color,
graphic design
treatment applied
• Lo fidelity: black and
white/wireframes
102. Prototype
• Generally it’s a functional representation of a would
be product/website
– Level of functionality can vary from one or two features to
all or nearly all
– paper prototyping: reluctance due to informality vs.
inclusivity
• Used to reduce riskway to discover and solve
issues in a cheaper medium before production
• Spectrum—often thought of as “throw-away”, but
not always
– Agile
105. Usability Testing
• Design technique for improving products by
measuring their usability—i.e., capacity to
meet intended purpose
• Formative: diagnostic testing
• Summative: validation testing
• Qualitative: participant’s descriptions, your
observations of their actions
• Quantitative: measured activity (speed,
accuracy, recall)
106. Usability Demo
• Steve Krug created a 24 minute video that
demonstrates how he conducts usability
sessions
• http://www.youtube.com/watch?v=QckIzHC9
9Xc&feature=player_embedded
107. Crosby’s Maturity Grid
Adapted to Usability
Ignorance
“We don’t have any problems with Usability”
Uncertainty
“We don’t know why we have problems with usability”
Awakening
“Is it absolutely necessary to always have problems
with usability?”
Enlightenment
“Through management commitment and improvement
of human-centered processes we are identifying and
resolving our problems”
Wisdom
“Usability defect prevention is a routine part of our
design process & operation”
Certainty
“We know why we do not have problems with
usability”
108. Samantha Bailey
User Experience Design Consulting
136 E Main St. Suite 4
Kent, OH 44240
(330) 474-1138
samantha@baileysorts.com
Notas do Editor
Why are we here today? We all agree that we want our “products” (web, applications, software, etc) to be usable (user friendly, easy to use). We don’t want them to cause confusion, frustration, abandonment. We want people to be able to use them without needing help. In our giddiest dreams we imagine users actually liking our products and enjoying using them. It’s a tall order. So we know what we want-what is less clear is how to get there—if it was obvious or easy, we’d had a lot of good interfaces in our lives and we all know that’s not the case.
One of the things I want to do today is make some sense of the alphabet soup of terminology and give you a working definition for the central tenets, both theoretical and tactical, that are important in designing usable interfaces.
The foundation of usable interfaces is user-centered design.
The term “User centered design” is essentially interchangeable with User Experience Design, which has become the more dominant term, and “UX” has become the shorthand way of referring to the entire field.
One of the things I tell people who I mentor is that a reality of doing this work is that users will break your heart; they will be confused by designs you think are crystal clear, they will reject clever ideas you loved, they will fail to grasp labels you carefully crafted. Part of being successful in the work is learning how to put your ego aside and respond to what the empirical data you gather teaches you.Myth #14: You are like your usershttp://uxmyths.com/post/715988395/myth-you-are-like-your-users
One of the things I tell people who I mentor is that a reality of doing this work is that users will break your heart; they will be confused by designs you think are crystal clear, they will reject clever ideas you loved, they will fail to grasp labels you carefully crafted. Part of being successful in the work is learning how to put your ego aside and respond to what the empirical data you gather teaches you.Myth #14: You are like your usershttp://uxmyths.com/post/715988395/myth-you-are-like-your-users
Understanding Tablet Use: A Multi-Method ExplorationAbstract: Tablet ownership has grown rapidly over the last year. While market research surveys have helped us understand the demographics of tablet ownership and provided early insights into usage, there is little comprehensive research available. This paper describes a multi-method research effort that employed written and video diaries, in-home interviews, and contextual inquiry observations to learn about tablet use across three locations in the US. Our research provides an in-depth picture of frequent tablet activities (e.g., checking emails, playing games, social networking), locations of use (e.g., couch, bed, table), and contextual factors (e.g., watching TV, eating, cooking). It also contributes an understanding of why and how people choose to use tablets. Popular activities for tablet use, such as media consumption, shopping, cooking, and productivity are also explored. The findings from our research provide design implications and opportunities for enriching the tablet experience, and agendas for future research.
The dangers of Don’t Make Me Think
Personas and scenarios are not the only input into designBusiness requirements, task analyses and simple common sense also drive designUsability testing with real users should be used to validate designs developed using personas and scenarios
More banana goodness:http://www.instructables.com/id/How-to-Eat-a-Banana-Like-a-Monkey/http://www.slate.com/id/2067407/
Keith Instone’s navigation stress test: http://instone.org/navstress
Crosby was a Quality management guru whose maturity matrix is widely respected and his grid has been widely adapted. In our contexts these are the most useful citations:http://www.useit.com/alertbox/maturity.htmlhttp://www.ii.metu.edu.tr/~is526/course_material/lectures/Lecture02-SoftwarePatterns_V4.pdf