To Assume is Dangerous

Building something on a stack of assumptions gets you into trouble later on in a project, usually resulting in a couple layers of iteration that could have been avoided. We’re supposed to be designing for people, not just us! A lot of heartache and all nighters to meet deadlines can be avoided by taking the time to get some real feedback outside of the office’s walls. We’re smart people and we want our products to be useful, so let’s put it in front of the consumer for feedback. They’re the ones paying the bills after all! The good news is that it’s a lot easier than you think to keep your assumptions in check with some good ol’ user testing.

Where are we going with this?

One of the biggest mistakes is not knowing what questions we’re trying to get answers for. Soliciting general feedback can be a good thing, but when you’re in the early stages of your design, it’s not going to be as helpful as pinpointing the exact areas that need focus for improvement or optimization. Hearing what people think based off of brief interactions with a prototype won’t really get you anywhere without consistent questions for the users to answer. If there’s no consistency in the questions it’s hard to find a pattern and it becomes akin to reading tea leaves. Having a set of questions that you follow is the best way to synthesize takeaways, otherwise you get a big stack of stickies that take a while to untangle.

Tips for great takeaways:

1. Keep the questions simple - It’s hard to answer multipart questions in a clear and concise way. Giving a scenario followed by a single question will give you concise answers while users are testing.
   • Scenario: You’re having users test logging into an account and find the settings.
   • Good: Did you run into any barriers when signing in and finding the settings?
   • Bad: What did you think about your experience?
2. Look for patterns in the feedback - If multiple people run into the same barrier, chances are that’s where you should investigate. Redundancies, as with any sort of feedback, help us gain clarity on our direction.
3. Don’t suggest changes based on each piece of individual feedback - As designers we actively listen, but that doesn’t mean what the user says goes. We synthesize their feedback and deliver what they need, not just what they want.
4. Don’t ask leading questions - This plants an answer in the testees’ heads, and reinforces an opinion or assumption that we’ve formed. For unmoderated testing, it’s slightly less of an issue since they’re on their home turf and probably comfortable. In moderated situations, they’re in an unfamiliar place, talking with unfamiliar people, getting asked multiple questions about unfamiliar items verbally and on paper. As a subconscious defensive social action, people are more likely to try and empathize with an opinion someone shares with them rather than contest it. But we don’t want them to adopt our opinions, we want their honest thoughts.

So, we have all these results...

Once synthesized, the results of these tests can be used in onboarding stakeholders as well as times when we’ve come to an impasse with clients or team members. They are also useful as checkpoints for certain stages of our designs to make sure they’re on point and the project doesn’t crash and burn. Let the data be your guide! It’s the best way to reduce inefficiency in our teams’ processes, but it’s also important to realize that we can’t test everything; there are diminishing returns.

---