Talking Usability: Adventures in Agile—User Friendly Forms

The poor usability of any form can be attributed to ambiguous instructions and confusing labels. Not all developers are familiar with best practices of form design, which creates an opportunity for you—the technical communicator—to provide suggestions for improvement.

I worked on a project to design an office application to replace paper-based forms. The staff was satisfied with using paper-based forms and using email to distribute them for review and approval. The new application would use browser-based forms that integrated with other office applications and automated approvals.

The project followed the Agile development process, which requires demos at the end of each sprint. Business analysts used mock-ups to show design concepts and validate design decisions. Every meeting with users resulted in enhancements to the mock-ups. The mock-ups were quickly updated in preparation for the next meeting. In the haste to convert the mock-ups into online forms, developers overlooked that instructions were poorly written and the labels of buttons confusing.

I noticed the errors with the forms when testing the software. I mentioned the errors to the project team at the daily scrum, and reported the errors (and how to correct them) in bug reports. The developers considered the errors low priority and promised to fix them when time permitted. Unfortunately, the developers did not have the time to make the corrections. Consequently, the mock-ups (with errors) became the final design.

The project manager decided to conduct user acceptance testing and training simultaneously because he considered them opportunities to collect user feedback. I was aware that the forms contained errors so I used as few images of them as possible in the user guide. Although the instructions on the form were poorly written, the instructions in the user guide were clear and concise. Needless to say, the user guide became a solution for poor product design.

I learned a few lessons about designing forms that I share with you:

• Always proof read forms, especially when testing software.
• Report errors via the proper process. If the errors are not corrected, inform the project manager.
• If the project lacks a user interface style guide—create it.
• If developers do not understand the best practices for form design—teach them.
• If the project needs more time to do things right—ask for it.

The quest for user acceptance is lost if forms are poorly designed. Remember that you are the user advocate; do whatever you can to ensure a user-friendly product.