|
Last week I revealed the first law of form design which is that: Nobody wants to use your form. Like I said this is crucial to know because it emphasises respecting the user over trying to make your form fun, engaging, novel or “on brand”. And showing respect means doing everything we possibly can to get that form out of the way as quickly as possible. One way to measure how well we’re doing that is by tracking completion time. Which leads us to the second law of form design: Completion Time = Question Time + Pause Time Understanding this equation shifts the way we tackle the problem of designing a form so that users can get through it as quickly and as easily as possible. So let’s break it down: Question Time is how long it takes you to answer all of the questions. This includes the time to read the label, understand the question and provide an answer – the bit that includes things like:
Sticking with the same theme from last week, here’s the form to create a JIRA ticket: There are a lot of issues here, one of which is the number of optional fields. Most of the time you just want to capture something quickly to be refined at some point later. But the optional fields make this process tedious because it raises questions in the user’s mind: “What is this for? Is it okay to leave it blank?” This takes time! There are a few different ways to deal with optional fields but the current design is likely to result in lost tickets and less time doing actual work. This is not what you want. Let’s move onto Pause Time: Pause Time is how long it takes you to:
For example, when you create a JIRA ticket, you might want to know:
Not knowing this causes hesitation, raises concern and slows you down. Slow forms = bad UX The most sensible move would be to ditch JIRA for something better. But here’s a different scenario: Let’s say you’re about to buy something online, you probably want to know:
Not knowing this causes you to hesitate and slow down. This causes abandonment. Alternatively, if you know how long it’ll take to arrive and how long you have to return it, you are more likely to finish the job. Now it’s all very well and good knowing the law but there are many details that go into making sure that completion time is kept to an absolute minimum. If you’d like to know what all those details are, I’ve just released a brand new version of Form Design Mastery. Hand on heart, I think it’s the best design course out there; because it’s packed with design patterns that have been proven to work across multiple different products and services. But don’t just take my word for it, here’s what some members have said after finishing the course: “This helped improve our flow and enhance conversion. Totally worth the cost!” – Simon Vandereecken, Product designer at Checkout.com “Since employing some simple changes around field labels and removing unnecessary steps, we’ve seen an increase in qualified form completions.” – Ryan Weisser, Senior product designer at Gartner “Following Adam’s advice, we’ve seen abandonment rate and exit rate decrease, whilst conversion rate has increased”
– Paul Braddock, Lead designer at Co-op Group
Just to note that these are testimonials from people who invested in the original Form Design Mastery. 2.0 blows it out of the water. If you invest in the course over the next few days, you’ll also get 9 bonuses, including a live call where you can ask me questions and get feedback on your designs. Here’s everything you need to know: See you soon, p.s. If you have any questions, let me know. |
Join 9000+ designers, content designers and engineers who get my free weekly newsletter with evidence-based design tips (in 3 minutes or less). Mostly forms UX, but not always.
A year ago I posted this on LinkedIn: === I tell my students to avoid select boxes. Because it’s often better to use radio buttons. But students often say “But it’ll make the page too long”. Yep, but that doesn’t necessarily mean it’s bad UX. See the page I designed to let users select a course. Huge list of radio buttons. But no issues in user research whatsoever. Does this mean you should always use radio buttons? No. But most designers would balk at a design like this even though it worked...
Last week, I had a meeting with two devs and two designers. The meeting’s purpose was to let developers raise problems and get quick design decisions. One of the devs brought up an issue with a form that had conditional radio buttons. Here’s what the screen looked like (it’s a bit different to what I’m actually working on but close enough): When the user selects “Yes” it reveals a field to enter the name: If you leave it blank and submit the form, the page refreshes and shows an error: So far...
Quick one: Yesterday I sent you an email “My response to Hacker news comments”. I received a few responses asking for clarification in my second illustration – because I screwed it up. Here’s what it should have been: Enjoy,Adam