cft

How bad forms hurt your business

Bad forms will hurt your conversion rates and make your staff slower.


user

Klaus Schaefers

3 years ago | 4 min read

When you talk to startup companies, you always hear how much importance they give to the user experience (UX) of their product. These companies have understood that a bad UX will seriously hurt their business. It will make the product undesirable and people will not use, will not pay for it and, consequently, they will not recommend it.

But what about all these applications that already existing the market? In particular all those back office applications that are used by millions of office workers every day? Quite some have a terrible user experience and make the daily work unnecessary complex and frustrating.

For example, recently, a friend of mine complained of how annoying it was for him to go to a business trip. It was not the trip itself, of course, but the legacy system to report the travel expenses, which made the process of entering the information a real pain. I asked for some details and a screenshot of the system and decided to do a small and fast experiment to see if I could come up with a better user interface.

The experiment:

For the experiment, I created a simple prototype of the legacy system interface and an improved version in Quant-UX. The task for the user was simply to fill out the travel report for an imaginary trip.

For every receipt, the users have to enter the date, the type of expense and the total value.

The legacy system followed pretty much the raw description of the use case and presented the user a row based layout. Every row presented a receipt. The user had to select the date with a date picker, select the Expense type from a dropdown box and enter the value.

When I discussed the design with my friend, he told me two important things: first the systems only supported 5 types of expenses: Flight, Meal, Hotel, Taxi and Other. However, as “Other” expense types always had to be justified, nobody really used it; second, he told me that 95% percent of the time the trips just took one day.

So I came up with a much simpler prototype. It follows the basic principles of form design and usability (namely progressive disclosure). The labels are top aligned, and we just have one column. This makes the form easy to scan for the human eye. More importantly, I tried to reduce the complexity.

First, I got rid of all drop down boxes for the expense types. Instead there is for the most important expense type a designated input field.

Second, I hid the “Other” expense type, as it will be most of the times not used.

Third, I provided only one date field because most of the travels take only one day.

Fourth, I added an “Add …” button which allows the users to add more field or add more days.

Once I created my prototypes, I ran an A / B Test to compare both designs. I sent a link to the prototypes to my network, and kindly asked people to fill in the form. This means the tests were unsupervised, and people could not ask for help. The A / B testing was done by Quant-UX.

The tool randomly selected one of the prototypes for testing when the users visited the link. The testers were between 20 and 50 years old and can be considered digital natives. Before the users could fill out the form, a short introduction was shown to them. Also to ensure that the users would not enter arbitrary data, a small “cheat sheet” was shown next to the form. The legacy prototype was tested 31 times and the new design 37 times.

Results:

The test results confirmed my initial feeling that there was much room for improvement. Looking at the data (Legacy / New) two things really struck me. First, I was really surprised to see that a lot of the testers had problems understanding what to do in the legacy system.

Only 22 of the 31 (70%) tests were successful, while 33 of 37 (89%) users managed to complete the task in the new design. This means that novice users of the legacy system will most likely need some kind of education or training to understand how the system operates. Just passing a login and a link to the tool will in most cases not be enough for them.

Second, there is a significant difference in the execution times. While the users of the new prototype were able to enter all data in less than a minute (59sec in average), the users in the legacy system took in average 93 secs. This speed-up is not really surprising, as the number of necessary interactions was reduced by half, however it reveals how much time is wasted due to bad design.

Conclusions:

This test revealed that the simulated legacy system has some serious usability issues and that a better design would make the system easier to learn and its users more productive.

The legacy system forced the user to introduce the same information and date several times. Also it is unnecessary complex to select the expense types. If there would have been a lot of options to choose from, the dropdown boxes could make sense, but in this scenario the dropboxes just forced the user to do a lot of clicking.

Finally, the large number of input fields seems to be confusing and makes it harder for the users to understand the form. All these issues contribute to a bad user experience that is luckily easy to fix. Some simple improvements in the UI can increase the learnability, and more importantly boost the user’s productivity by 33% without touching any backend code or changing the business processes.

Quant-UX is an OpenSource prototyping and research tool. It is free to use at https://quant-ux.com

Upvote


user
Created by

Klaus Schaefers


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles