STC Summit day 2 – Progressive disclosure

Iโ€™m at STC 2012, the annual conference of the Society for Technical Communication. This post contains my notes from a session called “Improving the user experience by applying progressive information disclosure”. The presenter was Andrea L. Ames.

Andrea started by saying that our job as technical communicators is to make our users as successful as possible with our products. That means writing the content, and putting the content in the right place.

Andrea’s presentation covered:

  • What is progressive disclosure (PD) in a traditional world, with a traditional task-oriented help system. Andrea mentioned that we may have been doing PD for years.
  • The new twist – applying PD to the information experience, in particular the UI
  • Why it seems easy, but is not that easy to do.
  • Some quick steps towards PD.

What is progressive disclosure (PD)?

PD comes from the user experience world. It means that we take something that is essentially complex, and simplify it by giving the user only what they need right now, then reveal the rest later. We visually hide complexity. After all, sometimes the user will never need to see the complexity, depending on the path they choose.

PD is a technique used in interaction design. Wizards, for example, are a PD mechanism. PD has been around since the early 1980s.

PD can be applied to information as well. Not just the interaction or UI. We can help the user get just what they need, without being overwhelmed. Remember that their goal is not to read the documentation.

What is high value content?

Telling people how to manipulate the user interface is the lowest value content that you can write. High value content is telling the customer how they can solve their business problem.

Andrea described a user’s goals like this:

  • Goal 1 is to solve a problem.
  • Goal 2 is to use a specific tool to solve the problem.
  • Goal 3 is to read the help or documentation.
  • Even worse, if people have to read documentation on how to use the help, that’s goal 4.

What is progressive information disclosure?

Progressive information disclosure is the ability to provide the right information in the right place at the right time. It:

  • Assumes most users are at the stage of competent performer to proficient performer, rather than novices or experts.(From Sarah: This is a key point. Very useful.)
  • Postpones the display of novice information, background, concepts, and extended reference information, until the user needs and asks for them. This means that we need to thoroughly understand the context and what it means to the user.
  • Reduces complexity by revealing only what the user needs to know for the current task.


  • Reveal the information in an ordered manner. Each layer builds on the previous one. For example, a user starts by skimming the field labels and inline text before resorting to hovers and clicks to find help.
  • It should be a guided journey, not a scavenger hunt.
  • Design around the ideal information experience, assuming you have no resource or time constraints. This is your model.
  • Then you implement what you can, taking your constraints and dependencies into account.

It’s not entirely new

Andrea showed us an example of traditional contextual help, and discussed how elements of that design are already practising progressive information disclosure.

But there are problems with traditional information development methods

Traditional help information is task oriented, but it is usually task oriented in that it tells people how to use the UI. It also tells people the obvious things, such as how to type your username in the username field.

Much of the text in the UI is written by the developers.

The next evolution in progressive disclosure

Technical communicators need to get closer to the task than the help gets us at the moment. We are closer with embedded help, but it’s still out of the main taskflow. We need to write the right information in the UI. We need to influence the design of the task and all the related UI areas. The idea should be that we write as little as possible, because it’s not necessary.

How? Anything you can drive into visual design, interaction design, or algorithm, means that there’s less to write. For example, write the field labels on the UI.

The prerequisite is that we think more, and write less. The problem comes if we have very complex software, and if we don’t have the skills to simplify it ourselves. In that situation, what can we do?

  • Break out of complacency and be vigilant. Keep trying. Own the information experience.
  • Make sure we’re involved throughout the design experience. Become more influential in our organisations.
  • Don’t let the developers think for us. Sit in on the development design meetings, and contribute. Discuss with our team how to approach this. Push back on the words often spoken when the UI is complex: “We’ll fix it in the help.” No! Fix the UI. This is where the customers most need us.
  • Keep an eye on the volume of content produced, and reduce it where possible. Don’t assume we need a help topic per screen.
  • Be in the moment, and think about the right thing to do in this moment.

More ways to write less and think more:

  • Document the UI in the UI.
  • Think about how we can raise issues.
  • Ask questions about what we don’t know. Our questions are probably the same as the users’ questions.
  • When testing information, take user input into consideration. But make sure we understand the root cause of their feedback, rather than just doing exactly what they say.
  • Design the right solution, based on the root cause, because we understand the problem.

A practical guide

  • Start with the product, making it as obvious and self-evident as possible.
  • Consider the users’ stages of use.
  • Decide on the types of content we need, such as help with controls, panels, domain.
  • Improve the help, and make sure we are supporting the use of the UI with the non-UI based assistance (documentation).

A cool quote from Andrea

Andrea wants to write 10% of what she writes today, and have customers universally love it. And she wants people to buy products because of the help.


Andrea is great to listen to and watch. She is amusing, enthusiastic and knowledgeable. Thanks Andrea for a great session.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 23 May 2012, in STC, technical writing and tagged , , , , , . Bookmark the permalink. 7 Comments.

  1. Thanks, Sarah, for the FAB summary! ๐Ÿ™‚

  2. Great presentation! Thanks Sarah!

  3. I’m bummed that I can’t be there–I only live four hours away by car now. Thanks for taking such useful notes and sharing them!

  1. Pingback: STC Summit 2012 wrapup – STC12 « ffeathers

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: