Time for a Test

Design Sprint

Jun 30

When I was in high school, the last thing I wanted to hear was that there would be a test or exam in class. I don’t like tests, but that never changed the fact that they are a part of the academic process.

Thankfully, in the design sprint process, tests are actually enjoyable. And no, I’m not talking about paper tests, or those “scantron” ones where you have to completely fill out a bubble with a #2 pencil. I’m talking about user tests, where you show the user your prototype and examine how they interact with it.

Speaking About Tests…

Prior to taking a test, you have to review. So before I get ahead of myself, I’ll take a moment to mention that this blog post is part of a series documenting a design sprint I’m doing with two other group members. We are designing a fintech app that will teach personal finance to teenagers. My first post details what a sprint is. I also wrote about the pre-sprint process, ideating and sketching ideas, voting on a solution, and building a prototype. This week’s post is about phase 4, where we conduct user tests to see how well our app actually does with people.

Why Test?

According to Pattie Belle Hastings in The Sprint Handbook, “Testing is not merely the final hurdle in your sprint; it’s the gateway to understanding the viability and potential impact of your solution.” The best way to see if your solution works with people is to… well… see if your solution works with people. Without user testing, you’re taking a chance on your solution without actually seeing if it can actually give you the result that you want.

Say you see a nice t-shirt at the mall and decide you want to buy it. If you don’t try it on in the fitting room, you don’t know for sure if the shirt actually fits you (and yet, most of us do this). Instead, you’re taking a chance simply by trusting the tag with your size on it. The assurance that the t-shirt actually fits you comes when you test it. If you don’t, you risk going home, storing the t-shirt in your closet, eventually putting it on one day, learning that it doesn’t fit, sadly realizing that you no longer have the receipt, and because of that, can no longer get a refund. If only you had tested!

Pre-Test Preparation

My team met in the middle of the week to determine how we would recruit participants. One of our members created a Google Form for sign ups. Eventually, a list of questions to ask during the user tests were developed.

After that meeting, I texted two individuals to see if they would be interested in being a user test participant. While one declined the invite, the other accepted, and I went ahead and scheduled a time for us to meet virtually.

Here’s a takeaway from the process: like any test, you need to prepare for it. Sure, the user is jumping in without much context, but you, as the facilitator, must do your part to ensure that everything goes smoothly.

A Welcoming Environment

The second my user hopped into the Zoom call, I sought to make sure the meeting felt like a welcoming environment. I asked my participant how their day was going, and allowed them to become comfortable before sending them a link to the prototype. In Sprint, Jake Knapp writes, “the first job of the interviewer is to welcome the customer and put her at ease. That means a warm greeting and friendly small talk about the weather.” Ok, I didn’t personally ask about the weather, but I got the gist. Making the user feel welcome is a top priority. You know about the process, but chances are, they don’t. It’s your job to put them at ease.

Observation

The next step was to observe how my user would go about using the app. There were two things I was checking for here:

If the user can easy go from one place to the next
If the user can figure out how the app works without much context

Before letting the user click around in the Figma prototype, I gave them context behind what the app was. I told them that it is a fintech app designed to teach personal finance to adolescents. I explained that they were a test user, and that I would be examining their use of the app. Aside from that, it was up to my user to play around in the app.

While the user was testing the app, I had to give what Knapp calls “nudges.” In Sprint, Knapp writes, “Asking target customers to do realistic tasks during the interview is the best way to simulate that real-world experience.” In this regard, I gave my user some ideas as to how to operate within the app.

Asking the Simple Questions

After the user had exhausted everything they could do in the prototype, I then went into some of the pre-prepared questions created by my group. Debriefing is important, because it gives you the opportunity to understand the user’s thoughts and perspectives.

How do you feel about the color scheme of the app?
Do you think the font choices are legible?
Is the app easy to maneuver?
From 1-10, how knowledgeable are you on personal finance?
Do you play mobile games?

Overall, the feedback from my user was positive. They stated that the app was easy to navigate, and that everything was readable. The only piece of feedback? Making it easier to understand what each menu item meant.

Debrief

My sprint team met on Saturday to discuss the results of each of the user tests. According to the “Conducting Debrief Sessions” course on UXcel, “A debrief after a research session is the time to reflect on it with your team, encourage deep learning, and make complex connections.” This is exactly what my team did. During this debrief section, we showed what we collected, categorized them into positive and negatives, and saw trends across our feedback.

I compiled everything into a Miro board, using sticky notes to separate the positive and negative feedback. Across the board, we typically got the same results from all of our users. Overall, users didn’t thoroughly respond well to the color scheme. However, they all believed the app was easy to navigate and that the text was readable.

After examining the positive and negative feedback, we compiled these into learnings. This allowed us to see what could be improved upon. That way, the negative feedback isn’t just disregarded – it is used to make a good thing even better.

Reaching the Finish Line

The sprint is now technically complete. We actually did it! Our team successfully created and decided on a solution, built a functioning app prototype, and tested out with people other than ourselves. Now, it’s time to write a report about the experience and wrap the sprint up for good.