Author Archive

Progressive disclosure is a method of revealing the details of a feature on an on-demand basis, so that the basic elements of the feature appear by default while the less used or more advanced elements are hidden. These elements are usually just a click or two away, so they remain readily available, but they’re hidden by default to avoid interface clutter for the majority of users who do not need them.

This method is extremely effective for surfacing the right features in an application and hiding the wrong ones. Simply put, progressive disclosure is one of the most effective ways to clean up your application and improve user experiences without sacrificing functionality.

In other words, it’s the solution to one of the software’ industry’s biggest problems. The continuous addition of new features to applications invariably results in a more complicated interface, which in turn makes the user experience less desirable. Progressive disclosure gives us a way to keep building new features without complicating the interface.

In this article, we’ll explore progressive disclosure by looking at long-established conventions from the world of newspaper design, and then look at how to apply the principle to the web.

The Fine Art of Newspaper Design

Newspapers, as you know, have been around for hundreds of years. In this time, newspaper publishers have learned to do quite a few things that seem to make, well, perfect sense. Newspaper designs are obvious, but only because the people who put them together made them obvious.

The actual design of a newspaper varies wildly from one to the next, but newspapers far and wide adhere to a basic conventions.

First, they offer clear, concise headlines that enable readers to quickly scan a page to find whatever is most interesting.

Headlines serve as the first step in accessing more information. Once you choose a headline that looks interesting, you move on to the article itself.

And the article is written using the inverted pyramid method.

The Inverted Pyramid

The inverted pyramid is a style of presentation in which the most important and all-encompassing details are presented first and the rest of the story is told through progressively less significant, but more detailed pieces of the story. Like an inverted pyramid, it starts broad and gets progressively narrower. It’s the way news stories are written.

Journalists everywhere subscribe to this methodology by beginning each story with facts that explain the who, what, when, where, and why of the story. This creates a broad, big picture view of the story so readers can decide whether or not to keep going.

Each subsequent paragraph then offers increasingly specific about the story. Although the additional information helps the reader round out his sense of what happened in the story, each new piece of information decreases in importance.

This is done for a couple of key reasons. First, it enables readers to get the most important information right up front so she can quickly decide whether or not to keep reading. Second, it gives layout designers a way out of sticky design situations. If an article is too long to fit on a single page, but not long enough to warrant a second page, the least important pieces of information – located at the end of the article – can be trimmed to adjust its length. Using the inverted pyramid structure means the article can be made shorter or longer as needed.

This isn’t so much a problem on the web, but take a look at that first reason again. It enables readers to get the most important information up front.

Most newspaper articles start on one page and end on another. Because it’s a printed media, space is limited, so long articles are broken up into multiple parts. The first part can have a “Continued on A14” statement added to the end of it, for example, and the second part can resume with a “Continued from A1”, very much like a “Read more …” link on a web page.

Simple, right? Let’s recap.

First, the opening sentences of a news story are the most important, which is why they’re at the beginning. Second, anything beyond the critical elements can be relegated to another page.

Instead of cramming everything possible into a single space, newspaper designers split things up into logical chunks. And journalists continue the idea by presenting the most important things from each story first.

You can scan a page to find a headline, read the first few paragraphs of an article, and move on without getting bogged down in details you don’t need and that aren’t essential to the story.

This is the essence of progressive disclosure.

Progressive Disclosure on the Web

So how does all this apply to the web?

It applies to the design of individual features, and the architecture of the site or application as a whole. It gives us a way to surface the essential and most-used features and tuck the less-used features away behind a click.

In Google Calendar, for example, you can click an item listed in the calendar view to see the high-level details of an event.

To see more details, you simply click “edit event details”. This takes you to another page that contains all the information available about the event.

Here, you can see the guest list, comments that have been made, and reminder options. You started with just a few details and progressively accessed more information by clicking a link.

On this details page is another progressive disclosure style design. To add guests to an event, you need to click “Add guests”.

Once clicked, a text area is displayed so you can enter the email addresses of people who need to attend the event.

Why wait? Why not show the text area when the page loads instead of waiting for the user to click a link?

This is done so that only the most critical features are shown by default. Not everyone uses the calendar to organize multi-person events, and not every event requires a guest list. Since this feature is used less often than most of the others, it is hidden by default so that the interface can remain clean and simple while still offering a ton of useful functionality.

GrandCentral (a call and messaging management system) also makes use of progressive disclosure, and does so in a very simple way that you’ve probably seen a number of times on the web already. It applies progressive disclosure through a design pattern known as inline expand to reveal more information about a phone message.

By default, messages in the Inbox are shown in a list, and each item contains a small Play button.

When you click the Play button, the area is expanded and a new interface is revealed that enables you to play the message and learn more about the caller.

Functionality is again hidden to keep the interface simple by default. You can quickly glance at the list of messages to see what’s there without the full set of details for each call getting in the way. If you decide to listen to a particular message, you see those details in an on-demand fashion.

Seeing all of the details for all the messages would be overwhelming. Seeing a quick list and expanding select messages to see more is much friendlier.

Thanks – you’ve changed my life

As you can see, applying the concept of progressive disclosure is usually a simple matter of … OK, it’s not that simple.

You have to figure out which screen elements (features or content) are critical and which ones aren’t, and then figure out how to hide the non-critical elements while still providing quick access to them. But once you have that down, you can stop worrying about how to work in all those fancy new features you’ve been wanting to build.

Well, you can worry less anyway.

Kidding aside, don’t view this as an excuse to start cramming everything you can imagine into your application. No matter how well you master progressive disclosure, you still want to show restraint when it comes to adding new features.

More complex software has a funny way of resulting in more complex interfaces. Remember to show some restraint.

Communicating design is tricky business. Designers have invented all kinds of deliverables to handle this job, but we continue to run into the same issues over and over again.

First, we forget things. We leave out some small element that, as it turns out, is absolutely essential to making an interaction work, so we need to revise our designs and send out a new set. Second, we run out of time in our busy schedules and never actually get around to presenting the design work to our clients (whether internal or on the other side of the planet). Third, we forget to include a few extra hours in our project proposals for the inevitable questions developers will have as they dig in and start trying to build the deviously brilliant designs we’ve concocted for them.

Fortunately, there’s a solution to this mess. But for several months now, I apparently couldn’t be bothered to tell you about it.

So today, I’m turning over a new leaf. I’m giving away my secret weapon. (But not until the end of the article.)

Introducing the Design Description Document (DDD)

A Design Description Document (DDD) is, essentially, a slide deck that shows detailed use cases alongside wireframes or comps in an effort to detail all the interactions in a design. And it has quite a few major benefits.

Typically, when an interaction designer completes a set of task flow diagrams and wireframes, she ZIPs it up and sends it off to whoever is pounding on the wall for them and hopes everything goes well. This method invariably backfires.

The ZIP gets sent to the boss, and the boss comes back with questions. The ZIP gets sent to the development team, and the developers come back with questions. The ZIP gets sent to the Documentation team, and the writers wait until something is in QA, because they know the final product won’t be anywhere near what you designed, and then they write their Help documents as quickly as humanly possible.

The Design Description Document cures all of this. First, it communicates to the boss how each interaction will occur, so he has no questions. Second, it tells the developers exactly how things need to work so they know what to build and can immediately start cranking it out. Third, it gives the Documentation team something they can start writing about sooner than later. After all, if the developers know exactly how everything needs to work, odds are much better that the final product will be in line with the original design.

Do you see a trend here? DDDs are good for everyone. Oh wait, what about the designer?

Well, DDDs are designer-friendly, too. They take very little time to create, they’re wickedly easy to update, and, well, they can be branded, and what designer doesn’t love that?

And in addition to answering questions, it helps prevent you from making mistakes and sending them to everyone you know. Because a DDD includes detailed use cases (more on this in a few), you have to actually write down the steps to complete each interaction. As you do this, you can continually check the wireframe to make sure each step can be performed as you’ve written it. If not, you probably forgot to add something to the wireframe. Now you can fix the wireframe, update the DDD, and send out mistake-free design deliverables.

The elements of a DDD

The Cover slide (the first slide in the deck) of every Design Description Document includes a few key elements. Here’s the list:

• Client name
• Project name
• Version number of the application
• Designer’s name
• “Last modified” date

Each subsequent slide of the DDD includes a few more essential elements:

• Wireframe for a single screen, or a storyboard for a complete interaction (you will likely need to scale this down to fit it on the slide, hence the inclusion of a full-size version of each wireframe in your design deliverables)
• Detailed, written use cases for each interaction shown in the wireframe or storyboard
• The file name of the accompanying full-size wireframe image (e.g. 01-Homepage.jpg)
• Notes (if needed)

And if you find that you need some extra room for longer explanations, you can always add Notes slides to the equation, either mixed in with the wireframes or at the end of the slide deck.

The low-down on the how-to

To put one of these babies together, you need the right software. Fortunately, it’s probably already on your machine. As I said, DDDs are slide decks, which means you can put them together in Microsoft Powerpoint or Apple Keynote. You could, in theory, also use Adobe Illustrator or even use keyframes in Adobe Flash.

I created templates in Powerpoint and Keynote to get you started. I use the Keynote version often, and I find that it’s the easiest, but not everyone is lucky enough to own a Mac.

Both versions make use of “master slides”, and this is where the graphics are located. So that I don’t have to reformat text every time I create a new DDD, I keep a version that has three slides by default: the Cover slide, a Design Description slide, and a Notes slide.

To create a Design Description Document, simply pop open one of these files and do a quick Save As to make a copy without affecting the template. Then:

1. Access the Cover master slide and replace the ClientName, ProjectName, Version#, DesignerName, and DD/MM/YYYY text with the name of your client and the project, version number, designer name, and date.
2. Open the Design Description master slide and replace the AppName and V# text with the appropriate info.
3. Go to the second slide in the deck and copy and paste it to make new empty slides – as many as you need to show each wireframe you created. If you have 20 wireframes, create 20 Design Description slides.
4. Next, either insert a wireframe image or paste one in, and then start writing out use cases in the sidebar for each interaction on that screen.
5. When you’re done, either send it off as is, or turn it into a PDF. (This is good for preventing people from editing the document.)

In Keynote, you can simply export the entire document as a PDF, directly from within Keynote, by choosing File > Export and selecting the PDF tab in the resulting dialog box.

In Powerpoint on Windows – well, you’ll have to figure that out yourself. I’m allergic to Windows. Can’t go near the darn thing.

Use cases 101

These templates are designed to help you write effective use cases, but here is a quick crash course.

First, replace the term “Use case” throughout your Design Description slides with tasks. For example, “Sign in” is a very typical heading for a use case. “Retrieve password” is another.

Next, write out the steps to complete each interaction in the wireframe.

Finally, go back over each step in the use case and look for exceptions. Exceptions are things that can occur if a user doesn’t execute your use case exactly as you intended it. A user who enters an incorrect password on a sign-in screen, for example, needs to be shown an error message. The use case exceptions are where you detail these facts.

To do this, explain which use case step is being excepted, then write out the steps for the alternate use case. In the example shown here, a user can enter an incorrect user name (Step 1 in the use case). To remedy this, we show an inline error message, the user enters the user name again, and clicks the Sign In button.

Click here to download

Ha! Made you click.

So, you’re sold? You want the templates so you can create your own Design Description Documents and stop sending out mistakes and answering questions long after a project is over?

Well, then download the template already.

For just a few cents a day, you can help a designer break the habit

Once you get the hang of creating your own DDDs, spread the word. The more designers use these templates, the easier life will be for all of us in the future. I can’t tell you how many times I’ve been sent a set of wireframes designed by someone else and had to go hunt them down and ask questions.

With the DDD, life is richer and more rewarding. It’s like one of those commercials where everyone is happy.

For a full collection of templates, visit www.rhjr.net/ddd.

And if you happen to create a new template in something other than Keynote or Powerpoint, send them to me at “robert at rhjr dot net” and I’ll add them to the collection. (Be sure to give yourself credit in the template. You deserve it.)

The rise of ‘web 2.0′ has brought with it a slew of new interaction styles and concepts, most of which give the web some magical powers it never had before, making it a significantly more powerful platform for application development. But RSS, tagging, drag-and-drop, slide transitions, and many other new paradigms are unfamiliar to web audiences, who have been trained for years that the web has severely limited capabilities compared with the desktop.

So how do we teach our users to use all these fancy new gadgets? We do it through the magic of instructive design. Let’s take a look at how some simple design elements can be used to communicate the value of these new interactions and get our users moving forward quickly.

Instructive design

Instructive design is the use of design elements to help users climb over the learning curve in a web application (or anything else for that matter). This includes very typical elements such as text, graphics, and video, but in this case, it’s not about what you use, it’s about how you use it.

The goal of instructive design is to teach users about an interaction as effectively and efficiently as possible, without getting in the way of the experienced users who already ‘get it’. Many tricks can be used to accomplish this goal, the most common of which is plain ol’ text. Later, I’ll discuss how to handle the more complicated stuff, but first a glimpse into the basics.

The Basics: Plain ol’ Text

You know those paragraphs of instructions you often see at the top of an application screen? Hardly anyone actually reads them. This happens because they’re focused on doing, not reading, and users tend to completely avoid text when using web applications. But the problem goes much further than long blocks of instructions. In a recent usability session, ten out of ten users looked right past a prominently-displayed Help button, choosing instead to ’satisfice’ their way through the tasks they were asked to perform. One user, in fact, said out loud that she wished there was some sort of Help documentation available.

If text is used well, however, it can be your saving grace. You just need to follow a few simple rules, all of which are shown in this example from Squidoo.

First, keep instructive text to a maximum of one or two lines. Short lines. Anything more will most likely not be read. In most cases, it won’t even be ’seen’. After writing instructive text, go over it several times to see how you can shorten it.

Second, make sure the text is visually different than that of section headings, field labels, and so on. People notice things that are different from other elements on a page, so instructive text that has its own styling has a better chance of getting noticed. Using a slightly smaller font size, in a slightly lighter color (mid-tone gray, for example, when the rest of the text is black) or a different font weight, sets the instructive text apart from the rest, much like footnotes are set apart from body text in a book, and draws the eye to it.

Finally, position instructive text as closely as possible to the element the instructions are about. If the text explains what type of data to enter into a form field, for example, place it immediately above or below the field. Better yet, use the text as the default value for the field, so it’s impossible for users to miss it. (If you do this, be sure to use JavaScript to automatically highlight the default text, or remove it completely, so users can start typing immediately, without having to select the text themselves.)

These practices keep newer users informed about how to use an application, but stay out of the way so experienced users don’t trip over them while trying to get things done.

Teaching users about RSS, tagging, and drag-and-drop interactions takes a little more creativity than a simple line of instructive text, but it’s not any more complicated, providing we keep the concepts of instructive design in mind as we create applications. Following is a breakdown of the three most vital elements of instructive design: purpose, benefit, and usage.

Purpose

Before a user will be happy about learning to use a new style of interaction, she must first understand the purpose of it. Tagging, for example, possibly because of its name, doesn’t have a clear purpose to most users, so it must be described in a way that will enable the user to form a clear mental model. Despite its great value as a user-driven system of organization, most users have no pre-existing mental model of tagging on a website, let alone its purpose.

When Amazon decided to implement a tagging system to its product pages, it added a small ‘What’s this?’ link next to the section heading for users who aren’t familiar with the paradigm. The link produces a small pop-up window that explains the concept behind tagging and answers several questions about how it is used. While this is helpful to those who might read it, anyone who has used Amazon lately probably realizes this link is a little buried amongst the boatload of information shown on a product page, and the body of the pop-up window is significantly more thorough than most people will want to know.

So what if the application’s whole organization system depends on tagging?

For starters, you can use the tags the same way most sites display local navigation (navigation links for a specific section within a site). Instead of reserving a section of the page for ‘Tags’, stick them in the sidebar with the other navigation under the label ‘Related’ and offer a way to edit the keywords for the page, such as with a link at the bottom of the sidebar section. In other words, avoid the term ‘tags’ until users need to know what tagging means. Users form mental models of applications as they use them, and keywords have a recognizable real-world meaning that can tune users into the purpose of tagging. So, instead of explaining the purpose in a lengthy Help document, imply the purpose with a simple and appropriate section label.

Next – and this may seem counter-intuitive – instead of focusing on the tags themselves, show a tag cloud, like the one above, and use short instructive text to describe it. This way, you give users something interesting to look at that doesn’t do any harm if the user doesn’t understand its purpose (Last.fm also uses this device). After all, a tag cloud is just a list of links, regardless of the various font sizes assigned to each one. Then offer a way to edit the tags, again referring to them as keywords, and provide a separate page or some sort of in-page editing capability that describes the tags in a bit more detail. From here, you can certainly link off to a Help document about tagging. Just be sure to get users hooked on using the tags first. The purpose will become clear through the interaction.

Once users get this far, consider also using a short screencast to bring the basics to life. Find the person in your company with the best people skills, sit him or her down with an outline for what to do, crack open Camtasia, and hit Record. A few quick edits later, you’ll have a friendly, engaging way to learn about tagging instead of a dry Help article.

Benefit

In addition to describing the purpose of an interaction, we need to stress that users will actually gain something through the interaction. The software business may focus on feature lists for marketing material, but any salesperson will tell you that selling benefits is far more effective than selling features.

FeedBurner teaches users who are new to RSS the benefits of feeds without ever even using the term ‘RSS’. Instructive text is used at the very beginning to explain that FeedBurner “makes it easy to receive content updates” in various feed reader applications. But while helping new users along, FeedBurner also provides chicklets (subscription buttons) so the experienced users can subscribe to various readers with a single click.

FeedBurner helps users get up to speed by replacing what would normally be a page full of unstyled XML with meaningful, formatted content, complete with information about the format and links to various feed readers. FeedBurner also mentions in several places on the page why users should use it and what FeedBurner is all about.

You can leverage this on your own site by using FeedBurner’s services to teach users about site feeds, or you can do something unique with the same purpose. Create a page on your site about RSS and why it’s so useful, and link the obligatory RSS icon to it instead of linking straight to an XML page. Use the page in the same ways FeedBurner does – to instruct – and your users will pick up on the value much more quickly.

Usage

The final thing to demonstrate in instructive elements is how to interact with the design. In addition to describing the benefit and purpose of an interaction, we also need to make it clear how to use it.

Drag-and-drop interactions, for example, have been around for a long time in desktop applications, but the masses have not yet learned that such an interaction can exist on the web, which makes the interaction very difficult to discover. Because of this, there are a few tricks to getting users on track.

First, it’s best to maintain the standard set by desktop applications by always using the move cursor on drag-able areas instead of the hand or arrow pointers. This can easily be set in the stylesheet for an application, and it establishes the same standard on the web that users are accustomed to on the desktop, making it easier for users to discover the feature and learn to use it.

To push things along a little more, using a text label for the drag handle has been extremely effective. As in, instead of only using the move cursor, label the drag-able area using the word ‘drag’. This spells out the details of using the interaction in plain English and makes it even easier to discover.

In Dashboard HQ, we created a screen state that enables users to rearrange elements on the page, change pod titles, and so on. In this state, each pod has an explicit drag handle that is visually and functionally separate from the title bar for the pod.

By doing this, we made the functionality easy to discover. Users can simply glance around the page, see that each pod has a clearly-labeled drag handle, and quickly determine how to complete the task of rearranging elements on the page. In this case, the purpose and benefit of the interaction is intrinsically clear, because users often immediately see the value of being able to arrange the page exactly the way they want.

Moving On

To dive a little deeper into the practice of instructive design, you can try a couple of different things. First, you can open up an application you worked on in the not-so-recent past and try to take a fresh look at it. Find the areas that might confuse users, areas that are simply not as clear as they could be. Then figure out how you can apply instructive design elements to the screens to make the interactions more obvious. Practice is truly the best way to get proficient.

In my book, Designing the Obvious, there’s a whole chapter dedicated to getting users up to speed with instructive design, it also discusses how to error-proof your designs, surface the most important elements in a screen or task flow, make iterative improvements to everything from use cases to live applications, and why we should avoid bending to the whims of users and stick to a vision for our designs.

Moving forward, just keep the principles outlined here in mind as you design application screens. Hopefully, you’ll catch yourself next time you decide to write a paragraph of instructions at the top of the page and try something a little different.

Like this article? Digg it!