Form filling on touch devices

23 Apr 2013 - 1:56pm
1 year ago
4 replies
4400 reads

I'm working on a project where a user will sign up for an account on a touch device. (This is a one time only flow). This process involves 5 fields. From what I've read/experienced over the last couple years, it's often good to limit screens to one field, so the user can focus on that, fill it out, and continue on (via a next button or whatever). 

One reason for this is that error recovery can be very tricky on these devices, and people can get confused on how to navigate fields. 

I presented my design for this with 5 steps, which met large opposition. They stated they have no problem filling out fields on their device all the time. They wanted it on 2 pages max, meaning one page has 3 fill in fields. 

I think for power users, or frequent users, this is not  a problem. But I know people have trouble with field fill in on touch devices - especially since the keyboard takes up a lot of room, making the room for fields tight. 

Looking for input on this. I might have been wrong to stretch it out to 5 pages, but I think 3 fields on a page is too much and will create problems when errors happen. Thoughts?


24 Apr 2013 - 1:31am
Ali Rahimi

There shouldn't be a problem for a user to have multiple fields on one screen. Of course there has to be some guidence like scrolling the screen to the next input, etc. If your registration process is error-prone though, you should try to make it easier for the user to get things right. But just stretching the inputs on to multiple screens isn't the answer, imo. 

Reframing the problems helps. Many other apps try to solve these kind of issues with introductory screens where the complex facts are broken down into digestable pieces using a story they tell. Maybe pakaging your registration process into such a "first launch" experience will help you solve the controversy, between you, your collegues and most imprtantly how the user percieves the app.

Some Links on that matter:

ios scrolling screen to input:

and even more:

Good luck and regars,


24 Apr 2013 - 5:21am

There isn't really a way to say exactly which is best without understanding the business goals and task (your goal is the sign up, but the user probably wants something a step or so beyond that ), the users, and their motivation. And, then the implementation itself can make an enormous difference to your answer - e.g. if the transitions between screens/pages is delightful (and works within the context), then it may provide positive results (people may not notice it or may really like it - depending on the goals (goal completion vs. enjoying the task)).

The overarching qusetion is whether or not the 5 fields themselves all need to be done at that stage in the task* - do you need all that information before they can proceed? Can they provide it later? Would it make sense to provide it later? how does that affect their engagement and commitment?  (* sign up is a sub-task, it's a means to an end)

What I'm getting at is the notion that one field 'sign up' is feasible, depending on your aim and the users' aims.  An example is to take only their email address, and then allow them to create a password later once they have created something that they would like to access again - and it's at this later stage that you confirm that the email address is typo free.  Your email newsletter person may complain, but if the user didn't proceed far enough to need a password and confirm their mail, then it's worth understanding why rather than sending circular emails.

This is just an example, and its suitability depends completely on what you're trying to acheive and what the users are trying to achieve.

Ultimately, user & design research is your best friend. Prototype it, see how users respond, tweak, rinse & repeat.

26 Apr 2013 - 10:16am

Certainly agree with the previous poster that you should be able to put all the fields on one page, if designed properly. There's plenty of intuitive sites that accomplish this today.

Just got done with the UXIM Seattle conference, where Luke Wroblewski ( gave a great talk on mobile inputs - I'll share some takeaways that may help, depending on your use case:

  • try showing the password, and provide a toggle to turn on/off hiding the password as they type. this way you can have just one password field (rather than password and password confirm) with assurance that they'll enter it correctly.
  • put your field labels on top of your fields. that way, when the mobile browser zooms in on the field, the label is still in the viewport
  • get creative with field masks and field parsing. for example, don't use a separate first and last name fields - make that one field for "name" and parse it into first and last after submit
  • can you move any fields to post-registration? for example, is there profile data that you can collect at a later date when it's actually needed?
  • any way that you can replace some text input fields with toggles, slides, switches? get creative if your use case allows.
these are just a few of the ideas I'd start to look at. Luke's site also has more reading if you're interested.

29 Apr 2013 - 9:37am

I am familiar with Luke W's blog. The sign up info is all required at that time, unfortunately. None of it can be delayed. Appreciate the input!

Syndicate content Get the feed