Here's the stage:

We have an inspection app on windows mobile. We are considering a html version. There are numerous inspections and there is an internal debate as to whether

  • all questions should be open by default, or
  • each question should be opened as you answer the previous question.

Here is a mock-up with 3 questions, but you can assume there may be as many as 20 questions.Inspection/Form Mockup

Here are some of the debated points:

Option 1. The questions are almost always sequential users shouldn't need to see the next question. Making it require a button press just makes the system more annoying to use.

Option 2. Users want to be able to see all the questions easy, even if they don't need to. Furthermore clicking a button to answer a question takes no more effort than requiring scrolling to see the next question.

Option 3. Compromise and offer both options.

Does anyone have any research on which is better? I was always under the assumption (and I'm positive I read it somewhere) that options 2 & 3 are what users prefer on a handheld device (where scrolling isn't free like on a computer with a scroll wheel).

  • 2
    on the first mockup, are the buttons needed anymore? Commented May 25, 2011 at 13:17
  • good point Adrian. There are some question types where you would want to save an answer, but I'm not sure of the feasibility of those types of questions on a html based form anyway (picture, signature capture, etc). Commented May 25, 2011 at 13:56
  • if you loose those buttons, the first option starts to sound better than the rest (less clicks) Commented May 25, 2011 at 14:07
  • 1
    Prototype both and test them, then let us know how it turned out :)
    – Rahul
    Commented May 25, 2011 at 18:02
  • 1
    Whichever option you select, please give some indication of how many questions there are. On desktops with option1 this can usually be infered from the scrollbars. Without it, I may get fed up with the questions if there are more than I expected or than I find reasonable. In other words: manage expectations. Commented May 26, 2011 at 6:25

5 Answers 5


Off hand, Option 1 sounds better for the reason you give –it’s easier and less error-prone to tap to advance to the next question than to swipe/scroll. The general rule is to use scrolling to avoid arbitrarily breaking up content. In your case, if you can only fit one whole question on the screen at a time, then you’re not being arbitrary. You may find some relevant research cited at Usability.gov's recommendations for scrolling and paging on web sites.

But you also seem to be say that users want to be able to see all the questions “even when they don’t need to.” Is that an observation or an assumption? If you provide scrolling, when do users scroll other than to go to the next question?

Whenever you observe users wanting to do things suboptimally, you should conduct more research to find out why. That will tell you what you need to include in the design, and it may not be that you need to support scrolling. For example:

  • Maybe users don’t always answer the questions in order, so they want to be able to see questions they’ve yet to answer. A better solution to scrolling for this problem would be a checkmark by the question title of answered questions.

  • Maybe users need to look at previous answers to answer a current question. A better solution there would be to summarize the user’s answer in the question title, or provide a means to temporarily see another question’s answer without losing one’s place (e.g., a control that only shows the answer while the finger is held down; lift the finger and the screen jumps back to the current question).

  • Maybe users want to review their answers before committing all of them. A better solution would be a summary screen after than last question. You may also provide a “zoom-out” control they can use at any time.

  • Maybe users want a preview of the next question they’re to answer to judge how to answer the current question. A better solution would be a fisheye view, where you show the needed detail on the next question, but subsequent (and previous) questions are fully collapsed.

  • Maybe user just enjoy scrolling. Perhaps you can have each question open with some equally interesting animation to provide the same level of entertainment.

The third option you show isn’t so much a compromise as it’s a surrender: you don’t know what to do so you push the design decision onto the user. That rarely works out well. Only pursue the third option if it’s an effective solution to a well-understood problem. For example, if may make sense if user research shows that:

  • There are two different user groups, environments, or subtasks where scrolling is better for one but worse for the other (e.g., providing answers versus reviewing answers, where in the first they go through each question carefully while in the second the skim through them)

  • The users will understand when and how to collapse or open all questions as appropriate.


I'm thinking that the 2nd design is the closest to how it would provide the best user experience.

Overwhelming the visitor with an enormous page of question and answers would likely put them off even beginning the task, so option 1 might not be the best route. With the 3rd option you're presenting the option to open / collapse all, but this is only available at the top of the page. Once the person has filled on 4 of the 20 questions they'd have to return to the top to if they decide they want to see everything open. They'd lose their place in the question list here.

For the 2nd design; am I correct in assuming that the next question will expand automatically once you've answered the current question? This is possibly the nicest route as you're leading the user through the form a step at a time rather than just bombarding them with choices right from the off.

However, from a technical point of view I'm not sure how suitable this would be. It will require JavaScript which not all devices would be able to cope with. That would require some thought as to what this app / HTML site will be required to work on.

  • Jon, That's exactly what we're proposing for option 2. You're correct about JavaScript, but this is a paid application, so we can specify minimum requirements for the device (likely the customer will purchase a device just to use the app). Thanks for your thoughts.
    – user5609
    Commented May 25, 2011 at 13:40
  • Purchase a device just to use the app? Sounds like it's an awesome app :) Let me know when it is officially released. Commented May 25, 2011 at 13:43
  • If you think purchasing a consumer grade device to run a web app is expensive - keep in mind our average customer utilizes ruggedized mobile computers from Symbol/Motorola, Datalogic, or Intermec. These are far better devices for the environments our applications are typically used, but the siren call we hear too often is, "Why can't our engineer use his [blackberry, iphone, android]?" Commented May 25, 2011 at 13:53

20 multiple choice questions in one list can be quite overwhelming, especially when viewed on a small device. Can you divide the 20 questions into logical subsections, themes or other natural groups?

If that's the case, you can either expand questions one group at a time, or use multiple tabs or pages. That way you could have 4 to 5 questions open at any time, instead of having to choose between either 1 or 20.

If grouping the questions is not desirable, I'd probably choose your second option (one question open at a time, next question automatically opens when you complete the previous). Unless users really need to look at their earlier answers: in that case I'd display everything at once.


What devices are you targeting? Scrolling is free if you have a decent touch screen, and for older devices you already have a native app.

Assuming that you are targeting mobiles with a browser that supports javascript properly, I'd go with a multipage interface (actually one html page with transitions using javascript).

  • A list of questions - this gives users an overview if they want it
  • For each question, display the options and large buttons for previous/next/list. Possibly include "Question 2 of 3" somewhere to indicate progress. A row of colored boxes representing which questions have been answered could also work well.

Transition between these pages is entirely client side, so is basically the same as scrolling except that you don't end up with half of two questions visible. Buttons are only annoying if they trigger a server round trip on a slow wireless connection.


Your 3rd option you've proposed is the most user-friendly in this case. You've stated in some other answers that people will likely purchase devices specifically for this application. This seems to indicate they will be highly trained, so buttons which allow the user to interact with the application how they prefer will be nice once they become familiar with the application.

While a beginner may be more comfortable with your initial approach of collapsing the questions and paging, etc, a power user will become frustrated by the unnecessary taps after a while.

Think of it like being guided step by step through an airport. The first few times it's nice having your hand held. After that, they're holding you back from quickly getting to where you need to go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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