Article No :737 | October 1, 2011 | by Chris Griffith
Software developers often think the user experience as something better left to either the interaction designers or the visual designers on their teams. In actuality, developers can have profound impacts on the user experience of the products they’re working on. This article will explore some areas of experience design in which the development process has a more direct role. This is not to say that developers can substitute for UX and interaction designers, but they can play a role in making compelling applications.
Limit the User’s Choices
This may sound counterintuitive, but when a user is given too many choices, it makes it harder for the user to make any choices. When faced with an excess of choice, the user might abandon the application altogether, which is certainly not the choice we want them to make. This dilemma is what Barry Schwartz named The Paradox of Choice. I have seen this time and again in usability labs as we try to find that balance of exposing enough options to users without overwhelming them.
Just because we can expose a setting or function to the user with a few lines of code doesn’t mean we should. Consider the impact of adding one more menu item or one more button to your UI before you do. It might be a simple line of code, but it could greatly impact your product.
Stay Out of the User's Way
As the developer, in some ways you are user number one. Although the product may not be something you will ever interact with once it is completed, you and your development team are the first ones to actually "kick the tires" on it. While doing so, pay attention to the amount of effort it takes to perform a task. How many clicks does it take? How far do I have to move my mouse? The interaction flow might seem fine on paper, but once you start bringing the experience to life, see how it feels. If there are too many interruptions (dialogs, screen transitions, etc.), there might be a better method to craft the workflow. Remember you already know the right route; if it seems difficult to you, imagine what it will be like for a novice. This also applies to visual transitions. They may seem awesome the first time, but try performing the same task over and over, and I guarantee you will be reducing their duration by half or more.
Give meaningful and prompt feedback to the user's input. How many of us have been to an e-commerce site, made it to the checkout screen, and seen a message like this: "Only click the button once or you will be charged twice." Really? The developer of this site couldn’t take the time to disable that button after it was pressed? These are things that developers can easily fix. Simply setting the state of that button to be disabled once the user clicked on it would have greatly improved the user experience. You can then go the next step and provide some form of formal status indicator (e.g., a spinner or status bar message).
Remember the product experience should be designed for the customer, not for you or the QA staff. Speak your real user's language, not yours. One place I often see this is in status messages. It is great to give the user feedback on how the application is performing or how a process status is progressing, but "Loading Network Socket Interfaces…" is probably not that useful to anyone outside the development team. Consider more human language, for example: "Loading Modules (4 of 14)." The user still gets the feedback that the system is working, but without seeing the digital underwear of the application.
Does anyone like to wait? As interesting as Disneyland makes the lines for their rides, they can never match the actual ride itself. The same can be said for your application. As cool as that spinner or loading widget is, hopefully it’s never cooler than the actual application. As more and more developers create mobile applications, latency will again play a larger role in the user experience. Mobile devices do not have the same horsepower as laptops, and cell networks never match the ethernet cable connected to your development system. So think of how you might be able to shift and cluster your network calls (assuming your network calls were asynchronous already), or how your application can be loaded in smaller chunks.
Make Actions Reversible
As difficult as an undo system can be to code, having such a system to allow users to undo their actions will greatly improve the user experience. Knowing that they can revert their actions will give users a level of comfort. Your software needs to be forgiving; users make mistakes, so give them the tools to fix them.
When building your application, take care that the navigation scheme and organization layout used throughout are consistent. If you find yourself having to hack in some bit of code to make a new menu or layout work, that might be a sign that you are introducing a bad UI. All applications take some time for users to learn. The more consistent you and your team are, the faster that learning curve will be. Once a user does something one way, he expects that the next process will be done in a similar manner. As users gain mastery of a product, they develop a sense of accomplishment that can, in turn, become a level of trust in your product. There is a saying in the UX community: “We may not always get it right, but we make sure you get it wrong the same way each time.”
So what do all these guidelines do? Hopefully they give you some pointers to help create great user experiences in your next product. Remember, every bit of your product is an experience and first impressions, starting from the preloader, matter. Code responsibly.
If you are interested in learning more about user experience, here are some great resources:
- Designing the Obvious: A Common Sense Approach to Web & Mobile Application Design, by Robert Hoekman, Jr.
- Designing the Moment: Web Interface Design Concepts in Action, by Robert Hoekman, Jr.
- Designing Web Interfaces: Principles and Patterns for Rich Interactions, by Bill Scott and Theresa Neil
- Designing Interfaces: Patterns for Effective Interaction Design, by Jenifer Tidwell