The secret to usability is not brilliant design. Even the most talented designers have difficulty being creative on demand. Artistic talent helps but it is not a requirement. Anyone can create good, usable products. There are a few techniques to help you create good designs.
One secret to good design is using iterative processes. You must understand the problem, the preferences of the intended audience and how they think. This takes time and some trial and error.
Usability is not just applicable to computer software. Any object that people must interact with – hammers, coffee makers, software, anything – benefits from experimenting and iterating the design. Whether your product exists in the real or virtual world it will benefit from usability testing.
Another secret is to collect careful metrics. Keep a careful comparative history of the usability results. This is critical to understanding how each tweak effects audience satisfaction.
Here are some techniques I have learned from my undergraduate and graduate studies in the human-computer interaction field and my work experience. You can apply these techniques to any project/product you create.
The key to usability is to get people to try and accomplish tasks using your design. Don’t ask them if they “like it”. This will not yield in useful observations. If you are really unsure of an aesthetic choice, you can ask specific questions like “Can you read the blue text”. Remember legibility practices like never put green text on a red background.
“Using the screen/interface/tools in front of you, how would you accomplish X?” (where X is the goal).
Don’t give them any more prompts. You can answer questions, but keep it short and non-specific as possible. Observe their behavior.
Now begins the hard part. Prompt them to talk out loud and share their thought process. This is tougher for introverts, so you might have to prompt them a lot. Say this, “Share with me what you are thinking. There are not wrong answers. It’s all your opinion.”
Get people who represent your target audience. If not available, then use anyone you can, but do not pick people who think like you. Do not use your team if you can help it. You need people who are going to challenge your assumptions and “break” things. If you start to feel uncomfortable because they are doing stuff you did not anticipate, then that is a great test. Your assumptions need to be challenged.
Every one of my designs begins on paper. Electronic wireframing tools are great, but the eraser is still more cost effective. Paper prototypes of menus, information screens, workflows or physical objects gives you the ability to quickly sketch and revise designs.
Put the paper in front of testers and ask them how they would use it to accomplish a goal. Once you are comfortable with the results your design is getting from paper testing, then move your design into some virtual tool for more intensive testing.
But, start with paper. You’ll quickly see what ideas have the most potential before spending the time building more detailed virtual models.
Revise, Test, Rinse, Repeat
This is where you can tweak the process to fit your needs. Traditionally, usability leads build wireframes, test them and present results to the team before any code is written. However, with agile/scrum the pace is much faster. Thus, usability testing is more easily done if you add tests as stories.
As stories are completed, try to write stories that test usability and functionality for each one (or logical blocks of stories). For example, if a set of stories builds out a reporting section in an app, then write stories to test if managers can intuitively view metrics for their team (ease of use) and print them out (functionality). In general, I recommend writing a functional test case that minimally satisfies the story. This helps you avoid the temptation of over-engineering the solution for each story (but more on this for another blog posting). Lastly, add appropriate usability test cases.
Again, the key to creating excellent usability is to continually tweak and improve. Agile provides a natural mechanism to do this during the course of a sprint, but waterfall methods work just as well.
Streamlined Metrics (A.K.A. No More BHRs!):
I was trained using the Deborah Mayhew approach to usability. First, you perform the ethnographic observations of the audience in their environment. Then, you perform tests of the app with prototypical audience members (BTW, I dislike the word “users”. Only IT and the drug trade refer to customers as “users”). Once completed you write what Steve Krug calls the BHR (or big honking report). This can be quite time intensive.
Krug’s book Rocket Surgery Made Easy strips the usability process down to its most critical elements. Instead of the BHR, you perform smaller tests focused on a smaller groups of features. The idea is that if usability is a pain, it will be skipped. It’s better to do small efforts and make tiny improvements than do nothing. Additionally, smaller reports are easier for developers to digest and fix than a huge list of improvements.
Getting Others to Buy Into Usability Testing
I have a 12-step process I loosely follow for any Web or Web based app development (more on this in another blog). Usability and business analysis are the most critical early steps in any project. It is tough to usher in organizational change and bringing in usability process can be a fight. Few people question its usefulness, but many rightfully bemoan how labor intensive it can be.
Try doing these little steps to get started: paper prototypes, virtual models, integration of testing into agile stories, and iterate, iterate, iterate.
You’ll see immediate benefits with little effort added.
- NOTE: All views and opinions are those of the author only and not official statements or endorsements of any public or private sector employer, organization or related entity.
Chaeny Emanavin is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.
Leave a Reply
You must be logged in to post a comment.