Quick, Fast Usability
Six steps to understand and validate.
Start ups are awesome for many reasons, but, personally, I love the hustle. Lots of work and not enough time led me to be massively productive. And while I never felt like one day was never enough, the sheer amount of work accomplished in that day was usually pretty astounding.
It’s this hustle that made me realize that understanding how much effort to put into a task, doing it quickly and for a specific purpose is crucial. This coincides nicely with lean software development, which posits that you must understand the what/why of your work or product in order to validate and learn from it.
How, though, can you minimize work and still learn from it? In terms of design, the answer is constant and consistent testing. Every start up should be testing its ideas from the very beginning to even understand if the product is viable.
Learning can be validated scientifically by running frequent experiments that allow entrepreneurs to test each element of their vision. — Eric Ries, The Lean Startup
Quick and simple usability tests are an easy way to do this. While there still sometimes exists the common misconception that usability is hard to perform or takes a lot of time, testing can easily be lean, fast, and cheap. And, if done soon, it can identify issues before any code is written, offsetting time and development costs.
Additionally, testing is so straightforward that with just a little training anyone on your team (developer, designer, project manager, etc.) can create and execute a study to get actionable results.
Generally, this process can be broken into 6 steps:
1. Identify the area of focus
The first thing to do is to decide your area of focus. This might be easy at first, as there may be a couple of things that immediately come to mind. But as you continue testing, it may become difficult to decide the priority of things to test. A great place to start is with the product goals — are they all being achieved? why not? Is part of the product hindering these goals? If available, analytics can be incredibly useful to help understand under performing elements.
2. Specify the problem and hypothesis
It’s very important to understand exactly what you are testing and why you are testing it. Creating a problem statement and hypothesis around the problem are excellent ways to keep yourself on track and measure your work. For example, let’s say that your research shows that almost all your users are not taking a specific action on page.
Make problem statement from this, such as:
I believe users are not taking an action on this page because the call to action is hidden. (cause)
You can now create a hypothesis to test this, such as:
Users will utilize the call to action on this page if we prioritize it higher on the page. (answer)
Since you have both a cause and answer, you can create multiple ways to solve the cause. More than one problem statement and hypothesis will most likely be needed for any area, but, at first, you may want to limit yourself to a two or three, in order to maintain an achievable time frame.
3. Define metrics
Next, define the metrics by which to measure your hypothesis. In our call to action example, a simple metric for this could be:
Did the rate of users activating the call to action increase?
You can have more than one metric, but make sure that the end result is actually something measurable. Try to steer clear of things like “Users like it more” or “Users can complete the task easier.” Create metrics that are as quantifiable as possible.
4. Apply metrics to current concept
It’s important to apply your metric to the current concept so that you can definitively see if your new solution moved you toward your goal. Without this, you won’t have a baseline.
5. Create a new solution
Often I try to start the step with asking myself “what’s the lowest barrier to success?” In our call to action example, the lowest barrier may be moving the call to action or adjusting the visual design slightly. I like to start here because it allows you to test easy ideas before creating a solution that may feel perfect but would take a lot of time and effort to implement
6. Test and measure the new solution
Now, you actually test. I test with 3–5 target users for each solution and confine the test to 30 minutes. It’s also important to allow a little time before and after each test, about 10 minutes each, in order to digest and readjust. In one (very) productive day, I can test 7–9 users, which includes high-level markings against your metric.
This process works for me because I’m forced to focus on very specific items and tasks against concrete, measurable outcomes. And because testing is on a small scale, turnaround for results is quick. Ultimately, if implemented at the beginning of any concept, this will allow for less user issues when launched (or released) and allow for more confidence in your product’s usability.
