I'm hesitating to write the post on user testing because there's a part of me that wants to take my sweet time to get it just right so that it will be a super dope post.

Well, here's where the value of setting some clear principles around what I'm doing helps. On Day 1, I decided that I wanted to prioritize incremental over monumental and consistency over quality for the Maker Log. So I'm going to forget about getting it right and just write the user testing post in small parts just so I actually get this out. Here's what I'm planning:

Part 1: User Test or Die

You think of a great thing. You build the thing. You tell everyone about the thing. You expect your inbox to be blowing up with messages of "wow this is the coolest thing I've ever seen", but instead, nothing happens. Why?

Most likely, your thing is not as cool as you thought. But it's also possible that some people would've loved your thing if only they knew how to use it.

When you work on a product, you make a million decisions about how it should look and function. You put a particular setting on a particular page because that's obviously where someone would expect it to be. You come up with a clever tagline on your marketing site that does an unmistakably clear job of conveying why people should want the product. As you use the product you've developed, you think, "This is designed well. Everything works exactly as expected."

Nope.

If you're involved in making a product, you are automatically disqualified from evaluating its usability. You simply know too much. All those hours spent thinking about every little detail means that you've built up a world of context that new users don't have. This is the first step of becoming a better product designer/developer: Can you accept that you have blind spots?

Once you've made the mind-blowing discovery that not everyone thinks exactly like you, you can do something about it. It's pretty simple, really: Ask people what they think.

You might think that it's sufficient to send your product to friends, family, and/or a set of beta testers and ask them to send you feedback. This can help for identifying some types of major problems (e.g. "it doesn't work on my computer"), but it won't be enough because most people won't bother mentioning most problems they run into. If they struggle to understand something, they'll most likely ignore it and move on rather than send you a message to let you know that they don't get something. They might feel embarrassed to ask if they think that it's their fault that they don't understand something. Even if they don't, sending feedback is extra work that they'd probably rather not do.

The best way to identify major issues with usability or product messaging is to watch people in real-time as they try to use your product. The easiest way to do this is to literally sit next to someone as they try using what you've built and have them talk out loud about what they're thinking. There are some tips that I've found useful in running user tests for Hide Feed, and that's what I'll cover in part 2!


You're reading Road to Ramen, where I think aloud and share everything I learn in exploring the question: Can I make a living building things I love?

by DK the Human (@dk_the_human)