Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Designing
Usable Forms
by Rick Dzekman
Topics
1.Accessibility
2.Context
3.Design
Accessibility in web forms
"it doesn't look as good" is never an acceptable
excuse to avoid accessibility
1
“But the building's facade
doesn't look as good with a
wheelchair ramp”
- Some horrible person
Consider a real world analo...
Different types of accessibility needs
Accessibility isn’t just about screenreaders
■ I experience eye strain – I browse t...
If you want to make your UI so
user-friendly that anyone can use it
Then you need to make sure
everyone can use it
Simple guidelines
If you follow these guidelines accessibility is going to be a
lot easier. Your design should be:
■ Simpl...
Redundancy in design – Example #1
Bad Good
Only colour is used to distinguish a link from
regular text
Both colour and und...
Redundancy in design – Example #2
Bad Good
Important information is only highlighted using
an icon
A label is added to the...
Redundancy in design – Example #2
Bad Good
The two inputs don’t have form labels A fieldset is used to group the fields an...
Redundancy in design – Example #2
Bad Good
Only colour is used to convey an error Colour, text and an icon is used to conv...
Remember
"it doesn't look as good" is never an
acceptable excuse to avoid accessibility
Why redundancy?
When you add redundancy to both the design and the code
you minimise the risk of accessibility issues.
Thi...
Some specific accessibility issues
These next slides
describe specific
accessibility pitfalls and
how to avoid them
from t...
Get the basics right
■ Use a large enough font size
■ Make sure you have high contrast
■ Consider edge cases: e.g. disable...
Use semantic markup
■ <fieldset> to group inputs
■ <aside> for help text
■ If it goes somewhere use <a href=“link”> if it ...
Help text
If help text is necessary don’t hide it!
When you hide content you encounter accessibility issues:
■ Older users...
Why go through all
this trouble? You risk
making it harder to
less-abled users.
All so you can hide
content in the
design?
Help text
Is your form long enough to need a progress bar?
Most progress bars only use colour to communicate how
far along...
Handling errors
■ Make sure you use more than just colour to
communicate errors
■ Avoid using red for marking mandatory fi...
Don’t hide labels
■ Consider the example with the "from date" and "to date".
If you add a label just for screen readers bu...
Dynamic form changes
Consider this scenario where selecting "add another"
causes dynamic changes to the page:
■ Use `aria-...
Remember
"it doesn't look as good" is never an
acceptable excuse to avoid accessibility
Context of web forms
Context matters
2
Consider this…
Keeping in mind everything I've said about accessibility,
what do you think about this question?
Is it ever...
There are exceptions to rules
Does this need a label for the input field?
You might not consider it a form - but it is the...
Don't be absurd
Another hypothetical question
Do you think having a label underneath
the input could ever increase usabili...
Don't be so close minded
“For one group of participants, we placed the labels above
the input fields and, for a second gro...
“What Matters Most Is Whether a
Label Is Close Enough to Its Field
Choose Any Harmonious
Arrangement of Labels, Then Test
...
Context is important
■ What is the purpose of the form?
■ How long is it?
■ Who handles the responses?
■ What language is ...
Types of forms
■ Search form
■ Lead capture forms
■ Enquiry / contact us
■ Support requests
■ Registration form
■ Survey
■...
Common idioms don't apply in all cases
“Web users spend 80% of their time looking at information
above the page fold. Alth...
How long is the form?
At Deakin university, the online application form is over 100
questions most of which aren't seen by...
Who deals with the responses?
Remember - your system usually has more than one user.
The end user isn't the only one impac...
What language is it in?
English
Life insurance company employee
Spanish
Empleado de la compañía de seguros de vida
German
...
Multilingual Web
How would a long compound word in
German work as a label? How does the
design look with a short Chinese l...
What happens after the form is submitted?
■ Can the user edit their response?
■ Can they keep track of the progress?
■ Can...
Designing web forms
Concrete design tips
3
Overview
Like a lot of design form design has a subjective component.
There are two types of advice for designing forms:
(...
Wording of your form
■ Who is the user / how much do you expect them to know?
■ This helps with deciding how technical you...
Using placeholders
Key takeaway: Don’t use placeholders
■ "Eyetracking studies show that users’ eyes are drawn to
empty fi...
Should you use a dropdown?
The best guide to this question comes from Sarah Miller and
Caroline Jarrett in the article "Fo...
Careful use of icons
Icons by themselves on a form can be very risky. In order to
communicate an action that a user needs ...
White space
Appropriate use of white space to create visual heirarchy and
grouping is vital to form design
■ "Tip #1: Plac...
Minimise the number of questions being asked
Keep your form as short as possible (but no shorter!)
■ If a field is require...
Responsive forms
Here are a few small tips to keep in mind
■ Is the font size large enough?
■ For iOS - if you don't make ...
Mandatory* vs (Optional)
This is a largely subjective issue. The question is simple, do you
mark mandatory items (e.g. wit...
“
Where to put the asterisk?
“I was once charged with testing
that. Seriously. $10,000 of
manhours testing asterisk
placem...
There are some UX designers who
will claim that users are used to the
asterisk marking mandatory fields
and that optional ...
Label placement (part 1)
Different label placements serve different functions
■ Labels on the left hand side of inputs all...
Label placement (part 2)
Keeping the last section in mind it's important to consider
what studies have been done. The most...
Label placement (part 3)
Eye movement over labels
Left aligned labels require a zigzag reading pattern and
lead to longer ...
Sentence case vs title case
Use sentence case for labels, buttons and headings
According to ISO-9241 sentence case is more...
You don't need a long preamble
In my experience testing a form with a long preamble - users
skimmed or ignored them. This ...
Design aesthetics are not important
Colour, shape, position, placement, padding, margins, fonts,
etc. make little to no di...
Handling errors
■ Make the form forgiving - e.g. accept both 03 9999 9999
and 0399999999, fix server-side or with JavaScri...
Thanks!Any questions?
Find me on Twitter
@rickdzekman
Upcoming SlideShare
Loading in …5
×

Designing usable forms

2,146 views

Published on

When it comes to the usability of forms there is a lot of research and a lot of factors to consider. This presentation reviews a large body of research on various aspects of form usability and user experience.

It covers three broad categories: 1. Accessibility, 2. Context & 3. Design

Published in: Design

Designing usable forms

  1. 1. Designing Usable Forms by Rick Dzekman
  2. 2. Topics 1.Accessibility 2.Context 3.Design
  3. 3. Accessibility in web forms "it doesn't look as good" is never an acceptable excuse to avoid accessibility 1
  4. 4. “But the building's facade doesn't look as good with a wheelchair ramp” - Some horrible person Consider a real world analogy “We can't have a handrail in the stairwell, it would make it look ugly” - Another horrible person https://commons.wikimedia.org/wiki/File:SSF_Main _Library_wheelchair_ramp_1.JPG https://commons.wikimedia.org/wiki/File:Orange_st airwell._(2610265332).jpg
  5. 5. Different types of accessibility needs Accessibility isn’t just about screenreaders ■ I experience eye strain – I browse the web at 150% zoom ■ My dad is inexperienced with technology – he can sturggle working out what is clickable ■ My mum needs glasses to read the screen – small or low contrast text is very problematic ■ My cousin has RSI so using a mouse can be painful – he prefers keyboard navigation
  6. 6. If you want to make your UI so user-friendly that anyone can use it Then you need to make sure everyone can use it
  7. 7. Simple guidelines If you follow these guidelines accessibility is going to be a lot easier. Your design should be: ■ Simple ■ Structured ■ Consistent ■ Intuitive ■ Redundant By design redundancy I mean having more than one way to convey contextual information. These are obvious What is this?
  8. 8. Redundancy in design – Example #1 Bad Good Only colour is used to distinguish a link from regular text Both colour and underline is used to distinguish a link from regular text
  9. 9. Redundancy in design – Example #2 Bad Good Important information is only highlighted using an icon A label is added to the icon to show that this section is important
  10. 10. Redundancy in design – Example #2 Bad Good The two inputs don’t have form labels A fieldset is used to group the fields and each one is given a label
  11. 11. Redundancy in design – Example #2 Bad Good Only colour is used to convey an error Colour, text and an icon is used to convey an error
  12. 12. Remember "it doesn't look as good" is never an acceptable excuse to avoid accessibility
  13. 13. Why redundancy? When you add redundancy to both the design and the code you minimise the risk of accessibility issues. This is because a lot of accessibility problems are caused by assumptions, e.g. assuming that the user: ■ Can see ■ Can tell the difference between red and green ■ Understands internet conventions ■ Is able to concentration / focus
  14. 14. Some specific accessibility issues These next slides describe specific accessibility pitfalls and how to avoid them from the beginning
  15. 15. Get the basics right ■ Use a large enough font size ■ Make sure you have high contrast ■ Consider edge cases: e.g. disabled buttons ■ Have a strong visual hierarchy ■ Do your headings follow both a semantic (h1-h6) as well as size order? ■ How do fieldsets look in your hierarchy? ■ Use the for=“id” attribute to link labels to inputs ■ i.e. <label for="dob">Date of birth</label> ■ <input type="text" id="dob">
  16. 16. Use semantic markup ■ <fieldset> to group inputs ■ <aside> for help text ■ If it goes somewhere use <a href=“link”> if it does something use <button> ■ Never use <a href=“#”> ■ <dl> (definition list) for displaying key/value pairs ■ e.g. showing previously submitted responses: Name: John Smith ^ definition term <dt> ^ definition <dd>
  17. 17. Help text If help text is necessary don’t hide it! When you hide content you encounter accessibility issues: ■ Older users / users with cognitive difficulties may not be familiar with the convention and not know to hover ■ You need to write separate code to account for keyboard navigation users ■ What will you do about screen readers? ■ You have to be careful about users with different browser modes (e.g. high contrast) who may not see the icon at all Why hide this content behind a hover?
  18. 18. Why go through all this trouble? You risk making it harder to less-abled users. All so you can hide content in the design?
  19. 19. Help text Is your form long enough to need a progress bar? Most progress bars only use colour to communicate how far along you are. This makes the assumption that your user can actually see the colour! Use redundancy: ■ Use an ordered list ■ Add a (current step) indicator ■ Advise the user how far along they are with text ■ E.g. (step 1 of 3) or (Progress: 50%)
  20. 20. Handling errors ■ Make sure you use more than just colour to communicate errors ■ Avoid using red for marking mandatory fields to avoid confusion ■ If errors are dynamic (either as the user types or after they submit the form) how will you communicate these dynamic changes to a screen reader?
  21. 21. Don’t hide labels ■ Consider the example with the "from date" and "to date". If you add a label just for screen readers but it's not visible you are not only adding extra development work but also pointlessly hiding content from the user. ■ On top of that you are thinking of accessibility as only about screen readers. ■ If the content needs a label for some users then it should probably be shown to all users.
  22. 22. Dynamic form changes Consider this scenario where selecting "add another" causes dynamic changes to the page: ■ Use `aria-live=assertive` to notify screen readers of a change to the DOM ■ Change the `focus` to the first input in the newly created element ■ Use useful anchor text on the button, e.g. "Add another task" vs simply using "Add another"
  23. 23. Remember "it doesn't look as good" is never an acceptable excuse to avoid accessibility
  24. 24. Context of web forms Context matters 2
  25. 25. Consider this… Keeping in mind everything I've said about accessibility, what do you think about this question? Is it ever OK to hide a label from a sighted user?
  26. 26. There are exceptions to rules Does this need a label for the input field? You might not consider it a form - but it is the second simplest kind of form there is. (What's the simplest?)
  27. 27. Don't be absurd Another hypothetical question Do you think having a label underneath the input could ever increase usability?
  28. 28. Don't be so close minded “For one group of participants, we placed the labels above the input fields and, for a second group, we placed them below. When test participants were able to concentrate on their work, there weren’t any differences between the two groups—everybody filled out the form correctly. But when we interrupted them and asked them to fill out the form in a reduced amount of time, the group with the labels below made fewer mistakes than the others.” "Label Placement in Austrian Forms, with Some Lessons for English Forms" (Roland Feichtinger) http://www.uxmatters.com/mt/archives/2010/10/label-placement-in-austrian-forms- with-some-lessons-for-english-forms.php Aside: can you think of a scenario for right-hand labels?
  29. 29. “What Matters Most Is Whether a Label Is Close Enough to Its Field Choose Any Harmonious Arrangement of Labels, Then Test - Label Placement in Austrian Forms, with Some Lessons for English Forms
  30. 30. Context is important ■ What is the purpose of the form? ■ How long is it? ■ Who handles the responses? ■ What language is the form in? ■ What can a user do once the form is submitted?
  31. 31. Types of forms ■ Search form ■ Lead capture forms ■ Enquiry / contact us ■ Support requests ■ Registration form ■ Survey ■ Application form ■ … And many others What is the purpose of the form? Each one will vary ■ How long it's likely to be ■ How the user gets there ■ How informed the user is ■ How engaged the user is
  32. 32. Common idioms don't apply in all cases “Web users spend 80% of their time looking at information above the page fold. Although users do scroll, they allocate only 20% of their attention below the fold.” “Scrolling and attention” Jakob Nielsen http://www.nngroup.com/articles/scrolling-and-attention/ Do you think that applies to a registration form? What about an application form? What about submitting a tax return? Some forms are only for engaged users, other forms are for users who have no choice (consider a form for staff on an intranet) Users do scroll – context is important!
  33. 33. How long is the form? At Deakin university, the online application form is over 100 questions most of which aren't seen by most users. Two randomly chosen applicants aren't likely to have seen the same questions. It is dynamic and context driven. ^ ATO eTax – sections > subsections > fieldsets < Salesforce.com “Free Trial” form
  34. 34. Who deals with the responses? Remember - your system usually has more than one user. The end user isn't the only one impacted by your design. There are administrators who have to maintain the form and staff who have to do something with the responses. Sometimes you can offload work to the user, making a form more difficult to fill out but easier to respond to. This might increase the time to respond for staff and as a result improve the ultimate user experience. Sometimes short-term costs to user experience can have long term benefits.
  35. 35. What language is it in? English Life insurance company employee Spanish Empleado de la compañía de seguros de vida German Lebensversicherungsgesellschaftsangestellter Chinese 寿险公司员工 Arabic: ‫موظف‬‫الحياة‬ ‫على‬ ‫التأمين‬ ‫شركة‬
  36. 36. Multilingual Web How would a long compound word in German work as a label? How does the design look with a short Chinese label? What about in Arabic where it needs to be right-aligned and read right-to-left?
  37. 37. What happens after the form is submitted? ■ Can the user edit their response? ■ Can they keep track of the progress? ■ Can they even see their responses after submission? ■ Can the user save progress and come back later? ■ What happens if the user changes their mind about submitting the form? ■ What happens if the user made a mistake while filling out the form? Some forms are more important than others. Forms can have legal, regulatory and even financial consequences. Usability does not trump everything
  38. 38. Designing web forms Concrete design tips 3
  39. 39. Overview Like a lot of design form design has a subjective component. There are two types of advice for designing forms: (1) Data driven, evidence based design considerations (2) Best practices Where I advocate a design decision I will identify if it's come from a particular study or piece of research. Otherwise the suggestions are considered best practice. As always be sceptical of “best practices” with no data. If you are in doubt about any design advice the best (or even only) way to decide for your context is to conduct an AB test.
  40. 40. Wording of your form ■ Who is the user / how much do you expect them to know? ■ This helps with deciding how technical your language can be ■ What is your relationship with the user? ■ If you have to ask personal questions it can be important to explain why you are asking this question ■ What kind of tone does your organisation have? ■ Often a conversational tone can be helpful in communicating with your user ■ How simple can you make your question while still retaining meaning? ■ Could you offload the complexity into help text? The best guide comes from Gerry Gaffney's article: "The art of writing very little: how to improve your forms“ http://www.formsthatwork.com/TheArtOfWritingVeryLittle
  41. 41. Using placeholders Key takeaway: Don’t use placeholders ■ "Eyetracking studies show that users’ eyes are drawn to empty fields" ■ "Disappearing placeholder text strains users’ short-term memory." ■ "It also poses additional burdens for users with visual and cognitive impairments.“ ■ "One last issue to consider is that placeholder text is generally bad for accessibility." "Placeholders in Form Fields Are Harmful“ http://www.nngroup.com/articles/form-design-placeholders/
  42. 42. Should you use a dropdown? The best guide to this question comes from Sarah Miller and Caroline Jarrett in the article "Four steps for choosing form elements on the Web” http://www.formsthatwork.com/files/Articles/dropdown.pdf Six questions to ask 1. Is it more natural for the user to type the answer rather than select it? 2. Are the answers easily mistyped? 3. Does the user need to review the options to understand the question? 4. How many options are there? 5. Is the user allowed to select more than one option? 6. Are the options visually distinctive?
  43. 43. Careful use of icons Icons by themselves on a form can be very risky. In order to communicate an action that a user needs to do it's best to use a combination of an icon and a label. "There are a few icons that enjoy mostly universal recognition from users. The icons for home, print, and the magnifying glass for search are such instances. Outside of these examples, most icons continue to be ambiguous to users due to their association with different meanings across various interfaces." “Icon usability“ http://www.nngroup.com/articles/icon-usability/
  44. 44. White space Appropriate use of white space to create visual heirarchy and grouping is vital to form design ■ "Tip #1: Place the label closer to the associated text field than to other text fields“ ■ "Tip #2: Group together related fields" "Group Form Elements Effectively Using White Space” http://www.nngroup.com/articles/form-design-white-space/ "Users overlook features if the GUI elements are too far away from the objects they act on" http://www.nngroup.com/articles/closeness-of-actions-and- objects-gui/
  45. 45. Minimise the number of questions being asked Keep your form as short as possible (but no shorter!) ■ If a field is required ask "why is this field required? Do we actually need it? ■ If a field is optional ask "if users don't have to fill it in, why are we asking them?“ The more questions we ask the user the more cognitive strain we put on them. This increases the chance of abandonment or the user making a mistake. Aim to reduce the number of questions you ask to the bare minimum. Rather than optional, consider making some questions conditional. So that the user is asked only if their other answers indicate that we need this information.
  46. 46. Responsive forms Here are a few small tips to keep in mind ■ Is the font size large enough? ■ For iOS - if you don't make the input font size 16px Safari will zoom in on the field when focused ■ Is the right keyboard coming up? (numeric, email, plain) ■ Have you turned off autocorrect / autocomplete for fields where it's a distraction? ■ Consider using a toggle instead of a checkbox (note, for desktop this can cause confusion!)
  47. 47. Mandatory* vs (Optional) This is a largely subjective issue. The question is simple, do you mark mandatory items (e.g. with an asterisk) or do you mark optional items (e.g. with "(optional)"). ■ If every or almost every input is mandatory then it makes more sense to mark optional fields ■ If there are many optional questions it's better to mark mandatory fields ■ Sometimes an (optional) indicator can make things ambiguous (consider checkboxes / document uploads) ■ If there are many forms on the web site or app then you should have a global rule, where individual forms may not follow best practice
  48. 48. “ Where to put the asterisk? “I was once charged with testing that. Seriously. $10,000 of manhours testing asterisk placement. There was no difference in user performance. At all.“ - Miriam Frost Jungwirth
  49. 49. There are some UX designers who will claim that users are used to the asterisk marking mandatory fields and that optional confuses users. However, I have never seen an actual study proving this claim. In all usability tests I've done users have never had problems with "optional"
  50. 50. Label placement (part 1) Different label placements serve different functions ■ Labels on the left hand side of inputs allows for quick scanning of the form. This is particularly useful if users need to edit or review their input and can be useful if they don't need to fill everything out. ■ Labels directly above the form input make it much simpler to fill out fields one at a time ■ No labels and using placeholders instead reduces screen space but at the cost of accessibility and bringing its own usability problems
  51. 51. Label placement (part 2) Keeping the last section in mind it's important to consider what studies have been done. The most famous eye tracking study has shown that labels above form inputs are considered the best: "Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field." "Label placement in forms“ http://www.uxmatters.com/mt/archives/2006/07/label- placement-in-forms.php
  52. 52. Label placement (part 3) Eye movement over labels Left aligned labels require a zigzag reading pattern and lead to longer saccades Labels above either have low saccades or require only a single eyeball fixation to read the label and focus on the input
  53. 53. Sentence case vs title case Use sentence case for labels, buttons and headings According to ISO-9241 sentence case is more readable than title case and should be used instead. If you're unfamiliar with this standard, read: "What on earth is ISO-9241” http://www.uxbooth.com/articles/what-on-earth-is-iso-9241/ NB. never use all caps for anything you actually expect users to read. All caps is proven to be the most difficult type of text for people to process.
  54. 54. You don't need a long preamble In my experience testing a form with a long preamble - users skimmed or ignored them. This was true even of older less tech savvy users. In my personal experience I only read preambles if I have trouble with the form. So if there was something important in there I would miss it. This has also been experienced by others with AB testing: "Both tests, October and November, showed a significant difference [...] between the conversion rates for the variants with the original preamble and with the [shorter] preamble." "Making a better web form" - http://www.formsthatwork.com/files/Articles/BetterForm.pdf
  55. 55. Design aesthetics are not important Colour, shape, position, placement, padding, margins, fonts, etc. make little to no difference to the usability of a form. These aesthetic details should not be our focus. "tinkering with a design that is reasonably tidy and organized in the first place is unlikely to make a major difference to the success of a form.“ "No significant differences for ... 1. Adding a photo, 2. Adding coloured backgrounds to fields, 3. centring the form in the browser window, 4. adding a blue background to the window" "Making a better web form" - http://www.formsthatwork.com/files/Articles/BetterForm.pdf
  56. 56. Handling errors ■ Make the form forgiving - e.g. accept both 03 9999 9999 and 0399999999, fix server-side or with JavaScript ■ Provide the user on-screen help ■ Give the user a way to get help outside of the form (email, live chat or even a help desk phone number) ■ Provide useful errors ("this field is required" rather than just highlighting it red) ■ Consider providing live feedback. e.g. fields get ticked and turn green when they are completed correctly. But watch out for accessibility concerns!
  57. 57. Thanks!Any questions? Find me on Twitter @rickdzekman

×