I was having a conversation recently with someone in my industry. The issue of usability testing came up. Specifically, they mentioned that perhaps they might not have time to run usability tests in the midst of just GSD (getting s**t done). I get it. I’ve felt that pressure. With so many things coming at you on a daily basis, you never really feel like you have time to focus and dig into a meaty problem. My answer though, was that I’ve never really been in a scenario where some kind testing wasn’t possible. It’s simply a matter of scale.
Eric Barker wrote a really great post that touches on this topic. Go read it and come back if you haven’t seen it.
Start with functions (not features)
As I wrote previously, it’s important to begin by thinking about the activities that you want to enable in the product (note that I didn’t say “tasks”), and how important they are for the customer. Spend some time away from your desk learning what your customers do on a regular basis. Leave software and products out of it for the moment. The goal is simply to learn and observe. If it helps, imagine yourself as Dian Fossey or Jane Goodall spending time in the wild. Your designs and ideas, and really your whole product, will be better for it.
Lower your expectations (but not your standards)
It sounds really bad. But it’s not really. Not every design activity should result in the most pixel perfect mockups. So don’t expect to create highly detailed designs right away. There’s a time and place for that, sure. But early on, you’ll want to explore ideas, and explore quickly. Spending time polishing details like colors and type styles can drag this down fast. So don’t worry about too much them at this stage.
Instead, focus on creating good usage patterns first (not pixel perfect details). This totally depends on the product you’re creating, and what kinds of customers you have. I tend to use wireframes for this stage of design, very simple wireframes. But you can even just sketch and make paper prototypes. Personally, I think wireframes work better because sketches can be a bit too low fidelity.
Most of my wireframes are black and white, maybe some grey thrown in if needed. They’re a level above sketching, but well below mockup stage.
Build quickly (but don’t EVER over-build)
Spend as little time as possible while making wireframes so you can get to building a prototype as soon as possible, using your wireframes as a guide. Sometimes, when people build prototypes though, they’re thinking of something that is as close to real as possible because they want to really know what it will be like if users go off into weird edge case areas of the product. But just like with producing wireframes, you really shouldn’t spend time polishing every detail in your prototype.
Instead, focus on building “just enough” to show how the experience will work. You can easily create convincing prototypes that look like the real thing without spending any time building out every detail and feature. The goal is to get to some form of a working model to really experience how the product will work. There is almost always a “best path” through an interface, and that’s what you should be focused on nailing down. For the rest of the weird edge case stuff, I either just leave it out or figure out some way to do what I call “error trapping” (which I’ll talk about more in the next section).
There are many tools to do this. I’ve even used Powerpoint to do this and it worked just fine. It was so convincing that even I (who built the prototype) forgot that I wasn’t actually using a web browser… Some of the most basic tools are just simple HTML. The tools are really not the point. Just get to a working model as fast as you can so you can iterate!
Generally, I spend at most a day, maybe a day and a half, banging out a prototype that I could then test with real people!
Test as much as you can (without killing your schedule)
There are lots of ways to conduct usability tests. The best is to have your actual customers come in and use your prototypes. You can look for “surrogate” users within your orgs as well. Building an accounting product? Do some early tests with your own internal corporate finance folks. At the end of the day, the methods and tools are not the things to focus on. The goal is to get actionable feedback so that you can iterate! So try to get that as fast as you can. If you have questions about methods or how to set up a test, let me know. I have lots of ideas on how to do that.
Don’t forget to share your test results. Data hoarders should just die in a fire. Educate your colleagues with the information you’ve gathered. After all, it’s not knowledge if it can’t be shared.
Oh, and about the error trapping. When prototyping, you can build into your prototype specific pages that force the user to stop what they’re doing, and have a quick discussion about what they were trying to do. This way, you can learn more about the intent behind the edge case usage, which is way more valuable than just knowing that the edge case exists.
Save the visual design for when it’s really needed
It’s not that visual design is unimportant. But early on, you’re probably more in a discovery mode, as opposed to a production mode. The benefit of working lo-fi is that you can iterate with customers well before any engineering time has been expended. The important thing is to not focus on the really tiny details that will drag your progress down, and instead focus your efforts on the things that will help you move your product forward. Maybe you’re not generating revenue just yet with this process, but the feedback you get can be a kind of payment all its own.
Thanks for reading