top of page


A mobile app for buying, selling and requesting books.



  • User Research and Analysis

  • Requirement and Modeling

  • Ideation & Sketching

  • Wireframes and Prototype

  • Evaluation


Timeline : September 21 - December 21

Team Members : 3


To minimize frustration, to allow users to feel they are getting good deals on books, and to feel comfortable doing so.

Product Definition

Librum is an app that connects users who want to buy/sell books in their local area. Librum allows users to post books for sale/giveaway; to search for given titles in their area to buy/pick up; to browse books listed for sale/giveaway in their area; to see reviews from previous readers; to give each other ratings after transactions, and to make public requests for specific books and browse the local list of requested books. Librum addresses four primary problems.

Potential users:
A. Have books they want to sell.
B. Want to buy specific books and browse locally available books.
C. Want to read reviews for books before they buy.
D. Need to be able to ask for specific books that are not easy to find or cheaply available.



We interviewed a total of 11 users, some of them in-person and some via zoom. We specifically tailored the questionnaire to probe users for information about their own book reading/owning habits to establish their suitability as part of our target audience, what services they currently use, what they like and dislike about those services, and how they felt about our proposed feature sets. After the interviews, raw work activity data was created by collating data from the interviews. 

In total, we created 38 Work Activity Notes after refining the raw user data and eliminating redundancies/duplicates.


We gained a great deal of other useful insight from our research, which we summarized into Work Activity Notes and sorted on the WAAD. 

Work activity affinity diagram


The major user roles of our application are Seller and Buyer. The Seller performs tasks like adding product description, posting listings of the books for sale, contacting the buyer etc. The Buyer performs tasks like rating the seller, contacting the seller, exploring the products page, using filters for searching, posting a request to buy, posting the requirement of any book etc.

User Role Model


Flow Model

The aim of the analysis phase is to draw insights from data collected during the research phase, moving from “what” users want/think/need to “why” they want/think/need it.


We had honed two of our existing personas into characters that also fell roughly along work-role lines: one “buyer” and one “seller,” that is, one user who primarily uses Librum when looking for books for themselves and another who mainly is using Librum to offload excess and unwanted books they had at home. 



The Buyer is a class of user-focused on purchasing or acquiring books. The Buyer is interested in buying books and is willing to spend money if they get a good deal. Buyer is interested in getting their hands on new books, and will generally use a variety of app features to find specific books and browse general categories. They are almost certainly our largest class of users.



The Seller is a class of user-focused on selling books that they already have. Much as the Buyer uses the search and browse functions to find existing items they want to buy, the Seller may use those same functions to determine whether the books they have are very common, rare, or not yet available. This can help Sellers prioritize what they want to post and spend the most time on. Similarly, Sellers can search the feed for books that have been specifically requested in the area, and determine if they have any of the posted books. When posting books for sale, the Seller will enter basic information such as title, author and generally will add other information as well. 




Due to some of the team being remote, we talked about project direction initially before deciding to have each team member provide some sketches of screens we established needed to exist for feature completeness. We then compared sketches before moving forward with design elements from some that we liked. 



We designed a storyboard 


We designed lo-fi wireframes based on the scenario shown in our storyboard. Our app uses a variety of transitions between wireframes. We use parent-child “zooming” transitions e.g. when a user opens an image in a listing and it enlarges, or when tapping a particular product listing, or when opening a settings menu. We use top-level transitions for flipping between major screens using the bottom-aligned navigation panel, and sibling transitions when e.g. flipping through multiple photos of a book. 


Post a book for Sale

Performing Filtered Search

Post a Request

Contact Seller about Listing

Validation (Testing)

Our pilot testing was done on a very tight timetable, and as a result we were able to test only three participants, one per group member. Nonetheless, they provided us with a great deal of vital feedback, as we suspected, and a number of changes were implemented in the prototype based on that feedback. In fact, the timetable was short enough that we were not able to address (or fully address) all concerns brought up in pilot testing, so we prioritized what we deemed the most important issues to be addressed first.


Participant feedback was collated in a Google Sheets doc, with each participant being on a separate page. Participant feedback was listed by page and task so that we could be sure that the correct screen was being viewed during review. There were a great number of small issues mentioned in testing, including too many small typographic, graphic, and intuitive-design changes to easily list. Without creating an exhaustive list, we will detail some of the major criticisms and changes below. If a specific change is not listed, that can be read as an issue that was simply “fixed.”

Inconsistent design

Several screens designed by different people on our team did not contain common elements that should be shared between all screens.


Additional background detail

Some of our prototype screens had repeated images or text as placeholders that pilot users found frustrating even knowing that it was a test. This was addressed by differentiating and adding images and text. Another example was that the filter screen initially took users back out to the initial search screen, not showing a difference between that and the new, filtered search. This was addressed with the addition of a new screen that showed different results after filters had been applied.

Absent intuitive features/present unintuitive features

A number of options (mostly buttons) were added to tasks when users said they felt like they should have been able to do something on a given screen (such as “Contact the Seller” not being a “sticky” button on a screen where it seemed like it should be.)  One screen had an option for phone and video calls between buyer and seller that was removed after one pilot user expressed surprise and overwhelm at the options. In another, a user was confused because a post was shown to have “Comments” and “Shares” next to it and that confused the user about the app’s feature-set.

Visual issues

One issue that was repeatedly brought up was that several low-profile white and grey buttons looked “disabled” to users. More defined black borders were added in each case to make the buttons more clearly “active.” In other places, descriptions were added to certain books where it looked like there should be some. Some users also complained that some features looked as if they had been pulled from other apps, like Facebook/Facebook Messenger. These features were edited to differentiate them. There were also many small alignment and detail sizing and placement changes made based on feedback.



bottom of page