Supporting Common Pathways And Increasing Simplicity Through Disclosure

Progressive disclosure is a nice term don’t you think? Seems kinda academic when you first read it and then it rather becomes clear, progressively disclosing itself, metaphorically revealing the meaning within. I love it.

Anyway, in UE it refers to the way in which we hide features and functions that are not required, revealing them as the user’s journey progresses. Jakob uses the analogy of the print dialogue box. Going to ‘print’ reveals a stripped down dialogue; page size, orientation, copies. If the user wants more, they click ‘options’ or ‘advanced’ and are shown zoom options, colour settings, resolution, duplex etc. etc.

Stretching the analogy further, we could consider the tree menu system to work as a progressive disclosure. We could think about other examples all over the place on the web. How about the checkout process when you can click to change the delivery or invoice address (and so receive a detailed dialogue) or you can continue to dispatch if the settings are as you wish.

So progressive disclosure is a way of describing simplicity to support the most common pathways. At The Company we try and get masses of this stuff into our online applications. Dynamic layers that open up additional areas of transactional forms when users require a non-standard interactions. We understand that almost everyone is a special case, there are no ‘standard’ customers (and as such we don’t do personas for standard customers). We restrict interactions to the most common operators and offer a second or third set of options on request.

There is a school of argument of course that this prevents people from ever finding these ‘power tools’ but this just smacks of poor design. Make it obvious that there is more you can do and people will naturally explore. Particularly if the first set does not meet their goal. If these request points become decision points (E.g. “have I done all I needed to do”) within the task flow, then that will inform the solution you design. A solution which will ultimately be task focussed and with clear expectations of effect of the user’s action. A notable failure to perform correct user research into an implementation like this can be seen in Word's hidden menus (aside: how to disable hidden menus in Word etc.).

Progressive disclosure has another benefit: perceived hierarchy. By placing the most common activities on the initial part of the process, you are making an implicit statement about its importance; it enables them to prioritise their interaction. This prioritisation solves much of the problem above regarding the perception that the interaction only has a small set of features.

So, to get this right we have had to make some significant decisions: what is first-tier disclosure and what is second-tier? How many options should go into the first tier? (think of only a few … and then remove some), How can we make this initial feature set simple? How shall we reveal and direct users to the second tier?

Well we are solving these problems daily through some obvious UE techniques: Research – we know what our customers do on our site through metrics and qualitative usability testing. We use hierarchical design techniques, card sorting, site mapping and task-flow design to understand what takes priority. We also understand when a linear process might work better, where all features are provided by in a staged disclosure. The trick, as Jakob affirms, is to fit the design to purpose. Is there benefit in progressive or staged disclosure for a given task with a given user group.

Reading this far you will probably have a better idea than you did before.