Improving the User Experience by Applying Progressive Information Disclosure


Published on

(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 (, or the mobile version (

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Improving the User Experience by Applying Progressive Information Disclosure

  1. 1. Improving the User Experience by Applying Progressive Information Disclosure Presented by Andrea L. AmesIBM 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
  2. 2. Tweeting? @aames
  3. 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. 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. 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 users 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. 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 dont show everything all at once or you will only confuse people and they will waste endless time messing with features that they dont need yet". In information development, PD can be applied to content, as well
  7. 7. What is progressiveinformation 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. 8. What is progressiveinformation 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. 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.
  10. 10. Traditional, contextual help
  11. 11. The problem with traditional assistance andtraditional 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. 12. The next PDevolution/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. 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. 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. 15. How can we think moreand 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. 16. How can we think more andwrite 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. 17. How can we think more andwrite 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. 18. Now what?1. Start with the product: is it as obvious and self-evident as possible2. Consider your users’ stages of use (backup)3. Consider the types of content you need to provide  Control assistance  Panel assistance  Domain assistance4. And the types of mechanisms available  Persistent UI text that doesn’t require a user gesture  Simple UI gestures your users will tolerate5. Can you improve “help?”6. How are you supporting use of the product with non-UI, task-oriented deliverables?
  19. 19. ResourcesJakob Nielsen, AlertboxDemystifying Usability blogTime-Tripper UI patternsInteractionDesign.org2012 STC Summit Proceedings paper: PDF (pg 177): Mobile: presentation on slideshare: 19
  20. 20. Questions? 20
  21. 21. Contacting/following AndreaE-mail: aames@pobox.comTwitter: @aamesFacebook: 21
  22. 22. Backup Stages of Use Model: A tool for applying PD 2012 STC Summit Proceedings paper: PDF (pg 177): Mobile:
  23. 23. “Stages of use” in designing and writingembedded assistance layers of PD Information Level0 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. 24. “Stages of use” in designing and writingembedded 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. 25. Cautionary note about stages of use inEA 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