Skip to main content

UX best practices


General Form Design & Structure

1. Multi-step forms out-perform single-step forms

  1. The first impression is less intimidating than a long form with lots of question fields.

2. Remove all non-essential fields.

Expedia lost $12 million per year by asking one additional question (company name) in their booking form. Marketo also found that a few non-essential fields were inflating their cost per lead by ~25%.

4. Top-left aligned labels are best for readability & completion

Google’s UX researchers found that aligning labels above fields on the left-hand side increased form completion time. This is because it requires fewer ‘visual fixations’, as illustrated in the diagram below.

5. Avoid placing questions side-by-side.

Eye-tracking studies have shown that simple one-column layouts are better than multi-column layouts with questions positioned side-by-side.

6. Give people a reason to use your form

In one simple example, BettingExpert received 31.54% more signups by changing their form title and call to action to emphasise why people should sign up.

7. Group related fields together into sections or steps


Questions & Field Types

8. Choose field types that reduce the number of clicks required to complete


9. Use smart defaults


10. Know when to use radio buttons, checkboxes, and dropdowns

Where possible, checkboxes and radio buttons should be used instead of dropdowns, as they less cognitive load to process. Typically, I use dropdowns when there are more than six options to choose from.

11. Radio buttons should be vertically-stacked

12. Do not slice fields when asking for phone numbers or date of birth.

13. Clearly explain why you’re asking for sensitive information

People are increasingly concerned over privacy and information security. If you must ask for sensitive information, make sure you explain why it is needed using support text below the field.

15. Use placeholders correctly

16. Always display a field label

17. Use predictive search for fields with lots of pre-defined options

18. If you must ask an optional question, make it clear that it’s optional

19. Selectable images are among the most engaging question type

20. Be careful when asking for phone numbers

People are increasingly less happy handing out their phone numbers. In fact, one study by Clicktale found that marking the phone number field as optional decreased the form abandonment rate from 39% to 4%.

21. Input fields should be sized accordingly

The size of a field should reflect how much text the user is expected to enter. Therefore, fields like zip code or house number should be shorter in width than fields like the address line.

Accessibility & Ease of Use

22. Avoid using Captchas.

23. Do not rely on colour to communicate

24. Ensure that your entire form can be navigated using the tab key

25. When asking a question that users may not understand, provide clear explanations to guide them to the correct answer.

26. Does your form work on all major browsers and devices?

27. Is your form easy to use in bright or low-light situations?

28. Ensure that nothing flashes more than twice per second

29. Enables browser auto-fill

30. Use milestone submissions

31. Optimise the speed of your forms

32. Avoid auto-advancing (automatically jumping to the next question)

33. Use visual cues and icons to make form fields more intuitive

Input Validation & error handling

34. Don’t make your validation too strict

Strict validation is a symptom of lazy programming. It’s bad for users, and your business will pay a price for it.
If there’s a lot of variation in how users answer a field (for example, responding to phone number with +12345678912, +44 12345678912, 012345678912), your programmers should use a rule that converts these to a consistent format on your end.

35. Do not ask people to confirm their email or password twice

36. If you must use validation, ensure that it’s inline (to the right of the field) and reports errors early on.

Trust & Social proof

37. Make your form design beautiful

It has been proven that people trust beautifully designed forms / websites more than forms that don’t look as impressive.

38. Address likely concerns near your form


39. Display strong social proof in close proximity to your form

Statements like ‘used by 100,000 people’ 

40. Be careful using security seals, unless you’re asking for payment

41. Display live chat or contact information within view of your form


Multi-step forms & progress indicators

42. When using multi-step forms, always display a progress bar

43. Be mindful of your transition speeds

44. Use clear signposting

A progress bar by itself is not enough. You should also display the the total number of steps and which step the user is currently on to remove any ambiguity. 

Buttons & Call to actions

45. Call to actions should finish the sentence ‘I want to…’


46. Make sure call to actions are highly contrasted

47. Call to actions should be the same width as fields


48. Avoid using ‘clear’ or ‘reset’ buttons

49. Sequence your questions logically

When asking for credit card details, for example, ask for information in the same order that it typically appears on the physical card (credit card number, expiry date, security code).

50. Do not place overly complicated legal messages near your buttons.

51. Do not trick users by auto-enrolling them into your mailing list.

52. Clearly explain what’s next upon clicking the submit button

53. Upon submit, disable the submit button from being pressed again

54. Make it clear what the user can expect to happen next

Mobile form optimisation

55. Use the mobile device’s native features (camera, geolocation, date picker) to simplify tasks

56. Question fields and buttons should be at least 48 pixels high.

The average adult finger pad size is about 10mm wide

57. All form labels & placeholder fonts should be above 16px

58. Use specific HTML input types to show the correct keypad


Source 















Comments

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @ElementCollection     private List<String> certifications = new ArrayList <String> ();     public Long getId() {         return id;     }     public void setId(Long id) {         this.id = id;     }     public List <String> getCertifications() {         return certifications;     }     public void setCertifications(List <String> certifications) {         this.certifications = certifications;     } .. }         Users u = new Users();         u.getCertifications().add("Sun Certified Java Programmer");         em.persist(u); Generated Tables    Users    Co

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @Column     private String firstname;     @Column     private String lastname;     @Column     private String username;     @Column     private String street;     @Column     private String city;     @Column     private String state;     @Column     private String zipc