Brady Hale

Dec 12, 2020

5 min read

Going through the Design Sprint Process for the first time

Exploring what went wrong with the Apple Siri Remote

Over the past 5 months or so, I have begun learning more about a process called the “Design Sprint.” The process is a “Five-Day process for answering critical business questions through design, prototyping, and testing ideas with customers.” In this case, it took me a little longer than “Five-Days” to explore the process and understand its importance.

For the Sprint, I chose a product that I use daily, to explore what “went wrong” with it and narrowed down a specific issue that I had with it, and went through the Sprint process in order to come up with a solution and test it. I chose the dreaded Apple Siri Remote. For the sake of the redesign, I was under the assumption that the users would already know how to navigate the remote and its functions.

Design Sprint #1 — Monday

In the beginning stage of the Sprint, it was hard to put a finger on what exactly is “wrong” with the Siri Remote. While there are a number of things that I would change with it, the most frustrating thing about using the Remote is using it in the dark or at night time. The remote, with its symmetrical design, is very hard to use just based on muscle memory when if you aren’t completely sure where the top of the remote is.

The goal is to design something that could be easily used in the dark with the addition of muscle memory to navigate the remote. In a perfect world, this change is for the people that already know how to use the remote. We are just changing somethings so that it is easier to continue to use it. We are purely concerned with usability.

Design Sprint #2 — Tuesday

Coming up with the best way to design the remote was actually pretty straight forward to me from the beginning. As a customer of the Siri Remote, this isn’t the first time that I have thought about it, and a small LED showing the direction (with a possibility of other functions) seemed like the way to go. In order to solidify that that was the best option, I ran through some exercises.

The first was just some doodles as to how I was going to solve the problem. The second was called “Crazy 8's” and it led to me storyboarding a little to get my point across.

Design Spring #3 — Wednesday

Storyboarding each possible option. The goal was to consider all possible situations that someone would use a Siri Remote and what the outcome could be. It was very important for understanding what would be needed for the prototype and how testing could turn out.

Design Spring #4 — Thursday

The idea that a physical prototype made the most sense when it comes to the goals that I had and what I wanted to accomplish. A series of tests will be done with lights on and off to see how quickly people can figure out the correct orientation of the remote. I will use the actual real remote and the cardboard prototype for the tests. We will be using aspects of visual and touch to figure out if the changes made on the prototype is a viable option.

Design Sprint #5 — Friday

The testing phase went pretty well given the circumstances I was under (being middle of COVID). Over the Thanksgiving holiday, I ran 5 tests with my family members, all of who have used the Siri Remote. One of the bias’ that they had, is they already have used it and they don’t like it either. This is how the test went:

Introduction to the product (later found out that they all have used one)
Questions to provide context:

  1. Have you ever used a Siri Remote before?
    What is your experience so far with the Remote?
    What's the good and the bad?
  2. What are the shortcomings of regular TV/DVD remotes?

Then I went about introducing the cardboard prototype to the person and told them what the plan was and ran through the tasks.

Lights on Task: Remotes were placed upside down. After sitting, testers will be asked to speak through their process as to what they are doing and seeing. Testers will be asked to turn over both the cardboard prototype remote and the actual Apple Siri Remote and identify which orientation is correct and place the “remote” back on the table. Testers will be timed and recorded for documentation and being able to be played back for review.

Lights off Task: 2 Tests were run the same way as the “Lights On” test. One of the tests, however, will start with the remotes face up instead of face down like the other test. Everything else will be the same.

Test Summary: The test went well functionally. What I was mostly looking for was how natural the applicants reacted when faced with the prototypes and how they handled them. While the testing went over well, after getting the results I realized that I wish I would have gotten other test users that hadn’t had a predisposition to the Siri Remote.

Sprint Summary

There are definitely things that I have learned and would change with my next experience. I learned a lot about certain things that I may be lacking in the design process, and it would be interesting to see how something like Personas could influence the sprint process. I also learned that I tend to pick a “solution” pretty quickly and should maybe open myself to other options because that may not be the best solution after all.

Things that I would change would be:

First of all, it is obviously suppose to be done over a week period, not over months. So it would have been interesting to do it the “correct” way and be able to go over multiple iterations over a short period of time.

The second would be the change in how applicants were selected (post-COVID would make things easier).

Overall the experience was great! I am glad that I have another tool under my belt!