Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Better Form Design: One Thing Per Page (Case Study)

In 2008, I worked on They wanted a single-page checkout with the trendiest of techniques from that era, including accordions1, AJAX and client-side validation.

Each step (delivery address, delivery options and credit-card details) had an accordion panel. Each panel was submitted via AJAX. Upon successful submission, the panel collapsed and the next one opened, with a sliding transition.

It looked a little like this:


Boots’ single-page checkout, using an accordion panel for each step. (View large version3)

Users struggled to complete their orders. Errors were hard to fix because users had to scroll up and down. And the accordion panels were painful and distracting. Inevitably, the client asked us to make changes.

We redesigned it so that each panel became its own page, removing the need for accordions and AJAX. However, we kept the client-side validation to avoid an unnecessary trip to the server.

It looked a little like this:


Boots’ checkout: Each step became its own screen. (View large version5)

This version converted much better. Though I can’t remember the exact numbers, I do know that the client was happy.

Six years later (2014), when I was at Just Eat, the same thing happened. We redesigned the single-page checkout flow so that each section became its own page. This time, I made a note of the numbers.

The result was an extra 2 million orders a year. Just to be clear, that’s orders, not revenue. The number is based on a percentage increase to conversion at checkout after releasing the new version for at least a week. The percentage was then converted to orders and multiplied by 52.

Here are some of the mobile-first designs we used:


Just Eat’s checkout split up into pages. We also had a design that further simplified the payment page: The user would first choose “Pay with cash” or “Pay with card,” which would then go to a page with the relevant form on it. Unfortunately, we never tested it. (View large version7)

A couple of years later (2016), Robin Whittleton of GDS told me that putting each thing on a page of its own was a design pattern in its own right, known as “One Thing Per Page.” Apart from the resulting numbers, there is a strong rationale behind the pattern, which we’ll get to shortly.

Before we do that, though, let’s take a look at exactly what this pattern is.

Further Reading on SmashingMag: Link

What Does “One Thing Per Page” Mean Exactly? Link

One Thing Per Page is not necessarily about having one element or component on a page (although it could be). In all likeliness, you’ll still have, for example, a header and footer.

Similarly, it’s not about having a single form field on each page either (although, again, it could be).

This pattern is about splitting up a complex process into multiple smaller pieces, and placing those smaller pieces on screens of their own.

For example, instead of placing the address form on the same page as the delivery options and payment forms, we would put it on a dedicated page.

An address form has multiple fields, but it’s a single, discrete question that is being asked of the user. It makes sense to tackle this question on one screen.

Let’s consider why the pattern is so good.

Why Is It So Good? Link

While this pattern often bears wonderful and delicious fruit (or orders and conversions, if you hate my analogies), it would be nice to understand the rationale behind it.

1. It Reduces Cognitive Load Link

As Ryan Holiday describes in The Obstacle Is The Way:

Remember the first time you saw a complicated algebra equation? It was a jumble of symbols and unknowns. But when you stopped to break it down and isolate the parts, all that was left was the answer.


An equation broken down step by step is easier to solve. (View large version13)

It’s the same for users trying to complete a form, or anything else for that matter. If there is less stuff on screen and only one choice to make, then friction is reduced to a minimum. Therefore, users stay on task.

2. Handling Errors Is Easy Link

When users fill out a small form, errors are caught and presented early. If there’s one thing to fix, then it becomes easy to fix, which reduces the chance of users giving up.


Even with several errors, Kidly’s address form is easy to fix. (View large version15)

3. Pages Load Faster Link

If pages are small by design, they will load faster16. Faster pages reduce the risk of users leaving, and they build trust in the service.

4. Tracking Behavior Is Easier Link

The more there is on a page, the harder it is to determine why a user has left the page. Don’t get me wrong: The ability to analyze a page shouldn’t drive design, but it is a nice byproduct.

5. Tracking Progress and Returning to Previous Steps Is Easier Link

If a user submits information frequently, we can save it in a more granular fashion. If a user drops off, we can send them an email, prompting them to complete their order, for example.

6. Scrolling Is Reduced or Eliminated Link

Don’t get me wrong: Scrolling isn’t a big deal17 — users expect web pages to work that way. But if pages are small, users won’t have to scroll. And the call to action is more likely to appear above the fold, which reinforces the requirements, making it easier to proceed.

7. Branching Is Easier Link

Sometimes we’ll send users down a different path based on a previous answer. A simple example would be two dropdown menus; what the user chooses in the first will affect the values shown in the second.

One Thing Per Page makes this simple: The user makes a choice and submits, and the server works out what the user sees next — easy and inclusive by default.

We could use JavaScript18. But it’s more complicated to build it and ensure that the UI is accessible. When JavaScript fails19, the user might suffer a broken experience. And loading the page with all of the permutations and options could add significant page weight.

Alternatively, we could use AJAX, but this doesn’t free us from having to render new (parts of) screens. More crucially, it doesn’t negate the server-side roundtrip.

That’s not all. We’d need to send more code to send an AJAX request, to handle errors and to show a loading indicator. Once again, this makes the page slower to load.

Custom loading indicators are problematic because they aren’t accurate, unlike the browser’s native implementation. And they aren’t familiar to the user — that is, they are specific to the website showing them. However, familiarity is a UX convention that we should break only if we really have to.

Also, having two or more fields that are dynamically updated on one page depends on the user interacting with the fields in order. We could enable and disable or show and hide fields, but this is more complicated.

Lastly, a user could make a change that requires a subsequent panel to disappear or be replaced by a different panel, which is confusing.

8. It’s Easier for Screen-Reader Users Link

If there is less on a page, then screen readers don’t have to wade through a lot of superfluous secondary information. Users can navigate to the first heading and start interacting with the form more quickly.

9. Amending Details Is Easier Link

Imagine someone is about to confirm their order. Crucially, they spot a mistake with their payment details. Going back to a dedicated page is far easier than going to a section within a page.


Clicking “Edit” takes the user to the payment page, with a dedicated title and related form fields. (View large version21)

Being taken halfway down the page is disorienting. Remember that the user clicked a link to perform a particular action — having other things on the page would be distracting.

It’s also potentially more work. For example, if you want to show and hide panels within the same page, you’d need extra logic to handle it.

With One Thing Per Page, these problems fade away.

10. Users Get Control of Their Data Allowance Link

Users cannot half download a page. It’s all or nothing. Smaller pages save user’s data. If they want more information, they can click a link, getting the ability to choose. Users don’t mind clicking22, as long as each step brings them closer to their goal.

11. It Solves Performance Problems Link

If everything is one gigantic thing — the extreme of which is a single-page application — then figuring out performance problems is hard. Is it a runtime issue? A memory leak? An AJAX call?

It’s easy to think that AJAX improves the experience, but adding more code rarely leads to a faster experience.

Having complexity on the client obscures the root cause of problems on the server. But if a page has one thing, then there’s little chance of performance issues. And if there is an issue, then finding it will be easier.

12. It Adds a Sense of Progression Link

Because the user is constantly moving to the next step, there is a sense of progression, which gives the user a positive feeling as they fill out the form.

13. It Reduces the Risk of Losing Information Link

A long form takes longer to complete. If it takes too long, then a page timeout may cause the information to be lost, leading to tremendous frustration.

Alternatively, the computer might freeze, which is the case for Daniel, the lead character in I, Daniel Blake. With declining health and having never used a computer before, he suffers from a frozen computer and lost data. In the end, he gives up.

14. Second-Time Experiences Are Faster Link

If, for example, we store the user’s address and payment details, we can skip these pages and take them straight to the “check and confirm” page. This reduces friction and increases conversion.

15. It Complements Mobile-First Design Link

Mobile-first design encourages us to design what is truly essential for small screens. One Thing Per Page follows the same approach.

16. The Design Process Is Easier Link

When we’re designing a complex flow, breaking it down into atomic screens and components makes it easier to understand the problem.

It’s easy to swap screens to change the order. And analyzing problem areas is easier when, like the user, we’re looking at one thing at a time.

This reduces the design effort — which is a nice byproduct of a pattern that benefits users so greatly.

Is This Pattern Suitable In All Situations? Link

Not always. Caroline Jarrett, who first wrote about One Thing Per Page23 in 2015, makes this quite clear. She explains that user research “will quickly show you that some questions will be best grouped into a longer page.”

However, conversely, she also goes onto explain that “questions that naturally ‘go together’ from the point of view of designers… don’t need to be on the same page to work for users.”

She provides an enlightening example when, for GOV.UK Verify, they tested putting “Create a username” on one page and “Create a password” on the next.

Like most designers, Caroline thought that putting these two form fields on separate pages would be overkill. In reality, users weren’t bothered by this at all.

The key point here is to at least start with One Thing Per Page and then, through research, find out whether grouping fields together would improve the user experience.

That is not to say you’ll always end up combining screens together — in my experience, the best results come from splitting things apart, period. I’d love to hear about your own experience, though.

Summary Link

This inconspicuous and humble UX pattern is flexible, performant and inclusive by design. It truly embraces the web, making things easy for high- and low-confidence users.

Having a lot (or everything) on one page might give the illusion of simplicity, but like algebraic equations, they are difficult to deal with unless they are broken down.

If we consider a task as a transaction that the user wants to complete, breaking it down into multiple steps makes sense. It’s as if we’re using the very building blocks of the web as a form of progressive disclosure. And the metaphor behind pages provides a subconscious sense of moving forward.

I’ve not come across another design pattern that has as many benefits as this one. This is one of those times when simple is just that: simple.

(cc, vf, yk, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

↑ Back to top Tweet itShare on Facebook

Adam Silver designs simple, human and inclusive websites. He also wrote a little book called MaintainableCSS.

  1. 1

    There is a lot of self promotion in this post, even if I do agree with the main thrust of the article. I’d like to know how the author arrived at the “2 million extra orders a year” for Just Eat when they were surely a million other factors involved in that than the checkout design, e.g. huge investment and growth due to things like TV advertising etc.

    If the author means that he saw a percentage increase in conversion rate overnight which when extrapolated would have lead to 2 million extra orders over the course of the year compared to their normal conversion rate and normal sales volume then fair play.

    Like I said, good article, but sounded very much like self promotion.

    • 2

      Adam Silver

      May 22, 2017 1:32 pm

      Yes, based on percentage.

      • 3

        Did you subtract any possible trend growth from your calculation? How long after the change did you take your conversion trend from?

        • 4

          Adam SIlver

          May 23, 2017 3:14 pm

          The stats were delivered very soon after the new checkout was released.

          More importantly, they were given as a percentage increase to conversion, when the user went to checkout. So should be an honest way to represent the results from the work delivered.

    • 6

      Exactly my thoughts too!

    • 7

      Syron Bowman

      May 23, 2017 6:38 am

      I didn’t really notice the self promotion because I felt the content to be really good.

  2. 8

    Barry Rutter

    May 22, 2017 2:35 pm

    I’m interested in the writers thoughts on a long form i.e a trade exhibition / conference or an insurance form, and should that form continue to have the steps breadcrumb if for example you end up having 10 or so pages in the form?

    • 9

      Well, I think that consumers would know getting insurance is not an easy 1,2,3 task. Therefore, a form with 10 pages would seem appropriate since you’re applying for insurance not buying something off Amazon.

    • 10

      Peter Laughton

      May 23, 2017 10:29 am

      You may even want to consider more than just a multi-page form – actually breaking up the process into different forms.

      We have had significantly higher conversions (like 3x) with a registration form in the B2B space when we initially ask for absolute minimal info (name, email), and then after completing the registration ask for personal and marketing details.

      Unfortunately we only measured registrations and so I cannot comment if personal details completions were higher/lower – that would be an interesting stat.

      If you absolutely have to have these additional details (such as for an insurance form), then it may be something that can be followed up with auto-email and/or telephonic queries.

      • 11

        Adam SIlver

        May 23, 2017 3:19 pm

        Yep, great way of doing things if the problem lends itself to that solution, like the one you mention. Would love to hear more about what you’ve experienced with this.

    • 12

      Adam SIlver

      May 23, 2017 3:18 pm

      If I understand the question correctly, you’re asking if there should be a progress bar to let the user know where they are in the flow, even if you have a long process?

      If so, I have not done testing on this personally. GDS has some interesting guides showing that they haven’t been valuable on the tests they have conducted.

      They also suggest that if a progress bar is necessary that “3/10” might be all you need.

      I’d love to run some tests, because it would be nice to kill a feature that doesn’t add value and therefore reduce the noise/increase speed etc.

      • 13

        perhaps a stupid question but how do you user go to the previous screen in the JustEat example? Or do you just rely on the browser back function?

    • 14

      Craig Morrison

      June 1, 2017 2:00 pm

      I work on GOV.UK services with long forms, maybe 5 sets of 10 pages and lots of permutations.

      We originally started with section-base progress and question history on the page. We’ve found a lot of that to be unnecessary for our users and also difficult to adapt to mobile use. Seperate overview or summary screens are generally more effective.

      Allowing the user to review and change information is a big usability benefit. For most services that need large forms some kind of solution for this is also part of complying WCAG.

  3. 16

    Does this only apply to mobile ordering? I’m wondering if having to click next a bunch of times on a desktop website would be annoying to a user.

    • 17

      Adam Silver

      May 23, 2017 7:30 am

      Boots was before “mobile”.

      The Just Eat numbers are for the responsive site.

      The checkout had the same layout on desktop, but naturally with more whitespace.

      Counting clicks is not something I would suggest analysing in isolation of the overall experience.

  4. 18

    Agree with others it seems a little self-promoish (especially when “millions” has no context).

    However, while people don’t want to admit to dark patterns – one of the biggest advantages to a multi-page flow is the sunk cost bias a user perceives after each step. This is probably nearly as important as reduced cognitive load.

    Get em in with as low as cost fields as you can (remember forms are a conversation!) and show progression so they want to finish.

    • 19

      That could be considered a dark pattern. But, honestly IMO, it’s just more of a natural pattern of behavior.
      When you meet someone IRL, you don’t immediately ask for deeply personal information or invade their personal physical space. You ask about the lighter stuff and grow trust (or not) during the conversation.

  5. 20

    Jeremy Cook

    May 22, 2017 4:50 pm

    We draw from what we are familiar with. It felt like that to me, not self-promotion. Thanks for sharing your experience.

  6. 21

    Thank you Adam for this article. I have a question. What do you suggest to do on desktop? Should be one page checkout or it should be still one thing per page?

    Apart from it – numbers are great!

    • 22

      Adam Silver

      May 23, 2017 7:33 am

      Boots happened before the rise of mobile so that was something that worked really well on desktop (large screens).

      Just Eat was a responsive site so it worked well for both small screens through to large.

  7. 23

    Tommy Hodgins

    May 23, 2017 2:56 am

    This is a great reminder of a good practice, and don’t worry – after reading through the whole thing no part of the post came across to me as self-promotion.

    Thanks for making a compelling case for ‘layout simplicity’. My experience has been the exact same – over time I’ve been hired again and again to break things apart further and simplify, not usually to consolidate them together.

    • 24

      Adam Silver

      May 23, 2017 7:26 am

      Thanks Tommy, would love to hear any experiences you have on this.

      Do you have anything out there I could read?

  8. 25

    Great article and well stated, Adam. Don’t let Jon’s comment worry you. I didn’t get a sense of self promotion. It’s not self promotion to say “This is what I do/did and reasons why and here’s some data to back it up.”. Only thing I’d add is that on the confirm and pay screen, when users can edit a portion or a “page” of the process, they should be able to either move back through the stages or jump back to the confirm and pay screen. It is a drag having to go through all pages again when a user edits something on page 2 of 6. #My2centsWorth.

    • 26

      Adam Silver

      May 23, 2017 7:22 am

      Yes, absolutely, Joe.

      Point 14 mentions this, but not specifically to the scenario you raise.

      It could have been clearer.

      Thank you.

  9. 27

    Some good tips and a good reminder not to overload the user with information, especially on mobile.

    However, one thing that irks me slightly is why are we trying to give this pattern a name when one already exists, which is:

    Wizard design pattern

    Would have been nice to give some acknowledgements to designers and researchers who talked about this core concept over 15 years ago and not present this as something completely new.

    From 2001

    Books for historical study

  10. 28

    Hello Adam,

    What I do on my own very complex and long forms is hidding parts as long as the previous parts have not been completed.

    Let’s say I’ve got 18 fields corresponding to 3 sections with 6 fields in each section.

    I’ll wait for the user to fill in the first section (6 fields) before showing him the 2sd section. Accordingly, the user won’t see the 3rd section before he has completed the 2sd one.

    What do you think? Is it as good as breaking the form into multiple pages?

    IMHO, the main benefit of my way would be that the user can review its entire submission without having to go through multiple pages.

    Best regards,

    • 29

      Adam SIlver

      May 23, 2017 3:32 pm

      Great question, Guilamu.

      Disclaimer: What I think and how it performs are two different things. If you’re planning to conduct some user research, I would love to hear the feedback. It’s also hard to comment without seeing the design.

      With the disclaimer out the way, I would be concerned to do this because:

      1. Representing a short page, only to reveal more fields toward the end feels like it’s a dishonest UI.

      2. Six questions on each screen sound like a lot to me.

      3. The fact that the page ends up weighty and long, means users lose many benefits described in the article.

      With regards to reviewing information all on one page. Did you see the “review” page I mentioned in the article (Point 9)? This allows users to review and amend.

      But also, we’re not limited to this. For Kidly, we actually built up an order summary that we displayed on every page of the checkout, to keep users informed throughout.

      • 30

        “Representing a short page, only to reveal more fields toward the end feels like it’s a dishonest UI.” Yes – but this is equally an effect of splitting into multiple pages. As a user, I find it infuriating to land at the beginning of a series of steps without knowing how many are coming or what information I’m going to be asked for.

        I may not have all of that information to hand. Maybe you’ll ask me for non-essential personal data that I don’t want to give, so I have to abort. I may find your list of payment methods doesn’t include one that suits me. But I can’t find out until I’ve wasted time completing the first few forms – and then when I do end up baling, you send me an unsolicited email asking me to return! (I’m not at all sure this should be considered lawful in the EU without granular up-front opt-in consent.)

        To me this is is the worst kind of UX, because it trains users to be bad users. We shouldn’t want to tolerate this. I’m coming to your site from a web that moves at fraction-of-a-second pace. Suddenly you want me to take several minutes to enter information. But you take it for granted that I’ll commit to this without the basic courtesy of letting me skip through the process first and see what I’m getting myself into. This can’t be a good pattern.

        tl;dr: I know it complicates the process and the visuals, but don’t offer a series of screens to step through without an interactive breadcrumb that’s fully exposed up front and throughout.

      • 31

        Hello Adam,

        Thank you very much for your reply and for your time.

        Here’s an example of what I’ve been doing for a while now:

        I think you’re right. It’s kindda “dishonest” to keep adding more and more questions while the user is filling in required fields (even if in my case, people who comes on this website are eager to fill in the maximum of informations because the more they add, the more we can protect them).

        You’re a bit more straightfoward by clearly adding steps to your form. However, even if I see there are 5 steps, I have no idea how long it’s gonna be to do those 5 steps.

        I think a good solution might be to display a progress bar like the one you have on some website for reading time, but here it would display the % done, the number of remaining fields, an estimate of the remaining time to complete the form (based on the number of remaining required fields, I guess), and also a graphic representation of what remains to be done (all those informations should easily fit in a small progress bar).

        What do you think?

    • 32

      Here are my thoughts Adam,
      When I see a page that hides and shows pieces of information when fields are field out (not components like accordians), my testing has often shown users reacting a but surprised because they don’t know why things are appearing and disappearing. This can chip away at a user’s confidence and sense of control over the app and make them feel unsure about their actions. If they click something else, will more fields disappear? Will they lose their work?

      Also, as we complete something, we see typically see ourselves get closer to the finish line. Instead, it sounds like your users get to a perceived finish line by finishing section 2 and then you move the line by displaying the 3rd section. Imagine this IRL if your GPS only showed 1/3 of the journey and didn’t show you the next 3rd until it said “you’ve arrived.”

      • 33

        “when fields are field out” should be “when fields are filled out.”

  11. 34

    Isn’t this pattern called a Wizard?

    Why try to give it a new name?

    IBM wrote about this core concept over 15 years ago. Not acknowledging previous research done on this feels self promotional.

    • 35

      I don’t see how failing to acknowledge a previous form of this pattern is in itself self-promotion.

      The author clearly attributed the term he uses (“One Thing Per Page”) to someone else:

      “A couple of years later (2016), Robin Whittleton of GDS told me that putting each thing on a page of its own was a design pattern in its own right, known as ‘One Thing Per Page’.”

      • 36

        Robin Whittleton

        May 25, 2017 9:59 am

        I didn’t discover this pattern – that falls to the excellent interaction design team at GDS alongside example projects that we’re doing real user testing.

        • 37

          Ah, I see. Thanks for clarifying, Robin. In that case, credit to the design team at GDS! :)

    • 38

      Robert Dundon

      May 30, 2017 5:00 pm

      I disagree that it’s self-promotional, but it’s good to remember that some of the core principles are the same: it’s helpful to split a long process into multiple, bite-size chunks.

      The more things are different, the more they can be the same :)

  12. 39

    Thank you for the article Adam. It offers great insight. I work at one of the largest webshops in the Netherlands. We have thorough discussions about having a one page checkout or a flow of multiple one-thing-per-page pages (steps). With the flow of multiple steps, the overview page can still become quit cluttered and visually look like a one page checkout. Do you have an idea on how to deal with this?

    • 40

      Adam SIlver

      May 23, 2017 3:34 pm

      If you see point 9, you’ll see Kidly’s design for the “overview” page which might help you.

      Does yours have a lot more information on it?

  13. 41

    Wow, what a poor article. It’s getting a point where Smashing Magazine produces great articles and then every so often a poor one sneaks through.

    I’m not even sure what the point of this one was.

    • 42

      Vitaly Friedman

      May 23, 2017 12:40 pm

      Dear Marc,

      Thank you for your comment! I’m very sad to hear that you found the article very poor. In the community, we always keep running into conversations of what’s better: multi-page checkout or single-page-checkout. The point of the article is to highlight that breaking down complexity into smaller steps is usually better than displaying all items at once — however, it does depend on how the form is styled, of course.

      Christian Holst from Baymard Institute recommends to display only 5–7 input fields per step, and keep the transition between steps seamless. Obviously, that’s not a new pattern, and one could see this article as a reminder. Still, I’ve got your point — let me see what we can do to make the articles more interesting/provoking in the future.

      Thank you so much for your feedback!

      • 43

        Vitaly Friedman,

        Thank you for replying to my original comment in such a professional and nice manner. I’m quite surprised at how reserved you were.

        When I first made the comment I didn’t mean to write it so short and in such a crass way. After submitting it I tried to edit it again but couldn’t figure out how to do it (I’m presuming you can’t edit your comments after submitting them).

        I’ll try to clarify in more detail what I meant.

        I did understand the point of the article and what was trying to be achieved, but I felt it was poorly constructed.

        Right from the title mentioning “thing” to the “extra 2 million orders a year”, then to the 16 generic points, the whole article didn’t flow like your normal articles.

        If it was a case study then where is the study of the case? Those 16 generic points seem to be added after the fact, they seem to be part of the article to maybe fill it up, instead of going indepth to what it really means to fine tune a checkout form.

        There’s many other ux sites which provide a plethora of examples and show in more detail the differences made when modifications are performed on a site.

        Even the pictures barely show the differences from the original to the new. I don’t believe then that it’s a case study at all.

        It’s more of an amazing event happened which was orders increased significantly, the checkout was changed for the better at that time, then 16 reasons why it’s better was made up. I’m not saying the 16 points are wrong, but they don’t directly relate to the case study but are more a generalisation.

        You could actually split the article into two, do a proper case study about the 2 million increase in orders. And then do a second article about simplicity, as in the famous don’t make me think.

        • 44

          ^ Up-vote from me for giving a more in-depth critique of the article. :)

    • 45

      Really? Others here seem to get the point just fine.

  14. 46

    Wallison Santos

    May 23, 2017 1:47 pm

    I learned a lot with this post. The self promotion is not that evil.

  15. 47

    This is a great refresher on form simplicity and how we’re too often overloaded with mutlitasking–stay focused!

    I have a question. The background is that I am creating a potentially very long form that potentially involves a lot of branching. This will be a great approach. However, what about progress bars? If we don’t know how the user will answer one question, how do we predict for them the next step?

  16. 49

    I think it’s a bit presumptuous to say that changing Just Eat’s checkout to multi-step led to the 2 million increase. There are many factors at play.

    Baynard Institute has been researching checkout design for years and has seen no increase to conversion purely because of design, either for single page, accordion or multi-step checkout.

  17. 50

    So… like a wizard? Or am I missing something?

  18. 51

    Hi, Thanks for sharing these information. Reading this article gave me many things to think about. Apart from these if any one want to read more blogs on these topic I suggest

  19. 52

    17. It enables easier A/B Testing

    For example, you want to show different panel(s) to a small percentage of users. Who knows, perhaps it’s something as minor as a color change and/or the change of some text. The point is, by having responsibilities divided into small pieces those pieces are easier to revisit.

    At #17 this feel low. It’s likely a Top 10, or perhaps for e-comm and other important transactions a Top 5 or Top 3.

  20. 53

    Nice article and overall I quite agree with the opinions expressed in it.
    I find it a bit ironic, though, that Amazon recently moved in the opposite direction, from one thing per page to a single page (at least in the Italian version). I guess with them being probably the biggest online marketplace, they must feel really strongly about using a single page approach.

  21. 54

    Interesting article. One issue I see with this is that it renders browser auto-complete useless. I have no idea if many people use autocomplete on long forms but I would have thought that a lot do. With Chrome being the biggest browser and their autocomplete being substantially improved since the stats listed were recorded, I wonder if the same would apply today.

  22. 55

    “Smaller pages save user’s data” – not compared to a single, longer page containing the same fields. It’s actually quite a lot more data (since you’re incurring more HTTP packets, and repeatedly serving the same HTML for the page structure/header/footer, etc).

    • 56

      Whether or not you need to re-serve the page structure HTML is an implementation issue that could be overcome in several ways.

  23. 57

    This article has significant issues with its explanation of AJAX, and honestly every technical point is either wrong or misleading.

    I’ll ignore the dubious stats that have been pointed out above, and say this. The article is good from a UX perspective, and a design perspective. If you’re a designer, take away the solid points about the simplification of checkout from this.

    As for the technical stuff. AJAX will always be faster than a full page reload. 100% of the time. Why? Because you’re not re-downloading and re-rendering the HTML, CSS and JS. Redoing all this to redisplay static UI elements is hugely inefficient.

    You can make an entire multi-page UI that is powered by AJAX under the hood and meet all of the specifications from this article. There is literally no good reason not to do it unless you are stuck with technical debt from some ecommerce platform. Code is not something designers should need to worry about when they’re designing. Worry about the UX, developers will worry about making it fast.

  24. 61

    Elle Kelsheimer

    May 26, 2017 4:25 pm

    What about tool/ productivity interfaces like Photoshop which the user will utilize frequently (and thus gain mastery) in hopes of performing complicated work quickly? I would hate to go through several screens every time I wanted to get to my select tool.

    • 62

      That’s a different design question from what’s being discussed. And, yes, wizards don’t really work out there.

  25. 63

    Dan Craddock

    May 31, 2017 12:51 pm

    Thanks Adam, this is a solid analysis with some compelling arguments. I’ll counter some of your points with the following.

    – 9: Debatable. I’d like to see more user research.

    – 10: I suspect 20 small page loads adds up to about the same data as 5 long pages. Maybe more given validation :-)

    – 4 and 11 are only relevant if you don’t have a decent analytics set up. Granted, many websites don’t.

    – 12: Debatable. Constant clicking/moving may seem endless after a while. And more steps means either no room for a progress indicator or a progress indicator that never seems like you’re getting through it. The perception of time can affect form-filler burden and satisfaction.

    – 16: Debatable. Designers and users may lose context and flow that would otherwise be provided by neighbouring questions.

    Keep up the great work in your series on form design. Really enjoying it.


  26. 64

    Nowadays a good coder can knock up a SPA page with multiple parts that show in steps. So take the user through logical chunks within the SPA, different “views”. Much faster than the old method you are using (i presume) by loading different pages. That is now the way any high traffic site should work. Maybe your simple checkout did not have a high traffic requirement for ajax.

  27. 65

    Designing “one thing per page” works for iOS users (to a certain extent) because they are accustomed to linear processes. On the other hand, Android users should never be more than 2 screens away from the beginning of a process. This has to do with the back button. The concept of designing “above the fold” is dying. Users scroll for content. When it comes to inputing all those custom fields we have ample pre-exiting information that we populate from Apple/Android pay, Google/Facebook accounts and, of course, previously completing the process. (We even have their age through Facebook log-in.) The user is skimming through to confirm the fields more than they are filling them out. Putting emphasis on these custom fields by giving them their own screens creates many unnecessary taps and the “duh” feeling. A good example of a scrolling check-out and confirmation screen is Instacart’s Android app. Even the delivery status is added on the same screen – and you can still edit many fields until delivered. Most importantly the UI designer is responsible for using design principles like ample spacing, text hierarchy and accounting for the keyboard to orient the user in a scrolling experience.


↑ Back to top