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.

Body off Baywatch, face off Crimewatch ... do customers prefer it to function, look good or both?

Fortunately in the blogosphere (eeugh) someone somewhere will be talking about a topic that's pertinent to your current interests. This week my regular read of Marc’s dancingmango site hit a nerve (in a good way) by talking about transactional regions (“Most retail banking web presence is just not connected”). At The Company my colleagues and I were recently debating whether transactional areas should look different from static ‘brochureware’. I think they should, or at least that it doesn't matter if they don't. In the olden days, Jakob used to say that web-based applications shouldn’t ape browser interraction. But this was before XHTML and JavaScript reached near universality and the vast majority of users expect a rich interface.

Marc’s spoken in the past about breaking free from linear form completion in a wonderful post (“Shoot the wizard! Designing a real world form”) and I support this idea of complete user control. Where I differ from him, and to return to the point, is that I believe customers appreciate a pared-down approach to look and feel on transactional sites. Yes there are legacy issues and, from our own back-end, I know these things tended to have been built by systems guys rather than web designers but the effect has been that there tends to be less distractive marketing guff (page bloat is another thing .. see below) and provided they’ve been interatively designed and user tested, things tend to work functionally.

I’ve mentioned in the past that I think the future will see us move to a more conversational web and increasingly customers will eschew sites that hark back to the days of padded table cells in favour of sites where the brand fits their expectations and aspirations - but we’re not there yet. We’re still, as consumers, focussed on speed and task efficiency and so sometimes keeping the box of crayons away from the menu board helps keep this focus. That said I am aware of situations where non-native web coders (and by that I mean teams where the day job is back-end code) have been left to develop the presentation layer and the result is bloated code, high page weight and long download times. Not to mention accessibility and cross-browser compatability issues.

In short, I don’t think we need to sweat it too much when transactional elements measurably work but don’t look great but I do think we need to worry when we separate static from transactional for cost and infrastructure reasons only to find that we’re suddenly using a top-nav where a left nav was before and the page loads would test the patience of a narcoleptic sloth. Marc cites some great examples where this disconnect has resulted in sloppy coding on transactional sites (HSBC image and First Direct image).

My final caveat is that this holds true for financial services sites and the more tedious transactional elements online. It’s pretty brand dependant; Lloyds TSB for example don’t need an exciting online banking service, they need one that’s quick, fully functional, compliant, compatible and secure. On the other hand if the Apple store was all this but visually dry and plain you’d start to feel a disconnect with the brand because, for someone like Apple, their consumer brand runs right through the entire customer lifecycle.