Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

What happens when a form presents fields in an unorthodox order, or can't group them in traditional ways because of design constraints?

For example, I'm considering a concept for a log-in / registration interface that features a single 'transforming' form rather than two separate pages. It offers a typical log-in form (email / password) that can 'pull up' to reveal further fields if the user needs a new account:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

The issue is that for the design to make sense, I can only reveal new fields at the bottom of the container. This means I have to add the 'name' field at the bottom of the form. But this is very unusual practice: almost all personal forms, both online and on paper, request a name or identifier right from the off.

I'm nervous that this break from convention will prevent users from immediately grokking the nature and purpose of my form. But what exactly are the potential UX consequences of unorthodox question orders or weak grouping of form questions?

Edit: I'm not actually all that interested in the design above - what I'm really wanting to understand is the effect of unusual question order.

share|improve this question
    
Do you really need to collect the name at sign up? –  dnbrv Apr 28 '12 at 15:18
    
@dnbrv - yes, unfortunately. –  Jimmy Breck-McKye Apr 28 '12 at 15:22
    
This sounds way better than losing the info I already entered, or waiting for another page to load. –  Ben Brocka Apr 28 '12 at 16:13

5 Answers 5

up vote 1 down vote accepted

To answer your core question, research and user testing suggest that breaking expectations when it comes to question order can have significant negative effects.

This is because form-fillers don't give forms the same level of attention that we designers like to think they do. We imagine them carefully and diligently reading each label before answering. Instead, they visually zoom in on the fields and answer them if they can, only looking to the field labels when they have to. This is the psychological phenomenon called satisficing: (subconsciously) expending the perceived minimal amount of effort to complete the task.

When users encounter essentially the same form in many places, they begin to form expectations. Filling out these forms slowly changes from a conscious practice to a rote one. It's like how when we are first learning to drive, we have to really attend to what we're doing, but after time, we can drive almost "on autopilot".

To make the most of limited resources, the brain is always looking for patterns that it can use to complete tasks in the future. So, after a while of seeing the same sequence of questions, the brain sees the pattern and begins to call on it in order to fill out the new forms it encounters. If the next form almost follows the pattern, but has at least one exception, the user is likely to either make an error (e.g. type in the answer for the expected field) or be stopped — jarringly — in their tracks. Either way, not a positive experience.

Of course, it's difficult to know exactly what question sequences are noted as a pattern by form-fillers' brains. The example you give may be one; as Myrddin says, you'll only know by testing. It all comes down to:

  • how frequently your target audience has encountered a similar sequence of questions before;
  • how consistent that sequence of questions is across all the existing forms; and
  • how much your form appears to the user to be another instance of those sequence of questions.

Hope this helps,

Jessica

share|improve this answer
    
Hmm, this is what I feared. Certain forms are so common on the web, that users start relying on heuristics to spot them, looking to get the 'gist' of a form's purpose from the nature of the first few questions. I guess my question, then, is: can I quantify the costs of breaking these heuristics easily, or will only user testing tell me if it's worth it? –  Jimmy Breck-McKye Apr 30 '12 at 16:35
    
Unfortunately, I think because of the small sample size, even user testing won't allow you to quantify the cost, unless it's a really significant problem. I've seen things work fine in user testing but break when exposed to the live audience. Couple of options: see if you can make the order the same without compromising other constraints; have an alternative you can quickly switch to if there is a major problem; or build a "backup" into the design (e.g. collect name later) for those cases where it breaks? –  Formulate Information Design May 1 '12 at 2:30

What you should do is conduct a small round of user testing. Take that design, send 5 users to your site and ask them to make a new account. Ask them to verbalize their thought processes (and keep prompting them about what they're thinking when they go silent, because the quiet confusion parts are exactly what you want to hear). You will quickly find out not only whether this login form is confusing, but also a half dozen other things wrong with the site.

My suspicion, sans testing, is that it is completely clear, as long as your scroll-up animation is smooth; the users will know exactly where the email address and password are, the two new fields will not be odd at all.

share|improve this answer
    
I agree with Myrddin. Even if you're not concerned about this particular design, you should always test your question sequence — along with other aspects of the design — with users before implementing. –  Formulate Information Design Apr 30 '12 at 2:13

I don't think this design is quite the right one.

I agree with Myrddin Emrys that user testing would be effective. However, I believe there is another important step that you can take prior to testing -- a quick prototype.

I took your BMML file and used Balsamiq Mockups to emulate the user experience of the transition/animation. I created two wireframes, one for each form state.

I then made 'Create new account' a link to the second wireframe. I made 'I already have an account' a link to the first wireframe. I ran the prototype using 'presentation mode'.

My experience was that the transition felt clunky. For example, the 'Log In' button suddenly became the 'Create Account' button. It didn't seem right.

I believe users would have to rely on recall rather than recognition to understand why the button label (and appearance?) has changed.

share|improve this answer
    
Fine, but that's not really what I'm asking about. I'm asking about the effects of unusual form field order. I've edited my question to make this clearer. –  Jimmy Breck-McKye Apr 29 '12 at 11:28
    
... though the button transformation was also something I was concerned about with this particular concept. –  Jimmy Breck-McKye Apr 29 '12 at 11:45
    
This is actually easily solved. In my answer I did recommend he use a smooth transition. What if the old button rose and faded out, while the new button slid up? That would be an extremely clear visual indicator that it's a different button. Because despite being in the same spot on the screen, with a smooth scrolling transition it has a completely different location on the form. Harder to code though (multiple animations in a single transition). –  Myrddin Emrys Apr 30 '12 at 4:31

I too like the design, but I think perhaps you're missing the point - you're wondering whether they'll be able to figure out how to type in their name after their email (yes I'm pretty sure they will).

What probably you should be asking is will they understand that you need to expand the form by dragging upwards to show the extra fields.

This, as @Myddin Emrys suggests, requires some user testing.

share|improve this answer
    
They wouldn't drag the form up; they'd use a link or control along the lines of 'create account' or somesuch. But I'm not interested in the design itself - I want to understand the effects of unusual question order. –  Jimmy Breck-McKye Apr 29 '12 at 11:40

I like your design. I hope the effect of this untraditional form presentation will hide problems you are afraid of (users will not perceive your form as 'yet another boring form', so will not expect tradition fields order either).

So, there’s no negative effect I can think of. You can add little explaination why you need the name at all, like 'Your real name' or 'Name for the forum', but it's a general advice for any form. Since the field is on the bottom, it will be perceived as something additional or even optional, so you should explain why it's needed.

Also, you do not need to ask user to repeat password if you ask for his email — he can always reset it using mailbox.

share|improve this answer
3  
I disagree about the repeat password; the number of typos you get with a hidden field like that are immense, in excess of 7% in my tests. You do NOT want to re-send a big chunk of new users through password recovery; they will just abandon. –  Myrddin Emrys Apr 28 '12 at 16:17
    
If (to paraphrase) we are "hoping the effect of untraditional form presentation will hide problems", we are not practicing user experience very well. Our job is to create designs that require less effort from users, not more. Moreover, people don't care about the form, and will not attend more carefully to it just because it seems "less boring". All they want to do it get through it to access whatever product or service is on the other side. –  Formulate Information Design Apr 30 '12 at 2:10
    
@FormulateInformationDesign sorry, but design is user experience too tobiasahlin.com/blog/skeumorphism-and-storytelling –  Nikita Prokopov Apr 30 '12 at 13:40
    
Of course design is user experience. My point was that we should be looking for a design that works, not one that hides problems. –  Formulate Information Design May 1 '12 at 2:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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