"It looks far too complex"was the phrase that introduced my previous post about browser based forms and the perception of application that include them. The phrase illustrates a common issue that faces many software developers, sales engineers and anyone that demonstrates software that includes a browser-based form for capturing data and attributes. Software applications that need users to enter structured data are typically poorly received.
In that previous post I suggested some opinions as to why users hate forms and more broadly any applications that attempt to impose structure. In this post I'm going to offer some opinions that represent my non-expert status in "user experience" design, to help encourage less of the original response that "it looks far too complex", and more of the "when can we start using it!".
How to fix the problem
I am not a "user experience" consultant of great repute, so my thoughts are just observations - that I'm going to write down anyway. The following lucky seven short sections describe how we might approach making data entry less odious to the user.
1) Try the MS Office 2007 approachMS Office 2007 introduces a new approach to capturing document attributes or properties , along with other usability enhancements. The experts at MS have also noticed that users hate entering data, so they have provided a new novel approach to the problem. These are some suggestions that I have drawn from observing the new application (Office 2007 beta 2)
- Constantly display the document or case attributes in an information panel, so it becomes less of a big surprise and threat
- Allow the user to enter the information at any time that suits them, without having to artificially navigate through a new dialog or form
- Only bully the user for entry of information when they have failed to enter it in the information panel, as late as possible
2) Avoid the traditional forms display
Many forms on websites and enterprise applications alike are long and linear, since this easiest to design and implement. Even LinkedIn, a popular application designed to encourage you to register confronts new users in this way (although their form is at least segmented). This is because vVertically oriented forms may appear more lengthy than necessary. Also, when a form is positioned in a vertical panel to the left of a document it appears more urgent, as western users read left to right.
Here are some thoughts to improve this with a different orientation:
- MS Office 2003 used vertical panels on the right, maybe for this reason
- MS Office 2007 uses a horizontally oriented document information panel at the top of a document. It seems to be accepted by the eye as a more integral part of the application task ribbon (the new Office approach to toolbars) than other approaches, and does not carry the issue of appearing unnecessarily lengthy
Capturing information across several screens, at relevant points in the process breaks up the appearance of a lengthy form and the monotony of entering all that data. The amount of information required at any one time is less overwhelming to the user. A key design point is that it helps the designer ensure that only relevant information entry is presented to particular a user.
4) Don't make it look like a tax return
Use a very clean, modern, friendly forms design. Investing in the best look possible will help it appeal to the user visually and will avoid clutter, making the usage more streamlined, which is essential if users are expected to return to the form in the future.
5) Know your user
Presenting the form in a presentation format most appropriate to the user profile is essential, and one item that I believe is regularly overlooked by applications. Here are some key thoughts around this:
- Know the size of the screen, and use it in a way appropriate to the application. Blog applications like Blogger are often terrible at this, presenting an editor that is too small to reasonably write and review lengthy posts.
- If the user doesn't need accessibility features, or keyboard shortcuts for productivity, avoid showing them them this information. It just leads to clutter and confusion.
- Where possible pick up the user profile automatically, so that accessibility features can be display only if needed.
6) Trick the user
Fool the user into believing that they are not entering information into a form, so that they are not threatened by it. This may also help the designer find more effective ways of collecting the information required. Try:
- Presenting the form as a series of friendly questions can be less threatening, and can hide unnecessary attributes that are not required
- If information entry is not enforced, experienced users will not enter it even if you show them textboxes for it
- Allow users to enter information over the course of their usage, not in a single enforced form or lengthy wizard
7) Share the burden
This is my favorite. The assumption in applicaitons that collect and share information, in either a collaborative or process driven tool, is that all data must be collected up front. Data entry is often performed right outside the mailroom in enterprise BPM processes. In more field based processes, the person initiating a request or document may be unfairly penalized with all of the data entry to identify the item. I would try and bear these points in mind:
- Don't make the case initiator (e.g. the salesman that creates the request for a new contract) enter all of the information. That salesman has a job to do, and its selling your stuff, not filling in forms.
- If the user can not see the advantage to them of entering the data, they are unlikely to take the care to fill it in correctly.
At the end of the day
For any application utilizing data entry by typical users, some novel ideas may be required. Otherwise a typical user can often become defensive at the sight of a single data entry form, runing the impression of an otherwise incredibly usable application. Despite this issue the application requires attributes to be entered for it to work correctly or deliver its full value. A balance needs to be struck.
As with any software application, get the buy in of some positive business champions early on in the design. They can help to guide your requirements, and diffuse negative feedback out on the shop floor.
When deploying a generally accessible web application, or an internal enterprise application, training and championing is impossible on a large scale. In these scenraios you need to work harder on the design to make it really appealing to a mass audience using the application with minimal guidance, training or change management.
Take as many tips as you can from the best online web businesses and apply some of the lucky seven ideas above. With luck you will hear less of the the original response that "it looks far too complex", and more of the "when can we start using it!".