I’m going on the assumption that once you put people into a wizard their primary purpose is completion hence cancel, etc. are really “bail outs” vs. core to the task at hand -thanks~

I believe that there’s a lot more to the content/chrome relationship than this frequently-stated ‘chrome should seem invisible’ mantra – and here, of course, invisible implies non-distracting, as it’s not actually invisible. However, the notion of invisible chrome only makes sense when the user’s focus is on the content.

While generally giving focus to the content over the chrome is a worthy goal – visitors come to your site for its content, not those groovy animated buttons you slaved over – it’s only part of this design issue. While chrome often disparagingly refers to visual clutter, if we define chrome as the essential but non-content elements of the page, then the more important objective is to ensure that the chrome elements are ‘instantly available’. When the user’s focus is on the content, they don’t fight for attention, but when the user’s focus moves to them, they become very present.

Achieving this balance primarily means ensuring that the chrome elements are where the user expects them to be. The assumption that a site identifier such as a logo will be in the top left of the page is a common example of this “anticipation of location”.

But to be more specific, “instantly available” means: immediately and unambiguously identifiable as the sought element when needed.

So in this Next/Previous button example, as Luke clearly illustrates, not only the location of the button, but also its styling and the wording of its label, and the positioning, styling and labeling of other buttons need to be considered.

You can quick-test for ‘instant availability’ through observation during testing – if, after the user completes each content interaction, the mouse immediately goes: move, click! in a smooth, confident action, you can yourself be confident that you got it right.

The continual transfer of attention between content and chrome is central to the user’s interaction with our design, and user fatigue sets in quickly if we don’t design and test to ensure that both are “instantly available” as needed. Often, because the user’s past experiences play heavily into the anticipation of where specific elements will be located, this can simply mean following the well-evolved and thoroughly-tested design patterns of large, successful sites.

In Luke’s article, he described a different approach whereby the form provides only a “Continue” function, in which case the user is provided with a confirmation of the information entered, and the opportunity to make changes. I think that is a fantastic approach in many cases, but it’s important to let the user know that the confirmation page is coming, or they can become frustrated (feeling that they have to start over, or to continue to the end just to find out they can’t correct their choices).

I’ve seen this done well with progress bars, etc, but I’m wondering how you would take an approach like that if the users’ choices are able to branching in the process, which make it difficult or impossible to forecast the steps between the current one and the confirmation / changes page? Any suggestions out there?

The use of multi-part forms increases complexity behind the scenes too. A well-designed form can reduce the back-end coding complexity, and thus reduce the likelihood of faults and vulnerabilities being introduced to the code. Every time a user moves forward or backward, the data needs to be re-validated and re-displayed. Like the chrome, the code when it’s working well, should also seem invisible and natural.