When Worlds Collide: Improving the User Experience by Applying Progressive Information Disclosure
Presented by
Andrea L. Ames @aamesIBM Senior Technical Staff Member / Total Information Experience Strategist & Architect
at 2013 Intelligent Content Conference (#ICC2013)on 8 February 2013in San Francisco, CA USA
(c) Andrea L. Ames, 2006-2013 2
About Andrea
Technical communicator since 1983 Areas of expertise
Information architecture and design and interaction design for products and interactive information
Information and product usability—from analysis through validation User-centered design and development process
IBM Senior Technical Staff Member UCSC in Silicon Valley Extension Tech Comm and Writing
certificate coordinator and instructor STC Fellow, past president (2004-05), and past member
of Board of Directors (1998-2006) ACM Distinguished Engineer
2
(c) Andrea L. Ames, 2006-2013 3
Agenda
Progressive disclosure (PD) Traditional information PD The new twist – applying it to the information
experience, in particular the UI Workshop: Quick steps to PD
and group heuristic evaluation …And more! Resources
3
(c) Andrea L. Ames, 2006-2013 4
According to Wikipedia… progressive disclosure (PD): “To move complex and less frequently used options out of the main user interface
and into secondary screens“
An interaction design technique Often used in human computer interaction Helps maintain the focus of a user's attention by reducing clutter, confusion, and
cognitive workload Improves usability by presenting only the minimum data required for the task at hand
Sequences actions across several screens Reduces feelings of overwhelm for the user Reveals only the essentials and helps the user manage the complexity of feature-rich
sites or applications Moves from "abstract to specific" via “ramping up” the user from simple to more
complex actions
(c) Andrea L. Ames, 2006-2013 5
PD for interaction isn’t new
Around since at least the early 1980s (Jack Carroll, IBM) Jakob Nielsen has been discussing it for ages
"Progressive disclosure is the best tool so far: show people the basics first, and once they understand that, allow
them to get to the expert features. But don't show everything all at once or you will only confuse people and they will waste endless time messing with features that
they don't need yet".
In information development, PD can be applied to content, as well
(c) Andrea L. Ames, 2006-2013 6
What is progressive information disclosure? In an information experience, enables you (the author) to
provide the right information in the right place at the right time
Assumes “competent performer” to “proficient performer” is stage of use (backup) in which users will spend most of their time when using the product–not novices; not experts
Defer display of novice information, background, concepts, extended reference material and examples, etc., until the user needs and requests it
Reduces complexity by revealing only the essentials for a current task and then reveals more as users advance through tasks
(c) Andrea L. Ames, 2006-2013 7
What is progressive information disclosure? (cont.)
Reveals information in an ordered manner Each layer builds on the previous one in a flow that provides
progressively more information Provides only the details that are necessary at a given time, in a
specific context Provides assistance when necessary--not information created just to
cover an empty widget Do not repeat information; for example, do not repeat field labels in
hover text. “A guided journey, not a scavenger hunt"
Designed around the ideal information experience–with no resource or time constraints
Implemented realistically with necessary constraints
(c) Andrea L. Ames, 2006-2013 8
A rose by any other name…
Technical communicators have been “doing” PD for a long time
We might not call it PD The best example of traditional PD:
Well-architected, traditional, online helpPrimary “layer”: Contextual and task topicsSecondary “layers”: prereqs, background,
related concepts and reference, etc.
(c) Andrea L. Ames, 2006-2013 9
Traditional, contextual help
(c) Andrea L. Ames, 2006-2013 10
The problem with traditional assistance and traditional information development methods
Typical UI-text development process: Written by developers of the UI Edited by tech pubs (best case; often copy edit capturing only capitalization and punctuation
issues and typos) Typical help development process:
Writers attend (some) design meetings, keeping track of the number of UI panels in the product, which typically include one help button per panel
Writers develop one help topic for each UI panel in the product Pop-up help/hover help provided for all, or no, controls Task help describes how to complete the fields in the UI panel:
Pop-up/hover help content repeated in task help Writers cut and paste from specs
Typical library design and development process: Deliverables developed based on development expectations and history vs. user needs Other (non-help) deliverable content identified without regard for task help also being created
Extensive redundancy across UI text, help, and other deliverables (like books) Design process accomplished within resource and time constraints, not
according to ideal or customer needs
(c) Andrea L. Ames, 2006-2013 11
What’s wrong with this picture?
(c) Andrea L. Ames, 2006-2013 12
The next PD evolution/revolution
The UI Add value Get even closer to the task than the help Influence the design of the task and task
ecosystem Drive reductions in words Prioritize resources around client value
Workshop
Let’s get our hands dirty!
(c) Andrea L. Ames, 2006-2013 14
Quick survey…do you know:
DITA? information architecture? topics? topic-based content architecture? topic-based content development?
(c) Andrea L. Ames, 2006-2013 15
Quick steps to PD
1. Consider your user and their stages of use (backup)
2. Start with the product: Is the UI as obvious and self-evident as possible1. Consider the types of content you need to provide
Control assistance Panel assistance
2. And the types of mechanisms available Persistent UI text that doesn’t require
a user gesture Simple UI gestures your users will tolerate
3. Can you improve “help?”
4. How are you supporting use of the product with non-UI, task-oriented deliverables?
5. What issues will keep you from implementing this kind of approach?
(c) Andrea L. Ames, 2006-2013 16
User, scenario
Content creator/technical writer Information architect
Use IA Workbench to create a topic model for a DITA document
Expectations, needs
(c) Andrea L. Ames, 2006-2013 17
UI First view: “welcome” Task flow All assistance about the UI should be in the UI
Persistent – absolutely necessary User controllable – useful, might be needed by some
users (obvious to get to)
Imagine you are a consultant or advisor, looking over the user’s shoulder; what does she need to know?
(c) Andrea L. Ames, 2006-2013 18
Just beyond the UI: Various flavors of “help” Stop yelling! Repeating the same thing, over and over,
does not make the message more valuable, useful, or enhance users’ comprehension
(c) Andrea L. Ames, 2006-2013 19
Completely divorced from the UI…or is it? Doc library Another form of help? What kind of content delivered in this way? Is the content we’re delivering this way
valuable (at all)? Or the most valuable for the delivery mechanism?
(c) Andrea L. Ames, 2006-2013 20
The biggest stumbling block(s)…
What keeps us from applying this approach? We didn’t know about it or how to do it We don’t think it’s the right thing to do Others (non-content people, like engineers)
don’t understand it and/or buy into it Processes and process artifacts don’t support it Tools don’t support it Other issues?
Need we say more?
Probably
(c) Andrea L. Ames, 2006-2013 22
PD revolution prerequisite: Think More, Write Less“Think more” means… Owning and being responsible for
the information experience Not making our users think about
how to use the product Not falling back on old paradigms:
One help topic per UI screen How many books are we going to
write? Not letting the developers think for
you Being assertive – making sure you’re
involved throughout the design process
“Write less” means… Ensuring that the UI is as easy to
explain as possible by contributing to designing interaction the right way the first time
Starting from the user’s immediate task context and working your way out to more general information—make “looking for” the answer a last resort (because it is)
Not forcing users to read more than they have to
Prioritizing what you cover and where—for example, using scenarios
Not just “papering the product” with traditional documentation
(c) Andrea L. Ames, 2006-2013 23
Why do we need to change? Traditional deliverables, developed by traditional methods, are not working:
Reference that “papers the product” Generalized user-guide info “Type your name in the Name field” help Most documentation focuses on functional information, not domain information, or the mapping from
domain to product function—written from the inside out Much of that information covers the large number of tasks users need to do – such as installing,
migrating, etc. – that are not business goals Online libraries stuffed with everything we produce
Documentation is often compensation for unusable products—a finger in an eroding dam of bad product design
Customers and users don’t read documentation—reading documentation is never a business goal
Information is difficult to find and often does not address the user’s issue Customers do not perceive information as separate from product Customers look more and more to forums, knowledge bases, and other social
sources of info vs. product doc Can you afford not to change—do you have the resource to continue building and
maintaining content that customers don’t need or use?
(c) Andrea L. Ames, 2006-2013 24
How can we think more and write less? Prioritize using deep understanding of users
(scenarios, use cases, etc.) Sometimes this means not writing something Most often, it means covering it in an unfamiliar
way (to the team, customers, and even you) Design deliverables to support users’ efficient and
effective use of information in the context of their tasks (embedded assistance, contextual information, examples, samples, concrete information, take cues from community-written info)
Own your portion of the responsibility for the usability of the product—the information experience begins in the product
(c) Andrea L. Ames, 2006-2013 25
How can we think more and write less? (cont.) If the design discussion around an aspect of the product seems
complicated or difficult to you, it probably is—this is where your customers most need you! In the design discussion, raise the issue with the dev team, contribute ideas for
improving the design. Look for gaps in user-goal and user-task flows: between UI panels, between tasks,
between different UIs (admin versus end user client, e.g.), between products. Ask questions about what you don’t know (they are probably the same as user’s
questions). If you can’t get product changes, or get them right away, find ways to improve the user
experience without adding topics… embedded information, “show me” demo, or tutorial.
Start with the user and provide the right information within the UI’s task flow (embedded assistance).
Determine what’s highest-value for your users—examples, samples, tasks, tutorials—and focus on those; don’t try to cover every part of the product with every kind of info and deliverable.
(c) Andrea L. Ames, 2006-2013 26
How can we think more and write less? (cont.) Document the UI in the UI
Don’t rewrite what’s in the UI in hover help and help pane Don’t include unnecessary hover help and help-pane content
When considering additional documentation Focus on user tasks—not UI tasks—and then on supporting reference and conceptual
information Focus concepts on the user’s task domain, not the tool Don’t duplicate UI help and hover-help content in other deliverables
When testing information, take user input into consideration, but don’t just do whatever they say
Understand the root causes of their concerns Design the right solution for the issue at hand and validate it Typically, users don’t know what the root cause is; they only know how to articulate what
they like and don’t like; base design decisions on observable performance, if possible
What we do requires thinking! There is no cookbook or recipe for implementing it!
(c) Andrea L. Ames, 2006-2013 27
Resources
Jakob Nielsen, AlertboxDemystifying Usability blogTime-Tripper UI patternsInteractionDesign.orgThis presentation on slideshare:
http://www.slideshare.net/aames/201302-worlds-collide-improveuxthrupid-workshop-aames
STC proceedings paper on stages of use (backup): http://www.stc.org/images/proceedings/Documents/enablingprogressivei1.htm
27
(c) Andrea L. Ames, 2006-2013 28
Questions?
28
(c) Andrea L. Ames, 2006-2013 29
Contacting/following/connecting with AndreaE-mail: [email protected]: @aames, @TMWLala, @strategicIAFacebook: www.facebook.com/alames,
http://www.facebook.com/pages/The-Strategic-IA/313151912099313 LinkedIn: http://www.linkedin.com/in/andreaames Blog: thinkmorewriteless.wordpress.com/
29
Backup
Stages of Use
(c) Andrea L. Ames, 2006-2013 31
“Stages of use” in designing and writing embedded assistance layers of PD
(c) Andrea L. Ames, 2006-2013 32
“Stages of use” in designing and writing embedded assistance layers of PD, cont.
(c) Andrea L. Ames, 2006-2013 33
Cautionary note about stages of use in EA design
Stages of use apply to multiple user dimensions; for example: Domain knowledge Computer use Your tool Tools like your tool
A user who is a novice in your tool and tools like your tool might be an expert in the domain and the use of computers in general.
The same user might be an expert with most parts of your UI and a novice in some, or might be an expert in some parts of a task flow and a novice in others.
You must consider the many dimensions of your users before arbitrarily applying a single “stage of use” label to them
Consider the appropriate information for the point in time for which you are designing: does the user need tool information, domain information, or both?
Thankfully, progressive disclosure enables you to support multiple levels of users throughout their use of the various parts of the product and through their growth in domain and tool knowledge and experience
