How FreshBooks Prepares Usability Tests in Only a Day

Prototyping and preparing for usability tests doesn’t have to be a drawn-out, painstaking process.

We don’t actually use calendars like this. Haha, so analog! (Photo by Eric Rothermel)

If you follow a Lean UX process you already know that you need regular user feedback. At FreshBooks, we put our work in front of our users every Thursday and use prototypes as the basis for getting feedback. Once you’ve got your rhythm, you can do it in a day.

We’ve learned that prototyping and preparing for usability tests doesn’t have to be a drawn-out, painstaking process. Unfortunately, I’ve seen plenty of organizations where it’s just that.

How we structure our Lean UX sprint

How do we know what to test? Our week-long design sprint is designed to test a hypothesis:

So our Thursday tests aren’t just a “let’s show stuff to users and get feedback” session (although those are good too). Each usability session tests our hypothesis; the idea that our sprint is pinned to.

Since we test on Thursdays, our prototype and test plan need to be prepared each Wednesday. We know we’ll return to our circle at the end of the week to say whether we disproved the hypothesis. So we can’t half-ass it; every week, we’re held accountable by our team.

That means a good prototype and test plan are crucial.

How we spend those 8 hours on Wednesdays…

… varies a little from team to team, and week to week. We don’t follow this process to the letter every week, but it should give you an idea of how FreshBooks UX designers keep our prototyping and testing lean.

10 a.m.: Get final circle feedback into mockups

We’ve already sorted out our hypothesis for the week — for example, “we believe that introducing friction into the signup process will increase conversion” (just go with me on this). This is usually squared away on Mondays.

On Tuesday the designer is exploring design options to test that hypothesis. At the end of the day, we show those options in the Design Circle. We end Tuesday afternoons with a design circle, where the team finalizes what we’re testing.

So Wednesday mornings are spent incorporating feedback from that circle into our mockups.

11 a.m.: Write your test plan for Thursday

Once we’ve polished off the tweaks to the mockups (we hope they’re tweaks!) we plan our test. Here’s what goes into a good test plan:

  • Goals: How do we know we’re testing our hypothesis? What trouble spots do we anticipate? You might phrase your test goals as questions you need answers to, like “Can the user sign up for FreshBooks?”
  • Tasks: How will we formulate a task that will meet our goals, but not lead test participants? For example, “Sign up for FreshBooks”. We also draft the follow-up questions to each task based on the expected outcomes, like “Why did you drop out after step 4?”

Because we use the same template every week, including the same script to start tests and a few key questions we ask everyone, like “tell us about your business,” we don’t need to over-document or reinvent the wheel. (Here’s a good template from Steve Krug if you’re starting from scratch.)

It’s a good idea to validate your test plan with your PM. Hey, it’s a good idea to write it together, if you can.

12 p.m.: Have lunch

We like lunch. Try Tuck Shop!

1 p.m.: Plan and building the prototype

We almost always use Sketch or Illustrator and Invision. They’re terrific, quick tools; they allow us to test both desktop and mobile apps, and they fit with our practice of iterating at a fairly high fidelity. (Each designer can use their preferred tool, as long as it gets the design across). Once our screens are designed, dropping them in Invision and building a prototype by linking hotspots is quick and easy.

It’s important to note that we jump from sketch to Sketch. We skip lo-fi prototyping and use the sketches from charrette to design directly in high-fidelity tools. That’s not always a great practice, but it works for us because we have a strong pattern library. So, we’re never really starting from scratch. In fact, we’re usually iterating on an existing pattern.

On a typical Wednesday, we’re pulling those sweet mockups into Invision and building a prototype that maps to the test we planned in the morning.

4:30 p.m.: Check in with participants

Since we test on Thursdays, we remind each participant with a quick phone call on Wednesday afternoon. We book our participants well in advance, by emailing a segment of FreshBooks users and asking them to sign up to our You Can Book Me form. YCBM sends automated reminder emails, but frankly, the call is more personal (and therefore more FreshBooksy) and more effective.

5:00 p.m.: Test the test

What could go wrong? So much!

We like to test our tests by conducting dry runs. It’s never a bad idea to do these with a PM or fellow designer if possible. Ideally, we test our test with whomever is going to observe our session the next day.

Often FreshBooks designers will conduct tests solo, but we encourage designers to pull in observers. A PM is great, but getting any scrum team member to participate is a win, plus it’s handy to have them walk through the test with us. Together, we’ll find blind spots and technical issues we might’ve missed on our own.

We try to cut any questions from our test script that aren’t directly related to our test goals, i.e. based on the hypothesis we want to validate. We often spot pointless questions when we’re testing our test. Cutting them feels great.

6:00 p.m.: Give High Fives

And home we go.

What have we learned?

Every designer should be able to build their own prototypes, and to test their own work. Building and testing a prototype can easily be a part of your weekly process.

We’ve made it part of our weekly process for almost two years now, and it’s enabled us to create a completely new platform for FreshBooks (we’ll have much more to say about that later). It also helped us generate more insights in a shorter amount of time, with much greater confidence.

Have you tried lean prototyping and testing? What’s worked for you?

And another thing:

FreshBooks is looking for participants for Collaborative Design Labs. And if you like this article, please pass it on.

Jeff Kraemer is a Principal UX Designer at FreshBooks.
Show your support

Clapping shows how much you appreciated Jeff Kraemer’s story.