A Semester-Long Sprint

Abstract: I was following the book Sprint by Jake Knapp for one of my college classes. Each day has a topic that you would focus on and base all of the activities on a singular and later a granular topic, which then includes testing your iterative idea.

The Problem

I focused on the Apple iPad Keyboard and its split view for this sprint. The button you use to find the split keyboard is hard to find; because of this, only a few people know how to use it or even know that this feature exists. So, the basis of my technology fix was adding a more functional button to find the split keyboard. Initially, I was planning on testing the keyboard's accuracy. Still, once I realized that almost no one even knew this function, the split keyboard, existed, I changed my plan to the findability of the button.

Objectives

The sprint is set up as days; you accomplish a task to iterate the fix you want to make each day. Monday, you verify the target of your research. Tuesday, you improve upon your target by finding additional solutions to what you wish to fix. Wednesday’s task is to outline the problem, potential solutions, and outcome fully. Thursday is storyboarding; in this stage, you find the real solution to the problem and start creating your prototype. The final day, Friday, is setting up the experiment to test the prototype you have made. As part of this, you start testing. The teacher asked us to test only five people for this class, and each sprint section took 2 to 3 weeks.

The Process

Monday

A whiteboard is used to draw up the targeted design fix.

Monday began with some confusion about what we were supposed to do. After the teacher explained it some more, I started coming up with my target, which was, in other words, the main focus of my sprint. I had already decided to focus on the iPad, but I was still defining my target at this point in my sprint. My ideas for the focus/target were comparing the split and merged keyboard for accuracy, how much time it takes to find the button and the accuracy between three different sizes of iPads. I started to focus mainly on typing accuracy and how I would find the reasoning behind the increased or decreased accuracy with things like screen size, space between keys, and the size of each button.

Tuesday

Crazy 8’s then focusing on three of the eight solutions.

Tuesday, we began with an exercise called crazy eights. In this activity, we had one minute to draw out a variation of our ideas, including doodles, diagrams, headlines, stick figures, or anything that formulates additional ideas. My variations were not of the same idea, just different things I could test. After finishing, we chose one of the eight to go into more detail in a three-panel drawing. It had to be self-explanatory, anonymous, and visual. It could be ugly, have words, and had to include a catchy title. My plan changed after this assignment, focusing on how people find the split keyboard rather than the typing accuracy.

Wednesday

Storyboarding solutions.

I began storyboarding my final solution on Wednesday. The storyboard is how I planned out the keyboard layout and the reasons behind the design. It is titled “How to Make the Split Keyboard Better?” It starts with what it looks like and then goes into how I would adjust the keyboard. This adjustment included adding the split and merge as an individual button, adding a gesture for dock/undock and dismiss the keyboard, and adjusting the spacing for both things. After I drew this, I realized I was trying to add too many things to my granular idea. I removed the gestures and adjusted the size of the keys to focus solely on the added split and merge buttons.

Thursday

My Paper Prototype.

We were supposed to prototype our sprint idea quickly based on our storyboard. I decided to use a paper prototype because it was the fastest way to create an example prototype. The teacher wanted it to be disposable, appear natural, and be enough of a learning example. Once I assembled the prototype, I needed a trial run to see if it worked. I tested it with one of my classmates, who understood how it worked, so I was successful. Between Thursday and Friday, I created another prototype with the same base images using Adobe XD. The digital prototype felt more accurate because it was based on technology; however, I can fix it as suggested by my tests, which I will review later.

Here is the link to try my prototype:

testing Prototype

Friday

For Friday, I needed a set plan for testing the prototype. This plan needed to include a friendly welcome, context questions, an introduction of the prototype, a task for them to accomplish, and then having them summarize their thoughts by asking questions.

My whole test is as follows:

I would introduce myself and explain the reason behind the test, reference my Colloquium class, and explain the assignment. I designed a prototype based on a feature on the iPad’s keyboard. This interview is to find out if this redesign is the right way to go and, if it is, how to improve upon it. I then ask some basic context questions.

1. What is your name?
2. What is your age?
3. Have you used an iPad before?
4. Did you know that the split keyboard feature existed?
5. Have you seen the split keyboard?
6. Have you ever used it?
7. What is your background in using technology for Apple products?

I would then test them with the original version of the iPad keyboard. This would be to see how fast they could figure out how to find and use the button that splits the keyboard and then merges it again. I would time them and see if they could do it in under 2 minutes. Once they were done with my test, I would have them look at the prototype and test it in the same way.

The Original Version vs. the Prototype.

Then, have some follow-up questions, which are:

1. Which caused you the most frustration? Why?
2. Which was easier to find? Why?
3. How would you improve my prototype?
4. Do you have another way to design this feature that would be better?
5. Would you use the split keyboard if my method of finding it was used? Why?
6. Is there a reason to even be able to split the keyboard?
7. Did you like the symbol I used? If not, why not? If yes, why?
8. Would you have put this button in another place?
9. Would you use progressive reduction after the symbol had been established? For this question, I would explain the term before asking the question.

Testing

Blue is the time it took with the original layout, and orange is the time it took with my prototype.

I tested five people and had very similar results with each person. It took them at least a minute and forty-five seconds with the original iPad to find the button and split/merge the keyboard. They all got a hint at a minute and thirty seconds and then proceeded to find and use the button within 15 seconds. Then, once I had them use my prototype for the same tasks, they were able to do it under 20 seconds.

For the follow-up questions, they typically had similar responses.

Which caused you the most frustration?

The original iPad. This answer was because it is not visible, and the interface to use it is unnatural.

Which was easier to find?

The prototype because the button was visible. Is there a reason to even be able to split the keyboard? Yes to be able to hold the iPad comfortably while typing.

The testers had a couple of different views on the following few questions. On the question How would you improve my prototype?

One person suggested that the keyboard icon be easier to dismiss, made more prominent, and increased in size throughout the prototype.

Did you like the symbol I used? If not, why not? If yes, why?

Three people would adjust it to two arrows pointing towards and away from each other, and the other two liked it the way it was.

Would you have put this button in another place?

There were some very good suggestions for replacing it. One suggestion was to move the icon up to the top of the keypad, and the other was to separate the dismiss keyboard button into two buttons, one for the dismiss keyboard and one for the merge and split.

Adjusted with two separate buttons OR with the button up by the icons. (that could also be just the symbol)

The final question that had opposing viewpoints was

Would you use progressive reduction after the symbol had been established?

This was split between yes and no because of the transferability between people who use the iPad all the time and those who hand the iPad off to show them something that requires the use of the keyboard.

Outcome

Some reasoning behind some of the changes involves a few design principles that can apply to my redesign. The first is ‘Iconic Representation’, second ‘Performance Load’, and third ‘Visibility’. I added an icon to symbolize what my button does, reduced the performance load, making it faster for people to find the function, and made the function more visible, making it upfront and easily accessible, not hidden and confusing. I still have some adjustments I could make to my process, but this got the job done.

What I Learned

From what I have experienced with this semester-long sprint, I would be able to enter a workspace that uses the sprint as its main mode of creation because I now know what I am doing with this. It was very enjoyable to reiterate something that I felt needed to be fixed, and as shown by my testing, the time spent finding this button decreased by a large percentage.