Mobile Marketplace for Secondhand Books: Users, Journeys and Information Architecture

You are designing a phone app where people can sell books they no longer need and buy secondhand copies from others. Both sides of the trade should be simple. Set the boundaries yourself: decide what the app covers and who its audience is. Break the product into its pieces: the different kinds of users, the actions each of them can take and what each action leads to. Then design the experience end to end for each kind of user, down to what appears on each screen and how a user moves from one screen to the next. Rough wireframes and user flows are expected. ### Clarifying Questions - Are only physical books in scope, or also e-books, audiobooks and book rentals? - Should trades happen through in-person handoffs, shipping, or both? - Does the app take the buyer's payment itself, or only connect the two parties so they settle the payment between themselves? - Is this a new standalone app, or part of an existing marketplace whose accounts and payments it can reuse? ### Part 1 — Scope, audience and user types Define the scope of the first version and the audience it serves. Identify the distinct types of users and choose which of them the first version must serve best. ```hint Not all used books trade alike Compare a course textbook, a paperback novel and a rare first edition: how do price, urgency and how often the same title changes hands differ between them? ``` #### What This Part Should Cover - A stated scope for the first version and what is deliberately left out - User types defined by role (buyer, seller, both, internal operator) and by need - A reasoned choice of the segment to serve first, tied to its pain points ### Part 2 — Actions and user flows For each user type, list the actions they can take and what each action results in: for that user, for the other side of the trade and for the state of the listing. Then walk through the main flows end to end: listing a book, finding and buying one, completing the handoff, and what happens when something goes wrong. ```hint Follow one copy Trace a single book from the moment its owner decides to sell it until the buyer has it in hand. Each change in its state needs an action someone takes and a place in the app where they take it. ``` #### What This Part Should Cover - Actions per user type and their outcomes on both sides of the trade - Complete selling and buying flows, from first open to a finished trade - Exception flows such as cancellations, no-shows and condition disputes ### Part 3 — Screens and information architecture Sketch the key screens: what each one shows, which options appear where, and how the screens link to each other. Show how navigation works for someone who buys, someone who sells and someone who does both. ```hint Decide the top level first Settle on a handful of top-level destinations before drawing any screen. Each flow from Part 2 should then trace a path through them with no dead ends. ``` #### What This Part Should Cover - A small set of top-level destinations and the screens beneath each - The content and the main action of every key screen - How screens connect, including entry points from notifications ### What a Strong Answer Covers - A clear goal and a focused first segment that shape every later choice - Consistency across the parts: every flow can be completed with the screens shown - Trust and safety built into the flows, such as condition grading, verified profiles, ratings and protected payment - A first version prioritized against later additions - Success metrics for both sides of the marketplace, with guardrails ### Follow-up Questions - At launch most buyers will find few listings near them. How do you get enough books listed to make the app useful? - How would you help a seller pick a price for a used copy? - A buyer reports that the book is in worse condition than the listing said. Walk through how the app resolves it.