3 Essential Points from Luke W’s “Web Form Design”


My time to read industry books is so limited that I have to really be frank about what I’m able to absorb, and the reality is: not much. ¬†It takes a bit more focus to power through something that doesn’t exactly have a narrative, like a fiction novel. It can also be a bit of a challenge to guess what parts of a book will eventually become important later on in my work, or if I won’t know if I necessarily agree with something until I try it in my own work or even test it out. So these days, I rely a lot on taking succinct, clear, notes that directly relate to projects I’m attached to.

I’m currently working on an application that has a lot of data points for end-users, which means lots of web forms, and editing web forms. Much of Luke W’s insight is pretty obvious and stuff you would probably know if you’ve used an e-commerce site or filled out a survey (in print, online, whatever) before. But I really liked these points:


It’s really nice for the user to enter whatever data however they want, as long as it’s valid. For example, look at all the ways we can enter a phone number:


There are other ways, obviously (just think of all the factorial fun involved with the parenthesis), but they’re all valid. A way to allow the user to enter their preferred method is to provide a single form field and to do the back-end work to accept all those variations. The work is on us. It’s not to say breaking up the telephone number entry form into three segments is wrong, but it might be a nice way of providing some agency for the user.¬†Flexibility comes out in other ways, too, like how much information a user might want to enter with a form and advanced features for super users.

Label/Form field alignment

I’ve ordered these in terms of saccade time (eye movement), fastest to slowest, and when I’d personally use it. I don’t include inline form fields because there’s so much written about that online, and I personally hate it unless it’s as simple as this. You can read Luke W’s take on it on his site but studies have shown that they don’t necessarily work well. I’ve also highlighted in the drawings I’ve uploaded where the eye would begin scanning the labels – I think it’s helpful to think of that to understand why certain form fields take longer to fill out (not always a bad thing).


Top aligned. I’d use this when a user is going to fill out a form once, it’s fairly long, and they need to power through it quickly.

right aligned

Right aligned. Use when vertical space needs to be limited to a certain size – otherwise, and you still need the user to fill things out fairly quickly. I’m thinking this is more applicable to e-commerce forms. It also creates a few problems in longer form field labels (we don’t read right aligned, in English anyway) so be careful!

left aligned

Left aligned. I’d use this when you know the form is going to be edited fairly often. It’s the form that requires the longest time to read initially, but it also allows the user to scan the left aligned text really well, so that’s a huge bonus for people who are going to be working with the same form multiple times, or who will go back to edit information.

Primary and Secondary Call to Actions

This is one of the few sections of the book that I think is worth reading carefully because of the number of studies Luke W has done with usability of primary and secondary CTAs. Surprisingly, people are really good at engaging with the CTA they want, even if it takes them a bit longer. The best way we can guide them is to provide differentiation – make the primary CTA one style (ie a button) and the secondary another (ie link, or another color). People also like to see all their choices in one location and the primary action the first thing they read (whether that’s the first CTA in a list of CTAs or the first CTA in a horizontal arrangement.)

And that’s it – the details I found most useful in helping me make decisions about label design. The other chapters concern themselves with issues that you can use your design sensibilities to reason through on your own – like where to place error text (and how they interact with the rest of the form fields) and best ways to display answer-dependent content.