10 Rules for Providing a Good User Experience
I am not a designer, I don’t play one on TV, and I didn’t stay in a Holiday Inn Express last night. But over the years, I have developed some thoughts around UI / UX that have resulted in some basic “rules” to apply when building systems. While this set of rules is far from complete, I felt the need to capture them.
What is the most useful starting state for a user? Users need a good starting point in software, the starting point needs to be useful, and a good jumping-off point for the application.
Don’t lie to the users. Don’t label something “Save” when it doesn’t save – that is particularly annoying. Make labels accurate and relevant.
Think about all groups of users. Most systems have a variety of users, so a good user experience should accommodate them all. This also means helping users with different accessibility needs.
Good UX shouldn’t require colors. A common aspect of user experience is the use of color (e.g., green and red being the only indication of a different state). There needs to be something more than just color, especially for color-blind users.
Speed of rendering / interaction is part of UX. Most systems need to be very responsive. Adding some responsive notes or thoughts to a design is very important.
What happens with large amounts of data? What happens with small amounts of data(or no data at all)? If your system may show large amounts of information, carefully consider how this is presented to users. On the flip side, how will that same system show small amounts of information? If it’s a table of data, what happens if you have millions of rows, or if you have no rows?
The UX has to understand the limits of the platform. A design is only relevant if it can be built. A design that works against a platform is just plain annoying for users.
The UX needs to consider error states. Probably the thing most missed in UX is the error states. For example, what should be displayed when the application loses network connectivity? Never leave the user wondering.
The UX needs to consider processes that run a long time. Every operation in your system won’t be instantaneous. Having a plan for notifying the user of asynchrony in behaviors is very important. This isn’t just about big background processes; it could be subtle things such as an autosave feature.
The UX must be aware of the budget. UX can vary depending on the tools chosen and the richness of the interactions proposed. For projects with a limited budget, you will often need to stay more inside of existing controls.
I do have opinions on what needs to be considered when designing software systems, although I’m not a designer. This list is an incomplete collection of what I think about when evaluating user interfaces or considering the overall user experience of systems. If there are more that should be included, let me know in the comments below.
