Call Recorder Feature Design Sprint
In his book “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days”, Jake Knapp summarizes what a sprint is: “The Sprint is GV’s (Google Ventures) unique five-day process for answering crucial questions through prototyping and testing ideas with customers. It’s a ‘greatest hits’ of business strategy, innovation, behavior science, design, and more — packaged into a step-by-step process that any team can use.”
The whole book is a DIY guide for running your own sprint to “answer your pressing business questions”. It’s full of real life examples from businesses that have tried it. I was about to run my own sprint along with other students from class. Before running my experiment, I needed a problem to be solved. In the book, businesses had complex problems to solve, and would turn to running a sprint as a way to find solutions fast. In comparison, my problem to be solved would be granular. An idea of a small problem but worthy to sprint about with well thought out details. After a few weeks of researching—and a few dead-ends—I came up with one.
Initiating the Experiment
Scenario
Imagine you’re a journalist starting out an investigation of an important issue regarding the disruption in the lobster migration patterns. You just found out that you’ve been granted an interview with a key ecologist at Rutgers University in New Brunswick, NJ. You’re stoked as this could be your big break! You always record your interviews using either your iPhone or a digital recorder. You might jot down a few notes on a notepad but that’s an exception. Memory is fallible, and you rely heavily on recordings of your interviews to get your story out. Besides, frantically scribbling notes on a notepad can be distracting to both you and the person you’re interviewing. You would rather spend your time listening attentively and asking meaningful questions.
The only problem today is that you’re a thousand miles away from New Jersey, and the interview will be in a couple hours in the form of a phone call. After reviewing your options, you quickly realize there’s no way to record your phone call interview using your iPhone alone. Right away, you start researching different call recorder apps you can purchase. The thought crosses your mind “why isn’t there a way to record my phone calls on my iPhone?”
Summary of Problem
Currently there’s no way to record a phone call on iOS. If you need to record a phone call, you’d have to use a third party app for a fee.
Hypothesis
If it were to become available, Apple users would value and make use of a built-in iOS call recorder.
Objective
Investigate how a built-in iOS call recorder feature could be implemented.
Process
I assess and offer a solution to the problem. I prototype and test it with real people. I make changes to my prototype according to the feedback I receive from user testing.
Outcome
I demonstrate how a built-in iOS call recorder feature can be successfully implemented in iOS using a realistic prototype.
Sprint Week
For a successful sprint, the sprint team clears a full work week — Monday through Friday — on their calendar to focus solely on one crucial question they come up with, to be solved during that sprint. Each day of the week has a clear schedule and focus.
Monday
On Monday, I thought about the outcome and what I wish to have accomplished at the end of the sprint, and came up with a long term goal. I also decided on a granular piece of the problem — a target — that I could realistically solve in one week.
Target: I would design a simple feature to record phone calls in iOS.
To come up with a long term goal, I briefly discussed the reasons why I was doing this project with other students, and in doing so, was able to get a more clear picture of this experiment’s long term goal.
Long Term Goal: Seamlessly add a call recorder feature into iOS.
I also came up with a sprint question: How can I integrate the call recorder feature with existing iOS call features?
I wrote both of them on a whiteboard and took a picture of it as a reminder to refer back to and guide decisions throughout the sprint.
Tuesday
Tuesday was the day I would work on solutions. I started the day with a quick exercise called lighting demo where I would write down the problem along with a few ideas I had for solutions. I only spent a few minutes on it. I then gave a 3-minute tour of the problem and explained the possible solutions I had in mind to the class. I asked for feedback. Next, I sketched out my solution ideas on several sticky notes with a marker. From those sketches, I took my strongest ideas and quickly sketched 8 iterations of them in 8 minutes. That’s another fast-paced exercise called crazy 8’s. The idea is to make you consider other variations or your strongest solution ideas. All you need for crazy’s 8 is a single sheet of paper folded in half three times, giving you 8 panels to sketch on. In my case, this crazy 8’s exercise helped me consider a few alternatives that I may have not considered otherwise.
Wednesday
By Wednesday I had a stack of a few different ideas, and needed to decide which ones to prototype and test. Wednesday is structured so the sprint team comes to that conclusion efficiently without wasting time in endless meetings and discussions. In the morning, I got together with other students who were also running their own sprints and we helped each other with this exercise. We followed five steps to get the job done quickly and efficiently. First, we revised our sketches and posted them on the white board. Next, we placed dot stickers next to what we thought was interesting ideas. Then, we had a quick discussion on highlights of the solution ideas. After that, each person votes for what they think is the best solution for each project. Each person gets to make the final decision for their own project.
In the afternoon, I took all the winning sketches and created a storyboard to tell the story of how my solution ideas could be used in a real life situation.
Thursday
On Thursday, I turned my solutions, ideas, and storyboard into a realistic prototype to test on Friday. I created and animated my prototype using Adobe XD.
Friday
I started this sprint with a challenge, and by Friday, after going through brainstorming sessions and several iterations of my solutions, I had a prototype and was ready to test it out with real people.
I tested my prototype with a total of 5 people. Research has shown that after testing a prototype with only 5 people you’re able to to discover most of its usability problems.
When you conduct user testing with a team, it’s best to have a designated interviewer while someone else takes notes. Since I was conducting the user testing by myself, I chose to record the user test sessions so that I could review them later.
I start the test interview with a friendly welcome to make people comfortable. I ask them about their day and other similar questions. I then transition to questions about phone call recording. I ask open-ended questions. I ask them to tell me about a time they had to record a phone call, and how they went about it. What did they like or dislike about it? After that, I introduce my prototype. I make sure to tell them some things may not work quite yet. I assure them there are no right or wrong answers. Candid feedback is the most helpful and that won’t hurt my feelings. I also ask them to please think aloud.
Test Questions
- Looking at the screen, if you wanted to record that phone call, what would you do?
- What would you do if you wanted to stop recording that call?
- What would you do if you wanted to hang up?
- Tell me what you think that is? (Screen after hanging up)
- What would you do if you wanted to listen to your recorded call?
Debrief Questions
- How does that prototype compare to an app you used before to record your calls?
- What did you like about this? What didn’t you like about this?
After the interview, I thank them for their time.
User Testing Results
Three users got confused with the screen I chose to start the test with, which was the screen after you press the button to start a phone call. One revision I’d make is to create a screen prior to that one where the tester would push a button to start the phone call themselves.
Two users had concerns about accidentally pushing the record button with their ear because of where the record button was located on the screen.
Four testers thought my prototype looked realistic.
One tester had suggestions about length of recorded call format. “It looks like the time, not the duration time”
All of them made positive comments about the call recorder timer.
All of them were able to start recording the call, end the recorded call, and end the phone call with no issues. All of the testers were able to push the play button to listen to their recorded call.
Three testers said they would use the feature at least occasionally. Two testers would have no use for the feature but could see how it’d be useful for other people.
Conclusion
In summary, a sprint is a quick and dirty way for testing out ideas to find out if they’re worth pursuing. It’s a chance to learn from your customers whether you’re on the right track. Even if your prototype fails and sends you back to the whiteboard and sticky notes, it’s still a worthwhile exercise because it helps you avoid investing large amounts of time and money into a failed concept. It goes to show that Design by Committee, a design principle employed on sprints, can also be successfully achieved in time-driven and fast paced environment. This 5-day sprint was actually done over the course of a whole semester as we learned the process. I thoroughly enjoyed the process and the book. My favorite part about a sprint is that there’s no time for overthinking your ideas. Every day has its own schedule and clear set of goals that keeps you and the team moving forward.
View my prototype here: https://xd.adobe.com/view/66720236-d073-400d-5df3-4ec403953773-1043/
