Shelf is a social app for borrowing and lending books amongst your community. It keeps track of who is currently borrowing your books (and what books you're borrowing); shows short book reviews from friends; and lets you create wish lists so that you can get notifications if a book you want to read is newly listed or available.

The goal of Shelf is to introduce a social element to literacy, promote reusing & recycling, and create an opportunity for community-building and community sharing.

In short, there is no social app or website that lets you borrow/lend books with friends.

I surveyed 5 people ages 23 to 65, ranging from casual or occasional readers to avid readers, but mostly focusing on moderate to avid readers. From the 5 people surveyed, some common themes are outlined below (where p1, p2, etc. are the people surveyed):

I then followed up on a few surveys with casual 1:1 interviews. Some overall takeaways:

• Most people get book suggestions from having conversations with friends. Some people look at Amazon's best-selling books to get ideas, but others had very specific book lists that they trusted (for example, specific staff members on McNally Jackson's Staff Picks).
• Most people will specifically go to Amazon or Goodreads to read reviews even after they get suggestions from friends.
• People find it awkward to ask someone to return a book they borrowed. One person said they found it as an opportunity to be able to meet back up with their friend and discuss the book.
• People own a lot of books they haven't actually read.

Based on the user interviews, I created two main user personas centered around book borrowing and general book purchasing habits:

In short, we want to accommodate users who want to quickly use Shelf as a search tool to find a book, and users who want to browse leisurely to discover new books or see what their friends are reading or reviewing.

To figure out all of the features that would be useful to our users, I wrote down pain points on sticky notes and brainstormed features that would help to solve those pain points.

A few feature ideas that resulted from the brainstorm session:

1. Have a chat function so that users can arrange to meet up or ask questions about a book.
2. Have a feature where users can send recommendations to their friends (either a book they own or not).
3. Have a global rating system for each book listed so that people don't have to leave to read Amazon's reviews.
4. Have an automatic system notification set for x amount of time to remind users to either return the book or continue reading, to absolve responsibility and awkwardness from the book owner.
5. Have a scan function so that users can easily upload many books without having to manually enter the author or book name.

Requesting a book:

{} = system options, [] = user actions

The next step was to create a basic flow diagram of all of the screens that would encompass our app and the relationships between screens.

What should the dashboard look like to appeal to both user personas?

At the top, we have an at-a-glance summary of the user's current books that are borrowed or being borrowed. There's also a CTA for the user to add a book listing, and a "Suggested For You" section, directly influenced by Elodie's pain point of feeling overwhelmed with authors she doesn't know.

Further down, there's a friend feed to show the most recent activity from friends, like what book they just listed or borrowed, directly influenced by Ricardo's desire to leisurely browse the app and see what friends has read what book.

The navigation at the bottom has options of navigating to the search page, messages, and their own profile.

To add a book to be borrowed, a dialog shows an input with autosearch, or the option to use your phone's camera to scan a book barcode. Once the user confirms by clicking on the correct book that is shown based on their search results or book scan, they have the option to rate and add a review to the book that will show up on their profile.

This rating is optional because 1) we don't want users to get hung up on writing something -- they can always add in a review later, and 2) according to our user interviews, people own a lot of books they don't actually read, so some people might not have read the book they're listing.

Once the book listing is confirmed, the user is taken to their profile page, which shows the listed book as the first book on their profile.

After the user searches for a book, they are taken to the book page. Because of the user interviews showing that most people want to read reviews, a global review rating is shown, as well as a friend review rating, so that they can see both.

The book page displays all of the friends who have the book listed and the current status (borrowed, available, etc.) and if available, the user can easily request by clicking the "Request" button.

The request button then autopopulates a message to the friend that is modifiable before sending.

The user can either search for a friend's name or go to their profile page to see a list of friends.

On a friend's profile page, their list of books are shown, which can be sorted by availability, user rating, global rating, or recently listed; or filtered by genre or rating.

After all of the sketches were finalized and explored and I got user feedback on wording (List a book? Add a book?), I created the wireframes. This process helped me see the entire scope of the project and play around with layout, although you'll see in the next section that the layout changes after a couple of rounds of edits.

When wireframing the dashboard page, adding the Activity Feed started to look like an overwhelming amount of content; the Recent Activity feed distracted from the more pertinent features, such as borrowed / borrowing books. Also, people are used to activity feeds being in a separate menu tab (Instagram, Twitter, etc.), so their mental models of social media apps may expect the Activity feed to be in a separate tab anyway.

Therefore, I decided to abstract the Activity Feed and add it as a separate tab in the menu, rather than on the dashboard.

I decided to create a high-fidelity prototype using InVision in order to make the usability testing participants feel like they are using a real app.

In my experience, when presenting low-fidelity wireframes and prototypes to clients or internal stakeholders, I've found that not everyone can take the mental leap of imagining low-fidelity designs as a real product, which is why I think the usability testing prototypes should have some level of believability with fidelity.

I didn't spend a ton of time here because the purpose was not to focus on the visual design elements, but rather the functionality, layout, and flow.

I created a script and conducted usability testing one just one person for 3 different scenarios: (1) listing a book, (2) finding a particular book, and (3) finding a particular book knowing your friend purchased it a few months ago.

Despite testing on only one person, I got some great insights into how I could improve the final design. The most impactful takeaways are listed in the insights table below:

At the end of the session, I asked the participant if they had any questions or comments on anything they just did, and got even more great feedback:

The book page displays a large cover image with most of the content showing as you scroll further down. Here, you can see that the availability is shown along with the number of miles away that the lister lives from the user, a direct feature from the usability tests.

There are options to request the book, add the book to their wishlist, read more reviews of the book, and browse other similar books.

There's also an option to share the listing, which opens up a bottom modal that shows the top people interacted within the app, along with a search button and other ways to share the link.

Initially, I created the wireframes and high-fidelity wireframes in Sketch and then exported them to create the Invision prototype that I used for usability testing, but after redoing the UI design and wanting more robust prototyping features for the next usability testing session, I should have just done everything within Figma.

Overall, I'm happy at how this project turned out. The next step is to do more user testing on the new design!