Usability goals 101
I've discussed using usability goals in several articles on this site as well as actually writing my thesis on the matter back in 2001. Hence, from time to time I've got questions on how to actually create and use usability goals in the best way. This is what this article will try to explain.
When gathering information from stakeholders in a project you usually end up with a lot of functional requirements (as in "You shall be able to save your drawing in a PNG-format") and some semi-functional ones (like "The drawing shall be stored in a database"), as well as some non-functional ones (for example "The system's latency when loading a drawing from the database shall be low"). These latter ones tend to come from stakeholders with a technical perspective, but these non-functional requirements are obviously quality aspects of the system, and so is usability. Thus, the quality 'usability' should have an equal place in the requirement documentation as the other non-functional requirements. But, what subqualities of usability are there?
The answer to that question is simple and at the same time somewhat complex; any adjective that users may use to describe their interaction with the system is a subquality to usability. If the user wants the system to be snappy, then a corresponding usability quality might be quickness or swiftness. One could argue that this is the same quality we spoke about above from a technical perspective, i.e. latency. But, latency is the exact (timed) response from the system and quickness is the user's perception of this response. For instance, if a call to a not-so-well-designed database would take 30 seconds (high latency), then giving the user appropriate feedback during this time will get the user to rate the quickness as fairly high. Not giving feedback, on the other hand, would get a really low quickness rating. (In effect, this means that a good design can make a bad system look better, and a bad design can make a good system look worse.)
If you feel that the users might not be able to express different qualities, then you can use already set subqualities. The most famous set is hidden in the ISO definition of usability (i.e. in ISO 9241-11). It specifies the "extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use". The qualitites being effectiveness (task completion), efficiency (task in time) and satisfaction (user's experience).
In practice, usability goals are often created to make the qualities more general. Contemplate the example below (from Hackos & Redish), where a more specific expression from the user is written in broader terms.
These kinds of goals can be used as project goals (where they are sometimes called effects), as sprint goals or milestone goals, or simply serve as focus for a design.
But if we make them measurable, they can be what makes your usability process legitimate in a world of non-believers. You can for instance measure efficiency by the time it takes to complete a task, by judging the percentage of the task that was completed or the number of times the interface misleads the user. What works best is up to you. Below is another example from Hackos & Redish, this time of how a usability goal can be translated into a measurable objective.
But, you usually end up with goals that require a user's subjective opinion. You can probably not tell your superior at work that the users thought that the product was fairly nice to use, you have to be a bit more precise than that. I usually go with a five- or seven-point Likert scale as in the example below:
I would not recommend using a ten-point scale, because that would give the users too many alternative. And in Sweden, since we have a special word that means "just enough, not too little, not too much", in some occasions I would go for a four-point or six-point scale, not to make it too easy for the users to pick the middle one.
In an ordinary project I would start out by running a contextual inquiry with the users working in the current version of the system or a competitor's, and afterwards try to create usability goals from the needs and requirements that they express. Then I would create measurable objectives from these usability goals and ask the users about their feelings about the current system (or measure time/errors/etc. during an observation). This will set a baseline for the project. During the design and implementation phases, I use the usability goals for focusing my design work and the sprints, as well as using the measurable objectives when testing out mockups and prototypes. I sometimes use the measurable objectives as definition of 'Done' for agile stories, as well.
When using the Effect management method, the usability goals (and their measurable objectives) are the core for everything created in the project, and the results from the method are steering the project. In the example below, a baseline has been set and the business owner has decided what would be the level to reach for the effect to happen.
Afterwards, when the product is finished, I use the goals and objectives for usability validation. Below is an example of how my colleagues and I summarized the usability validation results, including some statistics, in a document for executives just before product launch:
I am certain that there are other ways to use these goals and objectives. Do drop a line in the comment field below if you know of other ways to use this. And by the way, here are some more examples of measurable objectives presented by Usability.gov.
Now that I have shared my knowledge concerning usability goals, please share yours in the comment, especially if this small article has helped you in any way.
 Hackos, J.T. & Redish, J.C. (1998). User and Task Analysis for Interface Design. New York: Wiley & Sons.
 Pär Carlshamre - A usability perspective on requirements engineering