Can audiobooks be better than books?

Audiobooks have been around for years, as have the apps people use to listen to them. Audible, Audiobook and others have been dominating the space for the last decade. People generally feel comfortable using these apps. But could they be better? My goal was to find out how to make audiobooks more personal, enjoyable and useable.

My Role

I partnered with my good friend Braydn Degrawd, a UX student at DevMountain and audiobook expert. In this partnership, I was specifically responsible for:

1. Ethnographic research
2. Designing UI
3. Creating prototypes
4. Usability testing

Research

Assumptions

I started this project with a few assumptions:

1. People listen to audiobooks because they are convenient.
2. People who listen to audiobooks miss dog-earing and marking physical books.
3. People like physical books because they can be personalized by marking, dog-earing, and collecting them.
4. Students would like audiobooks because they are convenient and students are required to read a lot.

Survey

I had limited knowledge of audiobooks starting this project, having listened to them once when I was a kid. To get a broader view of audibooks, I sent out a survey to fellow classmates and their friends. In addition, I decided to test whether audiobooks would be useful for students by asking if they would like to use audiobooks for school.

From this question, I realized that audiobooks for students wasn’t the problem our app should solve. Students said they valued the ability to mark in books and also expressed concern about listening to a math or science text book and falling asleep. In addition, I saw issues with publishers as being a giant roadblock to making this app. I felt like, while an audiobook app for students does have some potential to solve problems, it would be better designed another day.

Another questions the survey asked was, “Do you prefer reading books or listening to audiobooks? Why?” Reading responses to this opened up two insights to the project. First:

11 out of 13 people who preferred audiobooks mentioned something about convenience.

This was an assumption I had from the beginning but it was helpful to get it reaffirmed. Second, the survey showed:

22 out of 53 people who prefer reading books mentioned comprehension value

This was our most significant finding of the survey. Almost half of those who answered this question thought that reading a book gave more comprehension than listening to an audiobook.

Interviews

In addition to the survey, I conducted three interviews with friends and classmates. I do understand that in an ideal setting, friends aren’t the best people to interview. However, for this project, it proved to be very insightful.

During the interviews, I was focused on learning what people did and why. I asked our interviewees about the apps they use, when they listen to audiobooks, how often they listen, what the didn’t like about them, among other things. What was interesting to discover was that, in addition to answering those questions, they talked a lot about comprehension issues without ever being prompted. There were two quotes that really stuck out in these interviews:

Nowhere in the research, surveys or interviews did anyone mention the word personal. Our initial assumptions were that people wanted something that they could make their own; something personal. I assumed they liked that books were markable, dog-earable, and physical. However, no one that was surveyed said anything about books being personal. So, I started asking, “why not?” After spinning for hours, I realized that the reason people dog-ear pages, mark lines, or anything else to a book is because they want to remember the book more. They want to comprehend and remember what they read. That was the problem.

With the problem realized, it was time to start coming up with solutions. Throughout the project, both my partner and I had written down potential solutions. I went through those and found some that still applied to our problem. At some point, there were too many solutions, so I suggested doing part of Google Venture’s Sprint to get on the right track. We each made two sketches showing ideas that would solve the problem of audiobooks not being focused on comprehension.

I then pinned them on the wall and, with my partner and two of our instructors, posted dots on the ones that we liked the best. Two ideas of the four were chosen for our project. The first was a feature that allows users to read along and mark passages of text while listening to an audiobook, then go back and see what they marked in each book. The second feature was called SmartNav. The research showed that many people loose their place in audiobooks and get distracted. SmartNav is a button that, when clicked, asks users what the last thing they remember listening to. Users can then select what they last remember and pick up right where they left off.

Lastly, I tried to find a way to implement a rewards system. I tossed around a few ideas and eventually settled on a quiz that allowed users to randomly receive rewards after taking a certain number of quizzes. The quizzes also continue to solve the problem of comprehension. I did not build out the rewards system because of time constraints.

While I realized these features had potential to accomplish our goal, I couldn’t think of a way to create a stand alone app from these features. So, this project is an example of how these features could be applied to another app, like Audible.

Low Fidelity

Prototype

I chose to create the low-fidelity prototype using Framer, mostly because I wanted to learn it, but also because it allowed for testing of audio features that actually worked. It took a long time, and I definitely questioned my choice. However, in the end, it was a great learning experience that resulted in a simple prototype used for testing.

Screenshots from our first street tested prototype. Check it out.

Usability Testing

After making this prototype, I went out and started testing. Our budget on this was nothing, so I stopped random people in downtown Salt Lake and asked them what they thought every button did. I noticed some things that were unique:

1. Every person clicked on the book, which was so intersting. Each one had different thoughts for why they did it, but they all expected either swiping or clicking on a book to do something.
2. The users did not see the function of a swipe-able menu below the buttons. No one saw that or tried to use it.
3. Ever person interviewed got the idea of SmartNav, but not fully. There was confusion as to whether it was in a book or a chapter, among other things.

After realizing these things, the prototype was altered and taken back to the streets. I ended up approaching over ten random strangers in addition to classmates and family members for testing. I felt like, more than any other project, I could see a difference in our design totally based on feedback from user interviews and usability testing. Each user had valuable feedback that heavily influenced the final design of this project.

High Fidelity

Mock up

Once I felt good about the low fidelity prototypes, I switched gears to Sketch and high fidelity. This took a long time. I didn’t want to wind up with something that looked exactly like Audible but the page really called for something simple. I tried many different backgrounds, colors, and fonts and ended up going with a white background and green buttons within the app. I felt like this accomplished exactly what I wanted; focus on the features while still looking clean and professional. When I finally settled on the final design, everything felt right visually.

High fidelity prototype screenshots. Check it out.

Usability Testing

Back on the streets, the new prototype addressed the concerns users had before, in addition to the updated visual design. To be fair, I did not test this end prototype nearly as thoroughly as the other four or five due to time constraints. However, I did get some great insights from usability tests with the hi-fi prototype:

1. On the quizzes page, people could find and take quizzes just fine. However, when they got an answer wrong or right, there wasn’t any feedback on why they got it wrong and where they could find the answer.
2. Users had no problem using the menu in the top right corner. I was worried that they would think this was not intuitive on an iPhone but thankfully the design worked for them.

Results

Through our testing, I realized that the features in our app allowed users to comprehend more. Every time I showed someone the SmartNav they were excited and wanted to use it. From the interviews, I also got helpful feedback on how things were working.

The one thing I would change

While I was happy to have stayed in wireframe mode for longer, I used Framer too early. Framer is an amazingly powerful tool that can create beautiful interactions. However, for our test, it was too much. I spent hours Framing something that I could have done equally as well in InVision in 20 minutes. What that taught me was that tools are just that: tools.