12

I am given the task to design a lengthy web form that asks a user to enter a lot of information on a technical installation he planned/built. Given the nature of the required data (there are different chunks, nearly all fields are required, and there are some dependencies that suggest a certain order) I organized into a wizard. However, after dividing the process into clear main steps (the easy part) I was still left with enough input fields to justify further grouping.

In this "second level" of data input, however, chunks are not necessarily ordered or dependent and I expect there to be more going back and forth (although most users will just go ahead from group to group). In consequence, I considered

a) a tabbed structure which allows "free" jumps, while still hinting at a from-top-to-bottom approach as the standard procedure and

b) a secondary wizard-thingy with another set of "substeps", which is more rigid

EDIT: c) another possibility would be to create a secondary level right inside the wizard to illustrate the substeps. It would work just as b), but communicate this with different visuals.

Mockups for suggestions a and b Mockup for suggestion c

This is a similar question to this one, and basically my suggestion is a combination of the two approaches in the accepted answer, however, they are there presented as alternatives, not in combination. It is also one approach to answer this question about long wizards, but one that wasn't discussed there.

My questions are:

  • Does anybody have experience with this kind of two-tiered approach? Are there possible pitfalls I have to be aware of, or is there something completely inadvisable about this? (some reading suggests not to mix tabs and wizards, but this refers mostly to "don't use tabs when the functionality is wizard")
  • Instead of tabs I also considered an accordion style for the secondary level (much like this jQuery example or this answer here). However, other comments I read around here state that accordions are "lame" or "old school" or "only for mobile" without much detail beyond that. So what would be actual drawbacks in this given situation?
  • I currently lean towards the rather rigid two-level wizard. As I said, most fields are required and important and I have not yet a found a need to jump ahead. In this case I wonder how to design the forward/backward navigation. The current Next button is supposed to jump to the next substep, while the last step contains the "to the next main step" button. However, I'm not quite satisfied with this yet as it may confuse users. Any ideas, experiences?
Improve this question
6
  • Funny tidbit: I managed to not notice the humongous red alert that said you can't post images, and only got suspicious when my question didn't show up in the user profile... Thank god there's a back button... And so much for users and warning alerts.
    – Louise
    Jun 26, 2012 at 12:46
  • Do you allow moving back and forth in the process? Perhaps you can take some inspiration from the way complicated electronic tax forms like the one we have in the Netherlands work. I find them easy to use here, even though they are complicated and require many fields to be entered in some cases.
    – André
    Jun 26, 2012 at 13:00
  • @André: The requirements do not specify this issue. From some of the dependencies it is clear that we (as designers) have trouble in deciding what to display should the user skip ahead > hence the strict wizard pattern. Going back to correct something has to be possible, however. Are the forms you mention available online somewhere? (from Germany ;) )
    – Louise
    Jun 26, 2012 at 15:42
  • You should be able to download the software from belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/…
    – André
    Jun 27, 2012 at 8:55
  • The only difference between your three examples is the design. Personally I'd prefer a combination of the 2nd and the 3rd (the 2nd with checkmarks to the left of the tab headers).
    – Danny Varod
    Jun 27, 2012 at 13:52

3 Answers 3

Reset to default
2

If I had to choose I would vote for the third of the presented options. It has more intuitive progress indicator that feels the most natural (in the set of proposals you presented).

If I had to suggest an approach to a long wizard problem I would propose to reverse the relation: do not force them to fill all the required information, just allow to add an installation info entry and mark it as not complete ("your installation info is 10% complete"). This allows a user to enter the information in piece-by-piece style while she is pulled towards completion of the information, rather than forcing to fill all the info at once. It also simplifies a design of the installation "profile" page.

Improve this answer
2
  • Your suggestion sounds great. However, the client explicitly rejected a sign up/login solution, as the process is one you would go through every other year (or even only once) and only for one project at a time. Hence there will be no "member profile" where one has an overview over various data records and their completion status. If we had, I would definitely agree with your approach to loosen the step-by-step-rule.
    – Louise
    Jun 27, 2012 at 11:36
  • Once-a-year condition definitely changes the situation :) Just remember about a "back" button.
    – Bartosz Rakowski
    Jun 27, 2012 at 11:52
1

Who says accordian are oldstyle? I am very much in favour of accordion style wizards that gradually reveal the questions and also provide feedback about the answers already given.

I did one of these for a financial questionaire for a client: enter image description here

They are also used in a lot of well designed checkouts like the one at harrods and John Lewis.

Benefits are:

  • You can progressively disclose questions depending on answers (so you can change progression through the wizard.
  • Users have a good understanding of where they are at all times.
  • Users have an overview of the answers already given and can easily return to them. I think this covers your forward/backward navigation issue.
  • It makes the length of the wizard feel shorter, as questions are all presented on one page.
Improve this answer
2
  • I would question the assumption that an accordion "makes the length of the wizard feel shorter, as questions are all presented on one page." Presenting questions piece-by-piece as in a tabbed wizard can make the process seem less burdensome, and also submitting the first step in a tabbed wizard creates a sense of commitment to the process (resulting in decreased abandonment). See The Secret Objectives of Queues - the point "It commits guests to the attraction".
    – Mike Eng
    Jul 9, 2012 at 16:20
  • Please feel free to add an answer to my bounty question about when not to use an accordion (: Sounds like you have an interesting perspective.
    – Lisa Tweedie
    Jul 9, 2012 at 16:31
0

Based on your wire-frames above, I believe you are already on the right track. I would suggest though to create a smaller similar sub-wizard underneath the primary wizard bar to keep page consistence. With some slight tweaks that can be seen below, you can supply additional clarity of where a user currently is in the process with a simple arrow. To allow navigation between the different steps just turn the title of each step into a link.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Improve this answer
2
  • 4
    I find this design confusing. It isn't imeadiately obvious which step the substeps relate to.
    – Lisa Tweedie
    Jun 27, 2012 at 15:02
  • 1
    @Lisa: Agreed. I think the secondary level should deliberately look different so that it is not confused with the primary one. For this approach I'd prefer my third mockup, which marks the subsets as subordinate and puts them right under the corresponding main step. But thanks for your thoughts!
    – Louise
    Jun 28, 2012 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.