I recently had three very different experiences with poor software design. The first experience was as an administrator of a major healthcare IT product. The second happened while processing a report for a large non-profit music organization. The third was as a user of a small museum web site.
Out of these experiences, I found some central themes:
- Do not require the user to re-key information that they have already entered.
- For large amounts of data entry, provide a feature to upload via Excel or plain text.
- Provide a clear way for the user to save their work as they go, so that work is not lost if they get interrupted during entry.
- Data that is shared across several processes should be configured to update all references automatically when the admin makes changes.
- If text boxes have character limits, state this upfront and/or provide a counter that gives feedback to the user.
- Do not use the same icon for multiple (different) actions/features on the same screen.
- Do not nest features on a screen in such a way that the nesting requires additional scrolling, particularly when the scrolling moves important buttons/controls away from the user.
- Always allow a graceful option for the user to quit.
- If an error message must be shown to an end user, make the message as clear as possible, stated in simple terms that give the user information on how to proceed to avoid the error, or how to recover.
- For a multi-step process, provide a way for the user to see a top-level view or outline of the whole. Provide a way to look backward as well as forward.
- Look beyond getting the task done. Look at how the task is completed. How many steps, how much entry, scrolling, screen movement, eye movement, rework, confusion? This may not always result in the smallest amount of code. More code may be needed to take into account more user variables. It is the user experience that matters most.
- Design administrative tools with the same high level of user-friendliness as the end-user product. Do not short-change the administrator because they are allegedly more “willing” to deal with imperfections in design. Do not assume that administrators – being more technical by nature – are willing to put up with more frustration. Administrators are users too!
- Have real users work with prototypes (not programmers or designers) before unleashing the software on the outside world.
Programmers, and even software designers who work as intermediaries, tend to develop tunnel vision – sometimes very quickly. Asking a developer or programmer to do testing is not very productive. We can make programmers more aware of better design concepts, but at the end of the day – they are still programmers. They may be very good – even brilliant – but they are not users with the same stake in the product. What has been called “usability testing” is also not foolproof for catching poor design. Users have to live with the product – programmers do not.
