Rakuten Kobo - Reader Experience

OVERVIEW

After Rakuten acquired Kobo Inc in 2012, Kobo Japan was created to leverage the technologies from the Canadian-based eReader company to address the localization needs of the domestic market in Japan, where cultures and values significantly impact the behavior of users. Within my team of 3 designers, I was assigned to key areas of the Kobo platform, specifically the Reader Experience, Download Management, and Bulk Actions platform. This case study will focus exclusive on the Reading Experience.

TIMELINE

5 months (April - August 2019)

ROLE

UX/UI Designer

METHODS & TOOLS

Domain Research, Competitive Analysis, Content/Feature Audit, Open Card Sorting, Use Cases, Figma

TEAM

Mariana Perez (UX/UI Designer)
Jungseop Kim (UX/UI Designer)
Jaime Zamorano (Product Design Lead)
Gisela Dietrich (Business Analyst)

PROJECT BACKGROUND

Among the race for marketshare in eReading, Rakuten acquired then Canadian start-up, Kobo, in 2012. Eventually, “Kobo Japan” diverged from Kobo Global (Canada) in order to address specific market and user needs. This was necessary, because Japan market accounted for most ebooks being sold globally. My team started working on Kobo back in 2017 as the core design team for small localized projects and consequent app-based features. By Summer 2018, our team was brought on in full-force to develop “Phoenix” - the new app redesign for iOS and Android. 

PROBLEM

Due to the local popularity of manga, a separate reading product was created to address the needs of local users. This, in addition to technical debt as a result of forking development, meant that there were several completely different reading experiences, including feature disparity amongst operating systems and device types/sizes. On an even larger scale, the experience is further divided due to other acquisitions of other companies with eReader products with their own designs, including Overdrive (acquired in 2015 by Rakuten), and Tolino (acquired in 2017 by Rakuten Kobo). The result: a very fragmented reading experience for Rakuten as a whole.

OPPORTUNITY

The Reading Experience is a large feature spanning across Android and iOS - with 3 different renderers per platform: Reflow, Fixed Layout and Comic. Across the 6 renderers, a Reading Experience UI needed to be introduced to control all the functionality and settings that each renderer provides to the user.  The intention is to have this UI overlay appear on the screen whenever the user taps the middle of the screen as they are reading their content and have it across all 6 renderers to make its usage intuitive and consistent.  However, simply coming up with a UI overlay wouldn’t do our users’ justice. We want to provide a unified experience for the product, while making intentional and informed design decisions to localize the reader for our specific market in Japan.

While our team in Japan focused exclusively on the Japan-specific product, our teams overseas recognized the issue and committed to aligning our designs across all organizations. On a bi-weekly basis, our team syncs with the Germany and Canada team to review weekly progress on design decisions, concurrent to the progress of the Pheonix project, in conjunction to create a “white label” library. While this article won’t focus on the contributions to white label design library, the decisions made in designing reading features specific for our market would make up the base of some initial designs that was used in the white-label portion of the Reader Experience.

DISCOVER

As the lead designer on the efforts for the “Open Reader” platform derived from Overdrive, I was added to the team mid project to offer support for the Reader Experience. As such, most of the research had already been done by my design team in not only filtering through product requirements provided by the business unit, but also identifying personas and user-specific needs that address the Japan market specifically:

1. The Japanese language is unique.
   The Japanese writing system is complex, consisting of three main scripts: Kanji (characters of Chinese origin), Hiragana (a syllabary) and Katakana (a syllabary). Different from any latin-based script language (such as English), Japanese can be read right to left, and also vertically top to bottom.
   

2. Manga makes up a large part of the Japanese reading experience.
   Manga, a type of Japanese graphic comic/ novels, are enjoyed by all gender and age demographics. The readership is large, the drawing style is unique, and the themes in stories are very wide. It’s significance is very much ingrained in modern day Japanese culture. Most importantly, in the context of the Reader Experience, it’s nearly entirely an image-based consumption/reading experience. 
   

3. Japan is home to very dense spaces. 
   Large cities, such as super metropolis Tokyo, represents about 10% of Japan’s entire population - more than all other 47 prefectures across the country, with a population density of some 6200+ people per square kilometer. Tokyo, Osaka, and Nagoya alone rank in the highest tier of population densities in the world with over 10 million people each. What this means is packed trains, packed buses, a whole lot of people, and just a whole lot less of personal space. This impacts a user’s experience when riding on a super crowded train, where your face is pretty much 10cm away from your phone (but you still feel the need to use it to read your favorite ebook!). 

UNDERSTAND

IDEATE

Building around use cases

Working together with our business analyst, we began consolidating requirements that outlined features affecting the reader experience. For certain features, we decided it would be necessary to extrapolate on use cases in order to clearly determine it's’ usefulness and practicality, and to ensure we were delivering significant value to our users.

In-scope feature requirements were categorized into 5 groups:

We agreed on which feature would impact which renderer (out of the aforementioned 6), denoting each as either "Native” or “Javascript”, referring to its original implementation method used in development. The general rule was, Native code would likely result in a high level of development effort, and required strong justification if we were to make any design changes. From this activity, we extracted several key features that required a deeper-dive, and brainstormed specific use-cases for each (denoted with * above).

For example, the Mark as Read/Unread function affected a wider scope of functions that impacted the user’s overall reading experience, even outside of the “Reader” module that I was focused on. Here are the use cases pertaining to the greater topic of Reading States (comments under each):

As a user, I want to know what books in my library are brand new

Once a user opens a new book, it is not new anymore. But what constitutes as new? 30 days?

As a user, I want to know what books in my library are unread

What qualifies as unread? What if I opened and closed a book I have never read before? Or I opened a book, paged forward once, paged back once, and closed the book? As this was fuzzy, we determined that it was necessary to allow the user to manually mark it as unread

As a user, I want to know what books in my library are completed

We approached this from two angles. First method was to have completion always triggered by the user as a manual flag. The advantage is, there’s no mistaking it based on some sort of computed logic. The other method, is to assume that a book is completed after a certain set of conditions are met.

Consideration 1: If we mark the book as completed after a certain x% of the book has been flipped through, do we prompt/ask the user whether they’re done with the book once they exit the reading experience?

Consideration 2: In series reading (frequent format found in manga series, denoting reading “chapters” of a manga series but each title chapter into a separate book), it’s safe to assume that if the user proceeds to the next chapter/volume, that the current volume/chapter is complete

As a user, I want to be able to identify which books I currently have in progress

There are several ways to interpret a book as in progress. This does not imply any book that has a non-zero progress meter is a book in-progress; there may be cases of books with a middling progress meter is "completed"

• There are books that I may not want to read anymore, I did not finish cover to cover

• Perhaps it is a 2-in-1 book and I only wanted to read the first part

• Perhaps there is a lot of back matter

Books in progress will have a non-zero progress meter though, as long as they are not on the first page, and not completed by the user. Formulaically, in progress would systematically fall into the progress meter range of 1-99%.

As a user, when I do not intend to further read a book, I want to move it out of the way

This action should be performable both inside and outside the reading experience. Once a user has this intention, the book should not appear on the home tab of the Kobo app section under Currently Reading, though it still appear in Recently Purchased.

As a user, when I re-enter a completed book, I may not want it to be in progress again

At this point, we do not know what the user’s intention is.

• Do they only want to check something?

• Are they showing someone something?

• Did they accidentally re-enter a completed book?

• Do they want to re-read the book?

If we are going to ask about the user’s intention, it needs to be unobtrusive; It should happen when the user leaves the book.

As a user in the middle of reading, when a book that has a lot of end matter, I want to end the book and mark it completed before reaching 100%

As a user in the middle of reading, when I do not intend to further read a book anymore, I want to mark it as completed and move it out of the way

We recognize the need to figure out how to deal with abandonment; should a book be abandoned, it should not be relegated or denoted under a “state”

As a user, I want to be able to see all the books that I have read/completed

A book is completed even if the user is re-reading the book.

As a user, I want to be able to re-read a book

And know that I am currently re-reading it.

As a user, I want to be able to identify which series I currently have in progress

As a user, I want to be able to identify which series I completed

As a user, I want to be able to identify which series I have not started

Overall, fleshing out the use cases helped tremendously in answering a lot of questions we prepared, but also opened up discussion for other corner cases we had not considered. And while most of these use cases didn’t directly impact the UI design of the Reader Experience, it was important to understand holistically how reading states impacted the user’s overall experience.

Rebuild IA and taxonomy with Open-Card sorting

I took the findings from the benchmarking activities and prepared an open-card sort exercise. I opted for an open-card sort because of the nature of this activity, in having participants label the groups after creating them. While the apps make use of icons to hide away all these features, realistically there are way too many features to cram into one panel without some sort of categorization. The open-card sort will help to further understand the categorization of features. Here are all the features to be included:

I took the labels of each feature, printed each onto an individual post-it note, and conducted a guerrilla-test with some people who weren’t familiar with the project in my office. I asked them to organize topics based on their best understanding of the term, and group similar terms together. I observed them completing this activity; once they decided on the affinities between topics, I asked them to give each of the groups a label. Here were the results:

Here is what I learned from this activity:

• There was a need to categorize the multitude of features within Reading Experience to differentiate between settings that impact the behavior of the reader, and settings that impacted the look & feel

• Users were largely in favor of grouping Annotations, Bookmarks, and Table of Contents together in order to properly navigate to certain sections.

• Users felt that Search was a separate function

Leveraging the insights uncovered from the open-sort, I incorporated the recurring findings to reinforce the decisions on how to construct the new taxonomy and IA that would define the core functions visible to the user in the toolbar of the Reader Experience.

The decision here was to smartly display options that apply to the book on hand. Only specific features/options to tweak the reading experience based on the type of book is shown to the user, in order to unify the UI across all the readers - one of the key goals for the redesign.

EXECUTION & SOLUTION

Primary View and Menu Overlay

With exceptions to FXL/OMF UI components that were designed in Native, all other UI components were redesigned to adhere to the “one reader” model as much as possible. The unified UI now offers users straightforward options for changing settings quickly; applicable options based on the content type now toggle in visibility to provide users options based on the appropriate context.

Book Contents - Standardized navigation UI modules between Search, ToC, Annotation browsing

One particular point of discussion in design involved the “jump-to” feature. This method of navigation is present in Search, ToC, Bookmarks, and Annotation browsing, allowing users to jump to a specific page or a page with specific content. 

As an example, let’s consider the search function. In considering the use case of this feature, under what circumstances is a user using this function? Let’s focus on these specific use cases:

As a user, I would like to search within the current chapter for a keyword or phrase that I remember

As a user, I would like to search within the entire book for a keyword or phrase that I remember

As a user, once I perform a search, I would like to see a list of occurrences of the keyword/phrase

As a user, when I tap a search result, I should be taken to the respective page

When considering these use cases, the common flow is for the user to type in a broad search term, and toggle or cycle through search results in order to confirm whether the section of the book they are seeking is the correct page we provided to them.

The same style of navigation stretches to annotations, bookmarks, and highlights browsing, allowing the user to jump quickly between all their notes and highlights. Without this feature, a user would need to spend a lot more taps to reactivate the toolbar, tap on search or annotation, and enter their search term or browse through their annotation list, then tap on the item in order to jump to that section. 

RETROSPECT

Key Takeaways

• Global design alignment is challenging. Throughout this project, our team in Japan was introducing new features that would steer away from the white-label design which we were synchronizing on every 2 weeks. Both parties recognized the need to include certain features, but the use cases and user flows slightly different, for example.

• I felt there was definitely more that could have been done to further unify the FXL/OMF and RFL reading experiences, had there been less of a development/technology constraint. I was really wanting to iterate on the page scrubber for FXL/OMF, but this was a locked legacy feature.

• Eventually, the “Open Reader” project I was leading prior to joining on for Rakuten Kobo, would be incorporated into the Rakuten Kobo reader as well, slotting in as the web-based reading experience. Given the chance, I would want to revisit the OpenReader project and align the design with Rakuten Kobo as well.

Unfortunately, Rakuten Kobo “Pheonix” was project was shelved after 2 years in development due to substantial organization restructuring. Thanks for reading!