Perlego: A “brief” product critique
Ever been a student?
If you have, chances are you’ve overpaid for textbooks in the past. Perlego provided a solution to this issue, working with over 650 publishers to give subscribers access to over 200,000 academic and professional e-books.
When this “Spotify for textbooks” invited me to their offices in late 2018, they were presented with a comprehensive list of possible improvements to their platform — the result of an extensive product critique.
But how was this completed in less than a week — and what changes were suggested?
Identifying the user
Knowing that user research had already been carried out by Perlego, and accepting that anything I did in a week couldn’t be as detailed or thorough, led to approach different to anything I’d tried before.
Rather than working with hypotheticals, I looked for places where the existing research results had been used. In other words, instead of questioning “what do users need?”, I asked “what does Perlego want its users to know?”
This was answered by “following the money”.
I was able to form a general picture of Perlego’s users by observing who they targeted with subscriptions, and what they were told about the service.
So what were the main concerns and goals of both groups?
Students
- Accessing core textbooks for their course
- Citing books correctly
- The cost of the service
- Reading while “on the go”
Professionals
- Wanting to read what experts in their field recommended
- Expanding their knowledge
- Reading while “on the go”
But most importantly, while both subscription plans offered the same access (although the student was 20% cheaper), the actual content each group wanted was different. Students were more likely to use Perlego for textbooks only, while professionals would probably expect a book “library service”, similar to Kindle Unlimited.
Identifying the problems
What was Perlego like to use for a new user?
I tried it out for a few hours to find out. Then after, with eight pages of categorised notes based on the thoughts and ideas I’d had while using it, attention turned to what I’d spent my time doing.
Most of my time was spent doing three things; reading books, looking for new content or returning to saved content.
The quality of my experience also varied depending on what activity was being carried out. While reading a book was easy enough (and also the area that seemed to have been worked on the most), browsing/discovering new books was by far the most difficult thing to do — and hence what the rest of this article focuses on.
This relatively mediocre experience was due to a number of things, including;
- poor book recommendations (both general and personal),
- subject categories that were too broad,
- no ability to filter or sort results.
Good design wasn’t able to fix all the experience problems I encountered. Some issues, like an algorithm rewrite to give users more suitable book recommendations, could only be solved by developers.
So what could it do?
Improving “My Library”
How do you organise your books? By category? Alphabetically? Date bought? Or do you just not bother?
A quick sweep of social media, as well as responses from student and young professional friends revealed a trend towards two methods; ordering alphabetically (title/author), or by size. But when adding a book from Perlego to your personal collection, users were forced to choose a “list” to add them to — effectively sorting them by category.
While sorting by category was a valid method, it seemed to both work best with larger book collections. But how many books did the average Perlego user have in their library? Was it overkill for users with smaller libraries to have to sort by category?
The model used to save books seemed to be more appropriate for a large bookshop, instead of a small personal collection.
A possible solution was to create a “favourite” section that allowed users to sort their saved books in a way that they wanted (alphabetically, date added etc.), replicating the style of their bookshelf.
However, users could still add books to lists if they wanted to — keeping consistency with the old system, as well as allowing for large collections to be dealt with in the future.
Simplifying a repetitive task
While the changes suggested in the last section were meant to improve the storage and organisation of books in “My Library”, they didn’t answer an important, related question.
How easy was it to actually add books?
The answer was easy — but time consuming. Adding books could get repetitive, and this was magnified with large amounts of books. There was also no way to add books to a list that hadn’t already been created without leaving the search results — an issue that stemed from using the wrong design pattern.
So was there a way to improve this process? I carried out a hierarchical task analysis (HTA) to find out.
The HTA revealed two key things.
Too much clicking to complete one task.
To add a book to the library, users had to select the book (first click), click on “save to library” (second click) and then had to select a reading list (third click).
A fourth click to close the modal window was also required.
A confirmation button that didn’t confirm.
The confirmation button in the process (“save to library”) didn’t represent the end of the user’s task, as a specific list still needed to be chosen afterwards.
Furthermore, this button was pressed after adding each book — adding unnecessary friction into the process.
A confirmation button should signal the end of a task, and only be pressed once.
To solve the excess clicking issue, “save to library” and “add to list” (3.1 and 3.2) could be made into independent tasks, with “favourite” and “add” buttons also being created. Pressing the favourite button would immediately add a book to the favourites section of “My Library” — building on the change proposed in the previous section.
Adding books to a list was slightly more complicated.
Users needed two options — to add to an existing list, or be able to create a new one. An immediate change in the UI (to provide users with instant feedback), presenting these new options, also needed to occur. But while the buttons to confirm (or cancel) adding to a list only needed to be clicked to end the task, selecting books to add to a list was a repeatable action.
My proposal was to create a menu that slid in from the top of the screen, with the possible list options (add to existing or create new) included as radio buttons. As the confirm button only needed to be pressed at the end, multiple books could be added at once — reducing friction and saving time when compared to the current system.
Using the correct design pattern
Perlego used infinite scroll as its design pattern to display browsing results, whether these came from searches or general browsing.
But was this the right choice?
Infinite scroll tends to work best with sites that have users consuming a lot of content, or on sites that want you to view as much of it as possible (e.g. Instagram, YouTube, Forbes). While there are articles that go into greater detail about infinite scroll and its alternatives, the general consensus is that infinite scroll shouldn’t be used for goal based tasks.
The goal of searching is to find an appropriate (or acceptable) result.
My recommended solution was to introduce pagination for search results. This was due to it;
- allowing users to know how far they are through the results, and quickly return to them if necessary,
- generally increasing click through rates (although this would need to be A/B tested for Perlego),
- having less impact on browser memory (therefore increasing computer performance).
We’ve barely scratched the surface…
Believe me, this was brief.
Remember the “comprehensive list” I talked about at the start of this article?
I’ve only talked about 3/26 points on it! There’s still my analysis of the registration process and research on the benefits of eBooks and reading styles (including the book paradox), which in turn have guided my thoughts on Perlego’s eReader.
Check out my portfolio (www.isaacanderson.co.uk) for more of my work!