(Join me on Thursday, July 12, 2012, 4:00 PM to 5:00 PM Eastern Time at the STC live webinar for this presentation!) You know that there is more to technical communication than developing traditional deliverables, that the experience need not be discontinuous or redundant, and that you can positively impact product experiences through content. How? Through progressive information disclosure. Learn how to improve users’ experiences using this information architecture and design technique.
For related proceedings paper, see pg 177 of the PDF (http://tinyurl.com/crdwwld), or the mobile version (http://bit.ly/MhO97q).
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Improving the User Experience by Applying Progressive Information Disclosure
1. Improving the User Experience
by Applying Progressive
Information Disclosure
Presented by
Andrea L. Ames
IBM Senior Technical Staff Member / Information Experience Strategist & Architect
UC Extension in Silicon Valley Certificate Coordinator & Instructor
STC Fellow & Past President (2004-05)
ACM Distinguished Engineer
3. 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
University of CA Extension certificate coordinator
and instructor
STC Fellow, past president (2004-05), and past member of
Board of Directors (1998-2006)
ACM Distinguished Engineer
3
4. Agenda
Progressive disclosure (PD)
Traditional information PD
The new twist – applying it to the information
experience, in particular the UI
But first, we have to think more
and write less
Quick steps to PD
Resources
4
5. 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
6. 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
7. 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
Defer display of novice information, background, concepts,
extended reference material, 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
8. 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
9. 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 help
Primary “layer”: Contextual and task topics
Secondary “layers”: prereqs, background, related
concepts and reference, etc.
11. 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 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 completed within resource and time constraints, not according
to ideal or customer needs
12. The next PD
evolution/revolution
The UI
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
13. PD revolution prereq:
Think More, Write Less
“Think more” means… “Write less” means…
Owning and being responsible for Ensuring that the UI is as easy to
the information experience explain as possible by contributing
Not making our users think about to designing interaction the right way
how to use the product the first time
Not falling back on old paradigms: Starting from the user’s immediate
One help topic per UI screen task context and working your way
How many books are we going to out to more general information—
write? make “looking for” the answer a last
Not letting the developers think for resort (because it is)
you Not forcing users to read more than
Being assertive – making sure they have to
you’re involved throughout the Prioritizing what you cover and
design process where—for example, using
scenarios
Not just “papering the product” with
traditional documentation
14. 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?
15. 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
16. 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.
17. 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!
18. Now what?
1. Start with the product: is it as obvious and self-evident as
possible
2. Consider your users’ stages of use (backup)
3. Consider the types of content you need to provide
Control assistance
Panel assistance
Domain assistance
4. And the types of mechanisms available
Persistent UI text that doesn’t require
a user gesture
Simple UI gestures your users will tolerate
5. Can you improve “help?”
6. How are you supporting use of the
product with non-UI, task-oriented deliverables?
19. Resources
Jakob Nielsen, Alertbox
Demystifying Usability blog
Time-Tripper UI patterns
InteractionDesign.org
2012 STC Summit Proceedings paper:
PDF (pg 177): http://tinyurl.com/crdwwld
Mobile: http://bit.ly/MhO97q
This presentation on slideshare: http://slidesha.re/JlUaNT
19
22. Backup
Stages of Use Model:
A tool for applying PD
2012 STC Summit Proceedings paper:
PDF (pg 177): http://tinyurl.com/crdwwld
Mobile: http://bit.ly/MhO97q
23. “Stages of use” in designing and writing
embedded assistance layers of PD
Information Level
0 25 50 75 100
Competent Proficient
Novice Advanced Beginner Expert
Performer Performer
15-25% 60-75% 1-5%
10-15% 5-10%
Information
Level
60
24. “Stages of use” in designing and writing
embedded assistance layers of PD, cont.
Information Level
0 25 50 75 100
Competent Proficient
Novice Advanced Beginner Expert
Performer Performer
15-25% 60-75% 1-5%
10-15% 5-10%
Information
Level
60
25. 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