1. The Client Is Not The User
The client may think she knows what the user wants, but she cannot. This is because the client is not the user. This brings me to the second principle.
2. Don't Give The Client What She Thinks The User Wants
If the client does not know what the user wants and you give her what she is asking for, you are doing her a disservice. You will ultimately be delivering an application that does not meet user's needs. Your client may initially be happy that you have given her exactly what she asked for but will she remain happy when the product is rejected by users?
I have seen too many designers and developers who are aware of these two principles but proceed to reach the wrong conclusion from it. Namely, that they know the user better. Which brings us to our next principle, which is, simply:
3. You Do Not Know What Your User Wants
You may be a user interface designer or developer with many years of experience but you do not know what users want. Which users? Those specific users who will be using the current application that you are building. Why? Because every application is unique. You may have built similar applications but, unless you have built exactly this application before, you do not know what the users of this application want.
So, who does know what your users want?
4. Only Users Know What Users Want
It's a basic concept but one that is alien to much of our industry. Only users of your application will know what works and what doesn't. It's surreal that, given this, most of us in our industry go out of our ways to delay asking them what they think of our applications. This brings me to the most imporant principle of all:
5. Test Early, Test Often, Then Test Again
Usability testing is not rocket science. In fact, it's quite a simple recipe:
Ingredients:
1. Two rooms
2. One or more representative users
3. A computer running your application
4. A usability tester
5. A video camera (no tape)
6. A TV screen
Take two rooms and place a computer running your application in one of them. In that room, place a representative user and a usability tester who will ask the user to perform various tasks in your application. Place a camera in the room to relay your user's actions to your design/development team who should be watching from the second room. (Ideally, having the rooms next to each other means that you don't have to run too much cable between the two but you can just as easily use wireless technologies or even broadcast the feed over the Internet to a development team across the globe.)
Leave to simmer then repeat.
Notice that you do not even need to record the test. If you do, chances are those tapes will become paperweights like most artifacts that are created during development. Remember: Agile is good.
Doing usability testing does not involve a large upfront financial investment. You can put together the above setup for around $1,000 these days. What it does involve, however, is buy-in to a User-Centered Product Development (UCPD) approach from the highest levels at both your and your client's organization.
Following a UCPD approach involves capturing measureable Usability Requirements alongside your Functional Requirements. You will have to set aside time to carry out usability testing at every iteration in your development process. You cannot do this without a budget. And you won't have a budget unless you have buy-in at the highest levels.
The above principles are perhaps the most important ones as they will determine your development process and your development process will largely decide whether your project succeeds (is accepted by your users) or fails (is rejected by your users.)
Alongside these process-related principles are design principles. These do not, in any way, replace testing. They are intended to give you a good starting point when designing your user interface, before you go to your users and say, "What do you think?"
6. Talk One Language
There should only ever be a single term or phrase used to refer to any given item in the application. An item here may refer to a concept, a business function or task or even a widget or individual interface element. You will find that the use of a metaphor for the project, as advocated by eXtreme Programming (XP), will ease this task tremendously.
7. Respect User Effort
Try to limit the user's physical toil while using the application. Repetitive Strain Injuries (RSI) are a fact of life today and we, as application designers, have to accept responsibility for the ergonomics of our applications.
8. Make difficult decisions
It is your job as the user interface designer to layer the user interface and make important decisions about its organization. Don't leave these decisions to the user just because it makes your life easier. If your application has a huge preferences section, treat this as a Design Smell and review the design to see if you have left decisions that you can make to the user.
9. Let The User Work
Users must be able to perform their most frequent, most important tasks without any resistance. For an SMS Messaging application, for example, this would include reading, replying to and forwarding messages and quickly checking the various mailboxes.
10. Prevent, Don't Scold
Whenever possible the UI should prevent the user from making a mistake instead of alerting the user to the mistake after the fact. This must be achieved without the UI getting in the way of the user.
11. Give Sufficient Feedback
The UI should give the user sufficient feedback for user actions. (This ties in nicely with Steve Krugs "Don't Make Me Think" philosophy: The user should never have to think "did that work?") Related to Don't Lose The User.
12. Show, Don't Tell
Although this may seem to contradict the Give Sufficient Feedback principle, it is actually meant to compliment it. Whenever possible, meaningful visual cues (when appropriate to the audience) should be chosen instead of lengthy textual descriptions. This can also pertain to actually teaching a user to do something in an application by showing them.
13. Don't Lose The User
The UI should protect the user's sense of spatial positioning. The user should never feel "lost" within the application.
14. Don't Sell What You Can't Deliver
Users must not be given Graphical User Interface (GUI) expectations that cannot be met (or can only be partially met) within a Web User Interface (WUI). Whenever OS or GUI expectations are set, they must be fully met. That said, the application must try and meet OS expectations as much as possible, especially for ergonomic features such as keyboard shortcuts and navigation but also for expected auxiliary helpers such as tooltips.
Don't Sell What You Can't Deliver is the main principle behind why Adobe chose to create a new component style called Halo in Flash and Flex instead of trying unsuccessfully to emulate either the Windows XP or Mac OS X look and feel.
15. Don't Keep Them Waiting
The application must perform fast enough to be considered usable within the given engineering limits for the application.
16. Innocent Until Proven Guilty
The user should be warned about a validation error on a control only if they have had a chance to interact with that control. (In other words, you should not perform validation on controls that are in their initial state and initially display a form full of validation errors.) Similarly, resetting a form should remove all validation errors.
17. Usability Approach to Accessibility
There is a trend I am noticing in our field that I find very worrisome and it concerns accessibility. Many people appear to be on a quest for the Magic Button of Accesibility (MBA). This is how an MBA works in an ideal world:
You gather usability requirements for your application for a given target audience. This target audience involves people with good eyesight, hearing, and motor control. Based on the usability requirements for this specific audience, you expand resources in designing a good user experience for this specific audience. You then spend further resources in developing your application, going back to users within this specific audience to get their feedback and to alter your design accordingly. Finally, right before you deliver your application, you press the Magic Button of Accessibility.
The Magic Button Accessibility magically makes the experience of your application as good for various other audiences. These include people who have various levels of sight, hearing, and motor control. Isn't it amazing that the MBA can transform a carefully crafted experience for a single audience into equally pleasurable experiences for many other audiences.
Unfortunately, the Magic Button of Accessibility doesn't exist because it cannot exist.
The MBA is an extreme example of the check-the-checkbox mentality to accessibility that is pravalent in our field today. I call this Checkbox Accessibility: For the most part, we do not really care what sort of experience users with accessibility requirements will have with our applications as long as we can check a checkbox on some form that says that our application is compliant with a set of rules.
If we can run our applications through a program that checks for this, all the better. After all, software is cheap compared to devoting extra time to design and develop an equally good experience for various other audiences. Checkbox Accessiblity is head-and-shoulders better than no accessibility but it does not guarantee a good experience for users with accessibility requirements.
The other approach to accessibiltiy is to see it as usability with different audiences. In other words, you cannot make your application truly accessible for users with disabilities without designing for those users. I call this the Usability Approach to Accessibility.
Having a usability approach to accessibility means that you have to gather usability requirements for disabled users just like you do for users without disabilities. You have to usability test with disabled users. And you have to realize that "disabled users" doesn't refer to a single audience but to multiple audiences, including those with accessibility requirements in sight, hearing and motor function.
Of course, just like usability with an audience of non-disabled users, usability for disabled users costs time and money and will require buy-in at the highest levels of your organization. If you are serious about accessibility, however, anything less is just not good enough.
These are general points of advice that can apply to any application. Based on these overall guidelines, the following are examples of high-level design decisions that were taken and applied in Opal. Keep in mind that Opal was developed in Flash MX but the issues are the same regardless of whether you are building an application in MTASC/SWFMill/FlashDevelop, Flash 8, Flash 9, Flex 1.5 or Flex 2. Each of those tools and technologies provides different features, components, programming models and development workflows but the end result, regardless of which technologies are used, is always evaluated by your users.
