How to measure "usability" in a specification-requirements document?

Question

Starting to look at my last year project now, and so I'm doing the specification-requirements document. Now, it just so happens that this project requires a high degree of "usability" - I dunno if this is the right word in english, but what I mean is that it should be really easy to use from a user PoV. Now - in all the projects I've worked on so far, usability haven't really been a great factor, and so I could just write some gibberish to get around it. I always asked our teachers how they would specify the requirements of usability though, but no one have yet given me an answer I felt was good enough.

Our teachers have always preached that any requirement given on a project should be "test-able", but how do you test how easily accessable your user-interface is?

Say I had a real-time application running. Here it wouldnt be too hard to say "an entry should be deleted in less then 100ms after the initial call". But it's a lot harder to say "The userinterface should be 86% intuitive".

I guess this is a tough nut to crack, but surely I can't be the first person in the world to have thought about this, let alone having problems with it.

Answer 1

... how do you test how easily accessible your user-interface is?

With usability tests.

Basically, you grab a bunch of your friends (because you won't have any money to encourage strangers to participate) give them the documentation a new user would have and ask them to perform the system's key use cases.

Ideally, you want your test users to have at least some of the qualities of your target users, so if your system is aimed at a technical audience then your classmates will work; however, if your system is aimed at the general public then you're going to want to get your friends in Arts, Human Kinetics, etc. to participate.

So how do you turn that into requirements? You identify your key use cases and stipulate what how usable should they be (walk-up usable, a few minutes with the documentation, real actual training...) and then verify that your test subjects can complete the use cases without too much frustration, with the right amount of training, in a reasonable time.

Answer 2

I would advise you against quantifying usability requirements. The problem is not so much that you can't define metrics. You could say, for instance, that

• it should take a person not longer than x seconds to find y on the site, or
• the conversion rate of the store has to be higher than z%
• etc etc

The problem is rather that you have to spend time and resources on finding acceptable target values for your metrics that you can actually reach. What is an acceptable time to find a piece of content?

Answer 3

Try to define usability in terms of "test-able" requirements.

You already gave yourself the answer, because usability can be described in terms of requirements like "an entry should be deleted in less then 100ms after the initial call".

What makes a user interface 86% intuitive? This can’t be answered without some form of measurement. You need to ask what features can make a user interface intuitive. Talk to the customer and the potential future users. Gather features (or better dig for them!), which would make working with the piece of software easier.

Maybe you get a list of features like:

• The department’s organization must be shown in a hierarchical tree view.
• In this tree view drag & drop must be possible.
• The font size must be configurable and saved for each user.
• On the top of the screen there must be a list of important links. Each user may configure and save his own personal list.
• ...

Make requirements out of these features. They are “testable” and thus “measureable”. If in the acceptance tests it turns out that 17 out of 20 features are working, you have 85% success.

EDIT: This works in a project environment, where you need to deliver measurements (like in many commercial projects). If you have a "softer" form of project environment where not everybody is poking on figures, then sticking too much on this formalism may be counterproductive since flexibility and agility may suffer from this.