Divebomb or the Dipping Toe: Onboarding vs. Progressive Disclosure

Person hiking through mountains with pack overflowing with supplies.
Luke Jones

Product Designer

Luke Jones

We’ve all been there: you sign into a web application for the first time and a window pops up asking you to take a tour of the product. The application guides you through features; there are flashing orbs, glowing rectangles, big arrows, and text boxes that cover the screen until you do as the application says.

This is called onboarding, and the person who created the onboarding experience hopes it will make you an expert of the application you are using. But instead of gaining encyclopaedic knowledge of the web application, it’s more likely that you searched for a button to skip or dismiss the feature tour.

A typical reason for onboarding is that users aren’t harnessing features of an application in the way a product team intends. The natural response to this is to spin-up an onboarding team and figure out a way to teach the user the intended use. The most common result of this thinking is the upfront onboarding I just described.

As creators of web applications, we believe a successful product is intuitive and delightful to use out of the gate. There is no fragmentation in the experience and it has a harmony as a person uses it. Upfront onboarding is the antithesis of these principles.

Progressive Disclosure

It’s naive to assume every piece of functionality in applications we design are intuitive. Some features won’t be used by everyone so it’s okay if you need to give someone a gentle nudge in the right direction.

While working on the video library team at a startup, I was asked to tackle the problem of users wanting to modify more than one video at a time. The user interface was complex and I didn’t want to add further complexity by having omnipresent checkboxes, so I landed on a design with transparent checkboxes over video thumbnails.

I was aware of the risks of making multi-select less visible, so I wanted to figure out a way of making users aware of the functionality in the least jarring way possible. My hypothesis was that users would respond well to progressive disclosure, an interaction design technique to reduce cognitive overload in an application, to teach the user how to do something at the time when it was most appropriate.

I landed on creating two separate prototypes and recruiting two groups of people of varying ages, skills, and experience for some user research. The sessions were 30-40 minutes long and had participants performing a number of tasks, two parts of which involved making changes to videos en masse.

Group 1 was shown the above onboarding message at the beginning of the user test. They were then asked to perform several tasks such as adding new footage and modifying existing videos before being asked to delete multiple videos from their library. Nobody in this group had read the initial message and took the long route to delete multiple videos (one-by-one).

Group 2 wasn’t shown this message and went straight into the tasks. But after they had performed the same task on several videos, the onboarding message popped up to say ‘Hey, did you know you can do this more quickly?’ with a gif of how to select multiple videos. Every person in this group read the modal and went on to use multi-select throughout the session.

To check the retention of this knowledge, I asked both groups to show me how to ‘tidy up their library’ by removing videos at the end of the sessions. Everybody from Group 2 used multi-select instantly. After several rounds of research, it was clear progressive disclosure was a great success.


Showing a person a lot of information up front causes cognitive overload and often isn’t the most effective way to solve the problem of users not understanding product functionality. Feature tour style onboarding may seem like a quick win for your product team, but it could be less successful than other techniques.

In interaction design, progressive disclosure is the equivalent of spotting when someone needs a hand and asking them if they want some help. They can say ‘no thank you’ if they want, or they can accept the help. Being in the frame of mind and scenario where they want to do something in a quicker, easier way opens them up to learning and, most importantly, remembering how to do it.

Footnote on research

All participants who used multiselect were asked how they found it, if they said ‘I just knew it would be on the thumbnail’ then I would exclude them from results about onboarding or progressive disclosure to not skew results.

DockYard is a digital product agency offering custom software, mobile, and web application development consulting. We provide exceptional professional services in strategy, user experience, design, and full stack engineering using Ember.js, React.js, Ruby, and Elixir. With a nationwide staff, we’ve got consultants in key markets across the United States, including San Francisco, Los Angeles, Denver, Chicago, Austin, New York, and Boston.


Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box