Setting Usability Criteria to Guide Development

There can be amazing value in setting usability targets before you design the application. This technique may not work in all environments and all projects, but shoot if it didn't work really well here. Note: a lot of the ideas from this post come from Luke Wroblewski's amazing insights into Best Practices in Form Design. If you haven't see Luke speak, see him. If you haven't read his book, buy it now.

So what is a usability target?

In a usability test, you generally record some metrics of user behaviour. Sure, you can ask people, "Did you like this site?" or "What did you think of the colors?" but you aren't really measuring anything there. The issue is that even if you aggregate reactions of this nature and say

respondents gave a 3.75 on a 5 point scale to this
website when asked if they liked the site or not

how do you you improve that 3.75? Should you improve that 3.75? Name 5 things you could do to improve that 3.75. Who can? I couldn't. Maybe put some puppies. People like puppies.

However, if you were to say things like:

• 67% of participants failed to find the "Purchase" button
• the average time to complete the transaction was 13 minutes and 15 seconds
• 98% of respondents didn't look beyond the homepage

Now we're talkin'. You can develop a plan to raise (or lower) metrics like these. If you made the purchase button 30% bigger, I bet more people would find it. If you removed some steps from the checkout process, you could probably complete transactions faster. And so on.

Important note: I wouldn't suggest any value judgement on any of these numbers. While 67% failed to find the button, 33% succeeded in finding the button. Maybe 33% is a great number. Maybe your business couldn't handle if 99% found it. The point is that the metrics give you a place to start the discussion.

Crazy Idea
try this on for size: what if you set the goals before you even designed the site or app? What if the metrics were clearly established as part of the requirements?

That's exactly what we did in the faculty recruitment project. Everyone on the team knew the basic requirements:

• build an online application for collecting applicants to faculty positions
• deliver faculty applicant's data to hiring officers electronically
• be publicly accessible but store the data securely

some basic requirements, right? What we did as a team was to set some additional usability targets:

• Applicants must be able to complete the form in 90 seconds or less.
• Once an application is started, Completion rate must be near or above 99%.
• No logins or passwords that would prevent the application from being completed on behalf of the applicant by someone else.

These targets were set based on our understanding of our user pool, potential faculty at Ivy League institutions. And most of them would be physicians and surgeons. These users are not universally known for their patience and forbearance. Actually, they tend to be a very demanding group.

Given that we had these targets to achieve, many issues that could have otherwise been thorny fell into place quickly.

• Wherever possible, eliminate fields. All the data on whether or not you want to hire someone is in the resume/CV anyway, so no sense in asking the user to input their entire CV over again. Only display the minimum number of fields that are needed.
  
• Wherever possible, eliminate non-required fields. If they really, really aren't required, why are we asking them? Apart from data in the CV, there are data you could ask that would be nice to have, but are really needed. Get 'em out.
• Eliminate steps. People can scroll down. People do scroll down. If you make it obvious that they need to scroll, and there is content or ideas to see down there, they'll scroll. No need to add clicks & steps unnecessarily.
• Make flow of application obvious.
• Group like fields together
• Delete unnecessary text
• Make labels clearer (especially if you could add a word or two to make the intent clear)
• Make field sizes appropriate to the text they will store.
  

It became liberating, in a way, to have these constraints in place. Because it gave us a reason to say "No" to something. It also made decisions easy when it came to should we do it like X or like Y? If the decision impacted our usability issues, then pick the best one. If not, then it doesn't matter. The programmer can decide.

The end result is here:
http://www.med.upenn.edu/apps/faculty_ad/index.php/g303

Try clicking on an posting and then click "Apply for this position"

Tell me what you think.