Designing for Progressive Disclosure

Design Principles, Design Philosophy

UX designers talk a lot about principles, concepts, and theories of design in these sorts of articles and at conferences. But, all too often, when it comes time to design a solution, I see people simply start drawing. They might do whatever looks good or whatever they’ve done before or use whatever solution they already love using or have just found on a design-inspiration board.

As UX designers, we need to approach information design in a proactive way. We need to make conscious decisions about what information needs to be visible and what can be a click or a scroll away, and how much we need to make the user aware of these choices. This is designing progressive disclosure.

Progressive disclosure is one of the many design ideas I first learned about in the early 2000s, but it took a few years to really make this lesson stick. Once I started designing giant enterprise portals, I realized what principles were driving everything. The old ones. Ted Nelson, summarizing his seminal work on hypermedia in 1977, said this:

“The hypertext concept is obvious. The tinkertoy concept may not seem obvious at first. Think yourself to a world of only screens though, and keeping track of what you are looking at and thinking about becomes a fundamental problem.”

However, the problem we must solve is not just one of providing functionality or cutting it down for simplicity, but in making what functionality we do offer apparent, clear, and easy for users to understand.

Drill-down Tactics

Most of the designers I have worked with call the user’s taking an action to get more details drilling down. There are many ways of doing this. Clicking or tapping is just the first step. What happens next is revealing the additional information or functionality. What are some common ways of showing more information?

Popups

I still don’t get why project managers, analysts, and developers love popups so much. So many requirements and user stories actually get written as showing more information in a popup. But, we’ve made some headway in recent years. My survey of how sites and apps offer progressive disclosure shows that there are many fewer popups on the mobile side than just a couple of years ago.

While popup dialogs are fine for some purposes, drilling down to see more content or functionality, as shown in Figure 1, is not one of them. Their context is vague, and controls are often limited. Anyway, users see far too many popups for signing on, displaying error messages, and especially for pushing unwanted promotions and sales.

One way I have successfully used popups is in the form of lightboxes, or image viewing popups, similar to that shown in Figure 2. On mobile devices, it can be especially hard to display images on a page that are large enough or enable zooming without interfering with the rest of the page controls. Using a lightbox lets the user tap an image, opening it in a full-screen dialog, which then allows pinch zooming and scrolling. For complex cases such as diagrams, I have even implemented sketching tools to help mitigate the small-screen issues.

Reasons for drilling down using popups:

• They are easy and quick to implement, often with the smallest amount of code. Native dialogs in mobile apps are very capable, but are prestyled, so easy to build.
• If loading page-wide content or functionality, the dialog context is usually suitable.
• There is no need for a masthead, title bar, navigation, wayfinding breadcrumbs, or action bar. Full-screen popups are especially useful. Aside from the title, most of the viewing area is dedicated to the content or function.

Reasons to avoid popups:

• They are not as contextual as you’d think. Since they hover over the center of the whole page, users can forget what specific element they clicked to initiated them.
• They scroll poorly. While scrolling is technically possible, it can be confusing, causing users simply to miss overflow content.
• Popups are overused, so people often dismiss them without reading their content.

Drawers

The much more contextual cousin of the popup is the drawer, which is a layer—ideally one that is noticeably smaller than a mobile device’s viewport—that emerges from some other user-interface element such as a navigation item, search box, or filter. UX designers often implement menus as large drawers, but they can be any size.

As shown in Figure 3, drawers must be clearly anchored to the link, tab, icon, or other element that launched them, but they do not need to be animated to literally emerge from that element. Aside from the fact that animation slows responsiveness, remember that some users can become disoriented or even ill because of on-screen motion. Therefore, you should avoid animation—or at least code it so, if the operating system accessibility settings can reduce motion, your application respects that.

Reasons for drilling down using drawers:

• Drawers are highly contextual and expand directly to show more information or functionality.
• They are effective if there is only a small, fixed amount of content.

Reasons to avoid drawers:

• If there is too much content or a variable amount of content, drawers scroll poorly and users can miss overflow content.
• Drawers work best if they emerge from a fixed element such as a masthead. They are not as convincing when they open from the middle of a page or a list.

Mouseover Popups

It isn’t possible to implement mouseover on mobile devices in any way that’s worth discussing, but I am bringing it up here because I still have to explain this to project teams several times a year.

One of those misapplied bits of data that have made their way to marketing and business schools is that having fewer clicks is always better. The ultimate extension of this myth is having no clicks at all. So, I regularly get asked whether we could have a popup appear on mouseover. The answer is no.

If you find yourself needing to argue against this, you might as well also remind everyone that hover conditions are also becoming a thing of the past on most computers. For years now, the majority of PCs have had touchscreens. Plus, people with multi-entry systems often switch input methods, between mouse or trackpad and touch, from moment to moment. You can’t tell which mode they’re in, because there simply is no such thing. Basically, we should assume that every device is touch capable at every moment.

Also, the habit of scrubbing the screen by moving the mouse around where the user is looking is far from universal. In fact, I have seen essentially no real-world users work in this way. Intrusive hover states are simply confusing or make an application look broken.

Open pages, drawers, accordions, or dialogs only on click or scroll. Never on hover.

Accordions

An accordion is a title row that expands when the user clicks it, revealing a larger area with more content or functionality, as shown in Figure 4. Accordions are really useful, but also hugely risky.

The biggest issue with accordions is that users get lost while scrolling. An accordion that opens to an area that is shorter than the typical screen height is fine. Users initially see a list of things and tap one to see its details. Then, they can either close it or scroll past it to the next item.

But many accordions contain very long lists of items. So users can easily become lost in the middle and have no idea what section they are in.

If you customize this to be something like the old Windows tree-view control, that is only a little better. The connecting lines certainly help indicate to users that they’re in a subsection, but they still don’t tell them what subsection they’re in.

Reasons for drilling down using accordions:

• You want to display some additional content or functionality immediately adjacent to the summary or title.
• You have only a small, fixed amount of content so can be confident that users would not get lost while scrolling.
• Ideally, if only one accordion is open at a time, you can avoid user confusion about their location in the system. This type of accordion is very good for step-by-step processes such as an ecommerce checkout.

Reasons to avoid accordions:

• If an open accordion is much taller than the typical viewport, users can get lost when scrolling.
• If each accordion’s contents is very similar to that of others, users can become confused about what section they’re in. Users would need to see the title to differentiate each section, but in long lists, the title would scroll off the page.
• If all accordion content is present at page load, there are performance impacts, as well as SEO and accessibility implications. Even though the content is there, sighted users cannot find it. Plus, because users working without style sheets cannot close the accordions, they can overload the page content.

One subset of accordions that I do like a lot is what I call the action row. If a list of items has many actions that the user can take on each row, allow the user to click anywhere on the row to expand a second row that reveals a set of functions.

Accordions of limited size such as these can work very well, without any of the downsides of more typical accordions.

Tabs

Tabs are overused at least as much as dialogs, especially on mobile devices. Many digital products use tabs as their default organizational structure. As far as I can tell, because every desktop Web site uses tabs as their primary navigation, tabs have been declared safe, standard elements.

But really they are not, and they do not work well for mobile navigation—especially as part of a process, or wizard, that reveals additional information sequentially.

Tabs can be implemented as a full page, part of a tabbed panel, as shown in Figure 5, or blocked off as a subset of the page content.

Reasons for drilling down using tabs:

• A set of tabs implies that each tab is more equivalent and equal to other tabs than the items in list solutions such as accordions.
• If tabs are in use in a desktop application, it is worthwhile to attempt to keep similar formats across platforms.

Reasons to avoid tabs:

• If you are designing for mobile phones, the available space doesn’t accommodate many tabs, so even with short labels, fitting more than about three or four tabs is impossible.
• In a step-by-step wizard, when using tabs with process indicators, there is less room to fit the style, icons, and labels for each step.
• Labels usually get cut down to icons only, limiting all users’ understanding of what the tab content actually is.

All my references to tabs assume actual tab-shaped tabs that are above the content and highlight which tab the user is currently on. In any other position on the screen—especially tabs at the bottom of the screen as in native iOS applications—users do not perceive such elements as tabs, but as independent actions.

Avoid tabs at the bottom of the screen. Design tabs so the current tab is clearly active and part of the content it reveals.

New Page

The default response to what clicking a link does is still basically the same as it was in the 1960s and in 1995 when the Web first emerged. Clicking or tapping a link simply loads a new page, state, or view.

When you’re looking at a diagram of a Web site or app, it may seem like there are a lot of pages, but users don’t see the entire diagram, just the pages they view. Hub-and-spoke navigation or drilling down to pages is generally much less confusing than other methods. Take accordions, for example. A page’s title can be anchored to the top of the viewport, preventing users from accidentally scrolling to a new page. Users know where they are and cannot get lost.

Back has long been the most used button in Web browsers and mobile apps, so trust that users can handle this method of navigation. But do code it right. Respect the back stack and history states. Don’t use fake pages that require the user to work with in-page navigation because they won’t.

Reasons for drilling down to new pages:

• This interaction is simple, natural, easy to code, and fully supported everywhere.
• Users easily understand this, and it’s easy to return to the original page.

Reasons to avoid drilling down to new pages:

• If your platform, or framework, is built as a single-page app, page changes can be confusing or cause actions that might break the process.
• If there is other live information or user-entered data on a page, leaving the page would risk losing context or clearing the information the user has entered.
• Users would want to be able to glance quickly at or otherwise switch between multiple contexts.

Performance is often mentioned as an issue here as well, but it’s usually a wash. If you load all the information into some huge page to present it as a dialog, lightbox, or tab state, the initial page load is slower because all the information is already there.

Developers might say they can call that tab content once the user clicks and the new tab state appears. I, of course, say that’s pretty much the same thing as making a new-page call anyway.

Mobile apps usually provide a better presentation framework because icons and other elements are part of the app, so load in just microseconds. The content may load later, if a remote server provides it, but you can use lazy-loading techniques to mitigate this or even prefetch content if you can fairly reliably predict user behavior.

Scrolling

Amazon famously skips almost all linking, as well as the use of accordions and internal tabs, instead displaying very long product pages. Many other services, including The Home Depot, whose site is shown in Figure 6, have since emulated this approach—because it works. There’s no real reason a page needs to be any particular length, so simply add more stuff below.

This works great! Weirdly so. A few items are anchored to provide a jump nav. If users click to see more user ratings, the link takes them to a lower part of the page.

This approach exploits something a lot of product teams still haven’t gotten their heads around: people scroll. If you make the first content compelling enough, users do scroll to read more, get details, or even take actions. I have seen calls to action such as Add to Cart work as well when the user needed to scroll to it as when higher on the page.

Design is critical. You must create hierarchies of information that communicate clearly to the user. For example, sections must have titles that are styled to show clearly that they are section titles.

Reasons for drilling down by scrolling:

• If the information builds on itself linearly, so you’re telling a story, the user slowly exposes more and more content. Product pages and weather services work well like this, with critical details at the top and more content as the user goes deeper.
• If users might just want to explore, they are willing to scroll to see what is available or what options exist—such as for news, entertainment services, or a broad list of product or service offerings.

Reasons to avoid drilling down by scrolling:

• When users are likely to take specific actions or view specific information on widely separated parts of a page, scrolling is less effective. Use another method to display summary information, and allow the user to reveal, then hide it—or quickly jump there and back.
• If your navigation is not floating or is locked to the edge of the viewport, users would first have to scroll all the way back up to the top—either to see key information such as their signed-in state or cart status or to use the navigation bar to move around the site or app. Even if users don’t often use these features, moving away from them can seem like a loss of safety and prevent users from scrolling as much or for as long.

But what about performance? This one isn’t a minor gripe. Because big pages load slowly, this approach is a nonstarter for many teams. Is page load is your key metric? It depends on how you measure. Because page loading isn’t just one thing, and people are not computers. Measuring total page-load times does not reflect how users perceive page load.

If you build a page to load everything that is visible instantly, it doesn’t matter whether the stuff below is still lazy-loading for a long, long time.

Scrolling Sideways

I don’t mean individual side-scrolling pages, which don’t work well at all. But there’s been some good work in the last couple years on what I call the category carousel.

These are often found on media sites and in apps such as Netflix or the Google Play Store, and they’re starting to make their way into ecommerce as well. I find them especially useful in a large stack of categories. The user scrolls down to see the category names, then gets a little clearer impression of what a particular category name means by seeing the category's contents.

Users can usually tap or click to go to a category page, then tap a single product or other item to view it, or they can scroll sideways within a category row to view all of the products inside that category.

Reasons for drilling down by scrolling sideways:

• You have a clear set of products that you can depict visually, in individual, closely related categories.
• If there are a number of these categories, the user can work with them as a matrix of options, scrolling down, then sideways as they explore more—adding multiple dimensions of progressive disclosure.

Reasons to avoid drilling down by scrolling sideways:

• Your content is not well summarized by a graphic. A category carousel doesn’t work well with poor visuals—even with clearly differentiated icons—or with text alone.
• There are multiple levels of hierarchy, so having users navigate through some other method to land on a category carousel of products can be confusing because it suddenly changes the method of interaction and discovery too much.
• Your graphic designers insist on strict adherence to a grid. A carousel must clearly indicate that there are more items, and the only way to do this is have the last item at the right partially visible, so you must ensure that partially scrolled items do not snap to align perfectly. This overlap gives many user-interface designers fits, so if it would be a fight, don’t even try to do this.

Worries about performance can also dissuade a team from taking this approach. Some category carousels contain only a handful of items, then a big See more button at the end lets users navigate to a page with the entire contents of the category. But don’t make users navigate. Instead, use best practices for coding infinite scroll to make this feature work the way users expect, without overloading your servers or their data plan.

Sharing and Trust

Possibly the worst thing to happen to UX design in the last decade or two has been oversimplification.

Simplicity is fine. You should absolutely create products with only as much complexity as is necessary for users to perform their tasks. Show, share, or ask the user to do only what is absolutely necessary. For example, don’t ask for information that you already have or could get with sensors.

But oversimplification takes away too much or tries to hide actual system complexity with a false sense of simplicity. When the user bumps into the edges, it leaves them confused and questioning, and they may trust neither the system nor the information.

One way in which this issue often manifests is in not actually letting users drill down to find more—instead, just showing them the key information and making them decide based on that.

I first became aware that this was a problem with mid-2000s ecommerce. Think of a typical product sheet for electronics. Scroll down a bit, and there’s a tabbed or accordion section of basic info, technical specifications, and reviews.

Long ago, some ecommerce stores noticed that very few people clicked things such as technical specifications. Then, they usually clicked to another tab within moments. Clearly, users weren’t reading the information, so they removed the whole tab.

And then, sales plummeted.

Why? Trust. While almost no one actually reads the details, lots of people glance over the data, note that it is there, so know the store had nothing to hide. The customers have faith that, if they needed to check the details or ask a friend, they could. Therefore, they can trust the summary information.

Always show slightly more information than the typical user needs. This policy has served me well—and has proven out in usability testing for many products.

Measurable or Useful

Let me finish with one warning about many of the techniques I have covered in this column. The metrification of everything.

Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.

We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.

Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.

Any time you’re reading an article and it says “Click to read more,” that’s not for any human-centered reason, nor for some obscure API or database reason, but because the site can measure clicks. The article publisher gets more money for ads past each click because users are seemingly engaged.

Be aware that you may get pushback on some of the progressive-disclosure techniques I’ve described in this column. Because these clicks don’t work the way everyone is used to measuring clicks, the perception may be that you’ve broken the site or app. But don’t just push back once this happens. Instead, make everyone aware of this issue up front, and include different and better ways of measuring results in your project planning.

Resources

Google. “First Contentful Paint.” Tools for Web Developers, February 12, 2019. Retrieved April 18, 2020.

Jehl, Scott. “Excerpt: Responsible Responsive Design.” UXmatters, April 23, 2019. Retrieved April 18, 2020.

Hoober, Steven. “Designing for Intrinsic Understanding.” UXmatters, March 4, 2019. Retrieved April 18, 2020.

Hoober, Steven. “Paging, Scrolling, and Infinite Scroll.” UXmatters, November 5, 2018. Retrieved April 18, 2020.

Hover. “What Ever Happened to Webrings?” Hover, July 7, 2015. Retrieved April 18, 2020.

Nelson, Theodor. “Ted Nelson’s Published Paper on Computers and Interaction, 1965 to 1977.” Internet Archive, February 1977. Retrieved April 18, 2020.

Schoonmaker, Kara. “Hypermedia.” Chicago School of Media Theory, Winter 2007. Retrieved April 18, 2020.

Spillers, Frank. “The Glossary of Human Computer Interaction: 44. Progressive Disclosure.” Interaction Design Foundation, undated. Retrieved April 18, 2020.