How & Why We Designed an Interval Timer
A case study by Trimm
Recently, we decided to try out a new design process to quickly and effectively design prototypes for our internal and collaborative projects.
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
For awhile, Kevin — my co-founder at Trimm — had been mentioning an idea for an interval timer. So, this became our training ground. We scheduled out a few days to tackle the problem and designed an iOS app prototype we learned a lot from. Check it out below:
Understanding The Problem
At the start of any design sprint, you’ll have — at best — a loose idea of the problem being solved. That’s usually the case for the entire team and this is actually a good thing. We learned to dive deeper than the surface problem and probe into the why behind the problem and empathize with who experiences it.
In this case, the who was Kevin. But the why behind this design was less clear. Kevin had lived with this issue for awhile but hadn’t stopped to really think of why until now. At first, we started with a job story — well, a few job stories:
There was a common theme here. So we created a catch-all story:
When I’m on a schedule, I want to be reminded at regular intervals so I can complete my scheduled task
But why? Why complete a scheduled task? What’s at the root of this problem? The exercises recommended for the design sprint help suss out an answer. As silly as it may sound, we simply asked ourselves “why” five times. The results from such a simple exercise were profoundly helpful:
Our problem is punctuality. Our user is concerned with this aspect of their life and helping them better manage their time means success for the user. The first day of a design sprint is intended to achieve this level of understanding around a problem — whether solved by a business, a website, or an app.
Embracing Divergent Thinking
It always seemed counter intuitive to throw an exhausting amount of ideas at a problem to solve it — wasteful, even — but it’s critical to fostering creative solutions. While we stumbled a bit and couldn’t resist the temptation to share ideas early and often, once we reached the bottom of the barrel of ideas, the most interesting solutions came about.
The second day of the sprint is about getting creative. It’s normal for a group to approach a problem with a solution in mind, maybe a few, but rarely 16 for every person on the team. We ran two rounds of Crazy Eights to get the creative muscles moving around.
Sketching 8 solutions in 5 minutes materializes some obscure ideas. Sometimes those obscure ideas spark an epiphany within the team or break through a block on an established idea. We picked the best of the sketches to run with and began wireframing the user flows:
Assumptions, Conflicts, Decisions
We had several debates over the order of inputs and screen interactions for this app. Whenever debates came up, we asked ourselves, “are we assuming too much?” and, if so, we’d throw it on the assumptions board with a plan to test and validate the assumption.
If ever an assumption wasn’t the source of dispute, there was a clear conflict — two solutions to the same problem — and we had to weigh out the two. Often, this means testing both solutions, but sometimes that isn’t the right decision. With the proper time and resources, testing both is ideal and possible, but you’ll want to focus on building a single testable prototype.
The goal up to this point has been to sketch and brainstorm around possible solutions, slowly refining sketches into rough wireframes and user flows. Once this work had been done, it was time to put it all together and get it in front of users. We used a mix of static and animated interface mockups to simulate the experience of using the application.
We assume the user wants to get the work started quickly, so the first screen on launch is to set the timer. We provide subtitles to give the user more context on how much time their timer takes, when they’ll be finished, and the duration of each interval.
At first, the timer screen was filled with options, but we realized that the user will first want to pause before making concrete decisions to affect the timer. When paused, the interval carries on — until stopped — while shortening proceeding intervals to prioritize the user finishing on time.
We wanted a visual way to subtly convey the passing of time to the user. We decided to change color over the course of the day and brightness over the course of an interval. Using the metaphor of an hourglass, the brightest point moves from the top half to the bottom as the interval runs, swapping once a new interval has begun.
Learning From Users
A proper design sprint ends with a day of user testing. For this, we worked from a cheap and fairly reliable sample: family & friends. Ideally, we’d seek out users who best fit the target demographic or persona. In our case, we were most concerned about the usability of our design and that requires the app to function for any possible user opening the app.
We designated a series of tasks for our users to complete to test our interactions and user flow, and reviewed each screen with them to infer their understanding of purpose and functionality. This is where the assumptions board comes into play. Each assumption should be paired with a plan to test and validate its success or failure with users — be it specific questions about the assumption or simply observing behavior.
We learned a whole lot in getting this prototype in front of users. Usability testing is so illuminating because you realize how little you know about the people who are utilizing the design. For us, some of our assumptions were very wrong — particularly ones we hadn’t even considered large enough to make note of.
Many users were confused by how to pause or extend an interval. We designed the app to automatically extend an interval while paused — assuming a user would pause because they were spending too much time on a single interval, not to stop the timer completely. Some users expressed interest in defining extended intervals manually and before starting the timer. Most users associated pause with a more concrete stop than with an extension of time.
We also found that our verbiage may be a cause for confusion. We continually use the word “interval” to describe the reminders spaced throughout the timer. This word has a strong associaton with exercising, but our design doesn’t include breaks or variable interval lengths — something many exercise interval timers do include. Although health and fitness was a use case we considered, we payed attention to the use case of a dieter. Since the intended purpose is to space out time for work tasks, it may be most appropriate to use “tasks”.
We enjoyed practicing the design sprint. Its a useful framework for rapidly investigating ideas and testing them with users. There’s nothing as satisfying as going from a loose idea on Monday to a user-tested prototype on Friday. We will continue organizing design sprints for internal and collaborative projects — local and remote — to improve our process and design better products.
We are Trimm, a design studio helping startups and small businesses realize the impact of great design. Interested in working with us on your next project?