Shoot the wizard! Designing a real world form

The web has created some clunky metaphors that suit the limitations of the code rather than supporting the intentions of the user. Forms are a great example of something that has a direct “real world” analogy, yet rarely mirror what happens in the real world.

I sit at my desk and I complete my tax return. Half way through I hear my two month old daughter screaming. I take a break from the form and feed her. When I return it is still on my desk in the same state I left it. Yet my online experience? I get timed out and anything I have done on the form has been lost. Unless I saved the form at that point.

And then there is the wizard. A linear step processes that dictates I complete one page before continuing to the next. Usually the wizard has a step indicator or progress monitor through the form; yet this is rarely a true monitor of progress through the work completed, rather page x of y. Probably this step indicator will not be clickable – if I am on page 3 I’ll be lucky if I can hyperlink back to page 1 and almost certainly I will not be able to hyperlink to page 5.

Forcing me to follow the wizard, down a clearly defined route to complete the form has a number of inherent issues.

• Clearly it is inconsistent with my real world experience of form filling. When I get my tax return through the post I flick through it. I get a feel for it. Maybe I fill out the boxes that I am comfortable to answer now, leaving others till later. I jump around the form in a way that is rarely possible on on-line forms. I don’t have to “register”. I don’t have to “save”. The form is there. I’m in control to do what I want to do with it, not what the form designer wants.
• The wizard is not only inconsistent with my real world experience, it is also inconsistent with my expectations of the web. I browse the web. Yet I cannot browse the form before I complete it. The one, consistent point of reference I have with my experience of the internet is the back button. Yet in many web applications this is removed. Or it behaves inconsistently; i.e. you’ve got two back buttons that behave differently (browser back button moves you to the previous page, back buttons on the page direct you to the previous page in the process).
• With a wizard pushing me down a pre-determined route, I am more likely to feel lost, trapped or unable to complete the form – when I reach a barrier my experience necessarily ends. You need my national insurance number? I don’t have it to hand. I click “next” and an error message appears. “Please enter your national insurance number”. I can hear an exasperated sigh.

There is an alternative to this “command and control”, imperative programming approach. It is a behaviour driven, declarative approach. Ditch the prescriptive wizard and adopt a “hub and spokes” structure to the form. The user navigates around the form, completing it according to their own preferences. With AJAX we no-longer have to post the form on each page transition, this can be done at the field completion level. Dependencies on the form can be dynamically driven rather than being prescribed up-front. There is no need to register first, the user name and password can be anonymous (and stored via a cookie) until the user decides to reveal their identity to us. The user takes control away from the designer. The metaphor for the form becomes the off-line form with the web technology providing enhancements to the experience rather than the limitations seen in so many forms you see today.