First user feedback

I sent my first prototype invitation to the original creator of MarinaraTimer – my colleague Peter. Peter still uses the app every day, so that seems like a good place to start. Critically, I didn’t ask Peter to give me predictive advice or just look at some design mock-ups. I just asked him to use the prototype in real life. I prepared him for how rough it is, and how I’ll be highly responsive with any feedback he has.

Peter tried the standard Pomodoro timer first, then the Custom timer, both during his normal workday. Right away he had some interesting feedback. Some he gave to me in person, which I recorded in Nolt. Other suggestions he submitted himself.

Over the next week, I received (and generated) suggestions and bug reports with Peter, prioritized them and worked on them immediately. I replied to the threads when I launched each individual change, sometimes including screenshots. In a way, I used Nolt’s board as a backlog. The work-stream is super narrow, so this approach is working just fine.

Prioritization

When deciding what to work on next, I consider a few things:

• Is it a bug preventing someone from using the app, or causing confusion or extreme friction? Neglecting these issues risks losing engaged users or getting inaccurate feedback.
• Is it going to teach me something about how people actually use the app in real life? Large or small, these work items tie directly to my goals.
• Is it quick to work on, or getting a lot of votes? Knocking out small or frequent user requests can engender trust and improve engagement.

If something doesn’t fall into one of these categories, it gets pushed to the bottom of the stack.

In focus

Most of the bugs revolved around the timer alarm sound itself, not being audible due to various device quirks. I immediately prioritized these issues and added a “sound test” button to help users determine if there is a problem with their device (eg. having their volume turned down). I learned that there’s a desire to make sure the alarm is working before setting and forgetting it.

Other friction centered on the timer itself, including the “millisecond” countdown being distracting, and there not being a way to pause the timer via keyboard. These were quick wins. I learned that while multitasking, users don’t want to think about the timer (or maybe even see it at all), but they also want to be able to switch to it and operate it quickly.

The only new feature request was the ability to customize your timer URL. (This exists in the legacy app, but I hadn’t developed it yet because I hadn’t yet understood the reason it exists.)  I asked for more info on how this feature would be used. The main reason for the request was to be able to type in the URL by memory. Makes perfect sense!

On hold

Other suggestions revolved around aesthetics. To be honest, most of these came from me! I want the app to be pretty and pleasing to look at. But so far, no one else is asking for that. So I forced myself to put it on hold.

Next steps

It’s been about a week of testing and iterating with Peter, so I’m going to invite one or two more people into the app and keep collecting feedback.

‍