I'm designing forms in a PPC / landing page style format where the user has arrived from an ad on a search engine page - this user is very likely to be interested in the product that I'm offering.

The landing page form in question is of multiple pages.

I understand that in general, it is worthwhile to have your 'call to action' above the fold for obvious reasons. My question is: Is there any benefit of having the 'next' button (that takes you to page two of the form) above the fold?

A quick analysis on my part resulted in the following:

  • The next button above the fold ensures that the user doesn't feel overwhelmed with too many inputs to enter at once, with a clear representation of how much work they have to do to get a result - as soon as the page is loaded.

  • If the next button was below the fold, there would be no obvious 'click magnets' in the initial view and I risk losing focus to other elements in the design (ex. outbound links in the header or navigation)

  • The next button above the fold severely limits the amount of content I can have in the form area, because my client's primary customers tend to own computers with a minimum resolution of 1024x768. (This causes another unrelated headache where I end up having too much whitespace on bigger resolutions - thank goodness for CSS media queries!)

Am I missing anything? Are there any studies done on this topic that shows any significant benefit for or against? Am I wasting my time debating about something seemingly so trivial? :)

EDIT: I should have made it clear that the next button is in its traditional position in the form, at the bottom right. In this scenario, keeping the button over the fold forces me to limit the content in the form as opposed to moving the button around.


4 Answers 4


I am actually going to attempt, after this intro., to avoid the concept of the fold entirely as it's an interesting debate - especially with mobile screen sizes being so short, laptops being short, and, generally, not being able to guarantee/know where the fold is. (This happens a lot at my current job. The designers and I all use 27" iMacs - then the designers kind of freak out when they are told by the clients that elements the client would like to be above the fold aren't when looked at on their 13" company provided laptop.) So, taking a different tack - you want the submit button to always be visible in the viewport.

One approach is the one Apple uses when you go to make a purchase. Put the long form on the left/right - and the submit, progress tracking, etc. on the right/left (respectively) in a box small enough for even an e-book at 5 inches tall - position fixed: http://store.apple.com/us/configure/MD387LL/A?

Another approach, which I can't remember the origin of at the moment (I believe it was a survey), is to lay the form out horizontally with the form broken up into small enough pieces that the bit of the form currently being filled out is pretty short and the next/previous/cancel/submit buttons with progress are on the right. For example, contact information form "page" consisting of name, address, address2, city, state, zip, phone, email in a left column - a dividing line - then the right column with 1 of N and a next button.

One thing I should mention is that you may want to test this as I have found having multiple page forms, unless a multiple question survey, results in more bails than a single long form with scrolling - your results may be different, however.

  • 1
    +1. Interesting strategies. Regarding multi vs single page: currently the important bit (email) is filled up on the first page which gets fired away to the server via AJAX as soon as its filled. (let's not go over the moral implications - what the client wants, the client gets). I do like your second solution. Thanks for the answer! Mar 21, 2013 at 5:14

If a user has the intention of filling out your form I don't really see an advantage of placing the buttons "above the fold".

More importantly you cannot really ensure anything being "above the fold" without some complex javascript and dynamic forms.

I think it is best to (if you need / want a multipage form) to separate the fields into meaningful groups which can make up the different steps.


I think a next, submit or similar button should be at the bottom of the form. We read left to right, top to bottom. The worst experience is scrolling up to go forward (one step back to go forward). Assuming your clients know how to scroll even half a page, put it near the end of the page / form where they will be at when it is time to move forward anyway.

  • 1
    Sorry, I should have made it clear that the next button is in its traditional position in the form, at the bottom right. In this scenario, keeping the button over the fold forces me to limit the content in the form as opposed to moving the button around. Thanks for your answer! Mar 21, 2013 at 4:08
  • In that case, I will add I think "above the fold" is generally not worth much. Keep the as simple as possible, limit the number of questions as much as possible, but limiting content simply to fit it into 1024 x 768 would not be a goal I would worry about. Especially when you consider the visually impaired who will have the most trouble period (0n average) and will have changed their resolution and DPI. Mar 21, 2013 at 4:14
  • 2
    @psychobunny 'limiting the content in the form' is probably a good idea, even though the fold is somewhat irrelevant. The goal should always be to ask the absolute minimum required in a form.
    – DA01
    Mar 21, 2013 at 4:28

You could also make the submit button listen to a key down event on the Enter key.

This supports some exotic scenario in which users don’t see the button but do want to send the form without scrolling.

Calling this scenario exotic, I don’t think it is an issue to have a submit button below some fold. Make sure the form is recognisable as a form and the users will expect the button to be there.

More on this: Behavior of the Enter button in a form

  • In general, listening to key events on the Web is a bad idea. Anyway, if the user does not see the button, there are not many chances that the button would be focused, so your listening machinery would not be triggered. Mar 23, 2013 at 15:19
  • But making the submit button the default button of the form would make pressing Return or Enter trigger this button when the key press is done in a single-line text input field. Contrary to JavaScript, this is clean, and can be done in pure HTML. This is typically done for the Search button in search forms. Mar 23, 2013 at 15:23

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.