Applications exist to either make something easier for an end user to do or in some limited cases make it even possible. The UI in particular (and by this I mean either the GUI, the command line argument structure, however the users interact with the program) exists to make it possible for the user to accomplish tasks.
Despite what some applications display, the UI does not exist to show the user how the code works under the hood, what the data structures are that store the user's information, nor the graphical embodiment of the organizational structure for the team working on the project. The User Interface exists for the benefit of the user, and should be designed around the user. Novel concepts, huh.
Ease of Use
The summary of the entire article is that ease of use translates into user productivity. Productivity is, for most applications anyway, the whole point and the value proposition that gives customers the reason to spend the money.
It is critical to measure usability and usage in any way that is possible. If you don't know where you are, you can't know where to go. If you don't know whether a change is good or bad, you can't know whether the right decision is to make it, not make it, or change it in a way that will make it better. Of course, if you guess you're very likely to get it wrong.
So you need data, you need to make informed decisions. What are your choices?
Bigger projects and companies have their own Usability Labs where they can test out different kinds of prototypes to see what works, what doesn't, and how their current versions score. They can prioritize based on the biggest problems they have and either make changes to existing features or design new features to address them.
The ability to take prototypes to users and get feedback before spending time and resources on design, development, and testing is a big win. The industry is awash with bad ideas that could have been either avoided or fixed if this simple and relatively inexpensive exercise had been done.
Microsoft's Customer Experience Improvement Program is a great example of getting and using real-world product usage data to improve future versions. It is an opt-in, anonymous feature added to many Microsoft products that allows users to send data on their usage of the product. Opt-in and anonymous are both absolutely key to this sort of functionality, you should never collect information without consent and you should not store the information in such a way that you can tie it to other data you may have about them.
Some examples of questions this type of data is excellent at answering:
- How often do users encounter this specific error?
- If they select feature X, do they use sub-feature Y?
- Do only users with Pentium IV computers or better try do to Z? How often do they cancel it if it takes longer than 30 seconds?
- What is the average data transfer speed user experience with B?
In other words, if you need some data based on real-world usage of your application and you can't get a good sense of it from usability testing (there's a lot of data that falls into this category), letting your customers help you help them better by collecting anonymous data from them to feed into your decision making processing can be a huge help.
Pretty self-explanatory, you should get consultation from your friendly neighborhood statistician on the best way to design the questionnaire and choose the recipients to make the data you receive as meaningful as possible. Got questions? Ask your users and/or potential customers!
If someone spends money on your product they usually are more than happy to let you know what they think about it, and are just looking for opportunities to tell you about it. You have to listen, have well-understood ways to incorporate the feedback into your decision-making processes, and be able to turn the feedback into solid value propositions.
For most customers the problem they face (or at least feel strongly that they face) is the inability to effectively communicate to the company their feedback. Easily discoverable ways to let you know what they like and don't like, discussion forums to talk to each other and build a community of customers and users, these are great ways to get information and strengthen your customer base.
Fit and Finish
I debated when outlining this series whether fit & finish belonged in Usability or Performance. I ended up putting it here because these problems get in the way of the user trying to do tasks. It may not stop them, but it interrupts their flow. Since flow is crucial to productivity and efficiency, getting all the small details right can make your application more valuable.
A great example of getting all the small details correct is Raymond Chen's series of blog posts on Scrollbars. You may have to scroll down a bit for it (hahaha at hem sorry), but it is well worth it. Getting scrolling just right is a minor, nitpicky point for most applications. If you don't get it right your users will notice and will be affected by it. I'm not using this as an example of something you need to get right or else, but rather an example of how to approach fit and finish in your application.
Most Recently Used is a great example of something that is usually a usability win. Keep track of what the user is doing and optimize their experience around it. Make it easy for them to repeat what they usually do, so there isn't searching around or trying to find files, etc. It is not a silver bullet, however, and in some cases MRUs can get in the way instead of help. Usability labs help to determine which is which.
OOBE stands for Out Of Box Experience, in other words what happens the first time the user installs and runs your application. In most cases I believe that experience should be different than the experience they have the second time and onward they run it.
What do they need to learn to use your application? What needs to get set up to make it work correctly? How do you make the user feel good about the purchase? These are all good things to think about for the first time the program runs.
However, you should not get in their way every time they run. A few examples: splash screens, intro movies for games, wizards, tips and tricks, anything that gets in the user's way when they want to launch and get going.
One problem I think most products have is the company considers them an island and an experience unto themselves. Most are just part of an overall workflow the users are in the midst of to get their work done, the more you can do to get out of their way and make their lives easier the more valuable your product will be.
A good portion of usability is tailoring the UI interaction model with the type of work to be done. Creating a tree view of data because the programmer really understands how to use the tree view control doesn't make it the right way to have the user interact with the program (although it very well may be). Starting with what the users want to do rather than how you want to store it is a good start, but next is to figure out ways to taking advantage of different mediums (like GUI did with the mouse) to make things easier for the user.
A few newer items to think about and see if they make sense for your application:
This is both for the new Tablet PCs and for other form factors that have stylus input or standalone tablet devices. Is there an advantage to gearing workflow to this input style? Will supporting gestures in a deep way help user productivity? Can support of pens and digital ink be a source of differentiation from the competition?
Speech interaction with computers is just starting to be feasible and usable. One of the barriers is that mouse/keyboard input to applications doesn't translate well to speech input. There are interesting opportunities for designing interaction models around speech input that fully take advantage of the medium. I caution that it is still early, and you would be wading into uncharted waters. That said, the upside looks fantastic for those who can make it work in ways that users understand.
With Windows Media Center Edition there's another interaction model to think about: the living room setting. If your application is running on a MCE PC, and it makes sense, you might want to have an interaction model geared towards the users being 10' away and running the PC with a remote control. Think very big UI, easy to read, geared towards a remote control rather than a mouse, etc. This is also relevant for PowerPoint scenarios where the UI for the application is being shown on a large screen, possibly for a large number of people.
The line between the Windows Shell (explorer.exe) and applications is starting to blur. Instead of launching a separate experience to interact with data and accomplish tasks, there's a move to a model where more functionality is integrated and seemless. By creating Shell Extensions, you too can add functionality in an integrated and powerful way to increase your customer's productivity.
Pretty straightforward; small screens and limited resources for graphics, memory, CPU, and storage.