Sprint 1 Deliverable - Moviles-G23-20262/General-Wiki GitHub Wiki
0. Ethical Video
1. Description of the problem and the proposed solution
Selected Problem
In university communities there is a massive waste of academic resources. Students frequently buy materials like textbooks, calculators, lab equipment, design tools; for a single course and never use them again once it ends, so items pile up in bedrooms or get thrown away. At the same time, other students in the same institution need those exact items for courses they are currently taking.
Today this exchange happens through disorganized, informal channels: Facebook Marketplace, WhatsApp groups, MercadoLibre; that are unorganized, open to non-students, and give buyers no reliable way to verify whether an item matches the exact edition or condition their course actually requires. This creates friction on both sides: sellers give up trying to find a buyer and let items go to waste, while buyers waste time scrolling through irrelevant posts, hesitate to commit to purchases they can't verify, and often default to buying new out of distrust, even when a used option would be cheaper and just as good.
Our user research (interviews and empathy maps with students such as Isabella, Maria, Valentina, Mateo, and Camilo) validated this across both sides of the transaction: sellers waste time answering repetitive questions from non-serious buyers and worry about sharing personal contact information; buyers treat every purchase as a manual research task, cross-referencing tabs and screening seller history because no shared trust standard exists.
Proposed Solution
CampusSwap is a peer-to-peer marketplace restricted to verified students of Universidad de los Andes, built to turn wasted academic materials into a trustworthy, organized, course-specific exchange for books, calculators, lab equipment, and design tools.
The solution is organized around three core fronts, drawn directly from our personas and Context Canvas:
- Course-specific search. Listings are filtered by faculty, degree, and course code, so students find exactly what their syllabus requires instead of scrolling through irrelevant posts.
- Trust and safety. Access is gated by institutional email (OAuth with the University Identity Provider), every listing requires real photos and a condition tag, and both sides rate each other after the exchange.
- Privacy and safe coordination. Buyers and sellers negotiate through in-app messaging — never exposing a personal phone number — and agree on a pre-mapped, safe, on-campus meeting point for the handoff.
On top of this core, smart features differentiate the product further: an AI price suggestion that proposes a fair price range from a photo of the item, and smart matching that notifies a student when a new listing matches their wishlist or current courses. Payments always stay outside the platform; the exchange happens in person on campus, so CampusSwap never stores payment credentials.
Revenue Model
Because payments are intentionally kept off-platform (in-person, cash or peer-to-peer transfer, for trust and safety reasons), CampusSwap cannot monetize through transaction fees or payment processing. The proposed model is therefore freemium, monetizing visibility and convenience rather than the exchange itself:
- Free core experience: publishing listings, course-based search, in-app messaging, ratings, and meeting-point coordination remain free for all verified students; this protects adoption and trust, which are the platform's main value drivers.
- Boosted/featured listings: sellers under time pressure (e.g., graduating students like Camilo) can pay a small fee to promote a listing or bundle to the top of search results and category pages for a limited time.
- Premium seller tools: an optional subscription for frequent sellers (e.g., Mateo) offering advanced analytics on their own listings (views, contact rate), unlimited AI price suggestions, and priority placement in smart-matching notifications.
- Institutional partnerships: potential future revenue from partnering with the university (e.g., co-sponsored sustainability initiatives, bookstore buy-back integration) rather than charging students directly, aligned with the platform's non-profit, community-first positioning.
Value Proposition
For university students who need affordable, specific academic materials and want to responsibly get rid of the ones they no longer use, CampusSwap is a peer-to-peer marketplace exclusive to verified students that makes buying and selling academic materials organized, trustworthy, and course-specific, unlike general marketplaces or informal WhatsApp groups, which are disorganized, open to non-students, and offer no way to verify condition or edition.
CampusSwap gives:
- Buyers (Maria, Valentina) confidence to purchase used items through verified sellers, structured condition proof, and course/edition-specific filtering, replacing manual, tab-by-tab research with a single trustworthy view.
- Sellers (Isabella, Mateo, Camilo) a fast, privacy-preserving way to reach the exact students who need their items, without the inefficiency and repetitive back-and-forth of WhatsApp groups.
- The university community a more sustainable, lower-waste ecosystem for academic materials, with data (Section 5 & 7) that lets the platform continuously validate and improve trust, pricing, and matching over time.
2. Problems–Alternatives–Solutions (PAS) Hypotheses
PAS 1: Unused materials with no organized resale channel
| Section | Content |
|---|---|
| Problem | Students (e.g., Isabella) accumulate academic materials they no longer use, calculators, books and have no easy, organized way to resell them within their own community, so items pile up or get thrown away. |
| Alternatives | Today, students post their unused items in faculty WhatsApp groups or on Facebook Marketplace. When no one replies within a few days, they give up and the items stay stored or are eventually discarded. |
| Solution Statement | CampusSwap lets students publish listings categorized by faculty, degree, and course, so unused items reach the exact students who need them. |
| Top Features | Isabella (seller/buyer): "I want to publish an item with my program tagged so that I can reach students who actually need it." Interaction: create listing, select category/program. |
| App similar apps / what's different | Similar to Facebook Marketplace / WhatsApp groups, but scoped exclusively to one university and organized by academic taxonomy (faculty → degree → course) instead of a flat, chronological feed. |
| App info that stays on the phone | Draft listings in progress, locally cached photos before upload, user's session/login token. |
| App info queried from the phone | Listing category filters selected by the user, item photos to upload, GPS/campus location (optional) for meeting point suggestion. |
| Backend Services | Listing Service stores and indexes items by faculty/degree/course; Type of interface: REST API. Publish events also flow into the Interaction Event Log DB, which is the primary source for Business Question 6 (which categories generate the most listings/completed exchanges) and Question 2 (listings opened per buyer). |
| Environmental Conditions | Campus Wi-Fi/data connectivity; peak usage around start/end of semester when materials change hands most. |
| Constraints | Categories must map to the university's official academic structure; photo uploads limited by mobile data/storage. Publishing and browsing remain part of the free core tier under the freemium revenue model, since they are the platform's main adoption and trust drivers. |
PAS 2: Buyers distrust used items with no proof of condition
| Section | Content |
|---|---|
| Problem | Buyers (e.g., Isabella's classmates) prefer paying more for new items over used ones because there is no reliable way to verify an item's condition before buying. |
| Alternatives | Buyers currently ask sellers for additional photos over WhatsApp and judge condition from low-quality images, or they avoid the risk entirely and buy new. |
| Solution Statement | Require sellers to attach condition tags (New/Good/Fair/Damaged) and real photos to every listing, giving buyers visual proof before committing. |
| Top Features | Isabella (seller): "Given that I'm listing a used book, I want to add a condition tag and photos so that I can build buyer trust without extra back-and-forth." |
| App similar apps / what's different | Unlike informal WhatsApp posts with vague descriptions ("good shape"), listings enforce structured condition metadata — the structured condition proof promised to buyers in the value proposition. |
| App info that stays on the phone | Locally cached uploaded images before confirmation. |
| App info queried from the phone | Camera access for condition photos. |
| Backend Services | Media Storage Service stores and serves listing photos; Type of interface: REST API / object storage (S3-like). |
| Environmental Conditions | Variable phone camera quality across students; lighting conditions when photographing items. |
| Constraints | Minimum photo count/resolution to be enforced; storage cost scales with number of listings. An image-labeling data source (photo angle, close-up, damage) is not yet available, so today the system can only count photos per listing, not classify what they show — Business Question 3 can only be answered partially until that labeling pipeline exists. |
PAS 3: Buyers manually cross-reference listings and sellers across tabs
| Section | Content |
|---|---|
| Problem | Repeat buyers (e.g., Maria) must manually open multiple tabs to compare price, quality, and seller reputation, since no platform consolidates this. |
| Alternatives | Repeat buyers keep several Marketplace tabs and WhatsApp screenshots open at the same time, comparing price, condition and seller reputation manually across platforms. |
| Solution Statement | Provide a single search/comparison view showing price, condition, and seller rating side by side for matching listings. |
| Top Features | Maria (buyer): "I want to see price, condition, and seller rating together in one view so that I can decide without opening multiple tabs." |
| App similar apps / what's different | Similar to e-commerce comparison filters (MercadoLibre-style), but scoped to verified university sellers only. |
| App info that stays on the phone | Recently viewed listings (for quick comparison) cached locally. |
| App info queried from the phone | Search/filter parameters entered by the user. |
| Backend Services | Search & Ranking Service — indexes listings and returns ranked/comparable results; Type of interface: REST/GraphQL API. |
| Environmental Conditions | Search volume spikes at semester start, when traffic can grow by an order of magnitude; needs to perform well on campus Wi-Fi without degrading response times. |
| Constraints | Ranking algorithm must avoid bias toward paying/sponsored sellers; response time must stay low for a good UX. This constraint is now concrete rather than hypothetical, since the revenue model introduces paid boosted/featured listings — ranking logic must clearly separate organic relevance from paid placement so Maria's comparison view stays trustworthy. |
PAS 4: No shared trust/reputation standard across sellers
| Section | Content |
|---|---|
| Problem | Maria has no reliable way to verify a seller's real reputation; reputation signals are inconsistent or absent, so she treats every purchase as a research task. |
| Alternatives | Buyers assess trust using indirect signals: how old the seller's profile is, how many mutual friends they share, or asking classmates whether they know the person. |
| Solution Statement | Implement a two-way rating and review system where both buyers and sellers rate each other after every transaction, visible on profiles. |
| Top Features | Maria (buyer): "I want to see a seller's rating, number of sales, and response speed so that I can trust them before messaging." |
| App similar apps / what's different | Similar to Airbnb/Uber's bidirectional rating systems, adapted to a peer-to-peer academic marketplace. |
| App info that stays on the phone | Cached rating summaries for recently viewed sellers (offline glance). |
| App info queried from the phone | User's rating submission (stars + comment) after a completed transaction. |
| Backend Services | Reputation Service — aggregates ratings, computes seller/buyer scores; Type of interface: REST API. This is also the primary data source for automated scam-pattern detection, a stated need of the analytics persona (Jesús Lievano), who currently has to flag suspicious accounts manually with no anomaly-detection dashboard. Reputation Service events should feed the same event log the rest of the analytics questions rely on. |
| Environmental Conditions | Requires enough completed transactions to generate meaningful scores (cold-start problem for new users). |
| Constraints | Ratings must be tied to verified completed transactions to prevent fake reviews; new sellers start with no history. |
PAS 5: Uncertainty about exact textbook edition required
| Section | Content |
|---|---|
| Problem | Budget-conscious first-years (e.g., Valentina) risk buying the wrong textbook edition, since informal listings rarely specify whether it matches the current syllabus. |
| Alternatives | Buyers compare the listing's cover photo against the publisher's website, or ask the seller to photograph the copyright page to confirm the edition. |
| Solution Statement | Link listings directly to specific course codes and required editions, pulled from a course-materials reference list. |
| Top Features | Valentina (buyer): "I want to filter listings by exact course code and edition so that I can avoid buying outdated material." |
| App similar apps / what's different | Unlike Facebook groups with free-text titles, listings are structured against a course/edition taxonomy. |
| App info that stays on the phone | Selected course/edition filter for the current session. |
| App info queried from the phone | None beyond standard filter selection (no sensor use). |
| Backend Services | Course Catalog Service maps courses to required materials/editions; Type of interface: REST API. |
| Environmental Conditions | Depends on the university keeping an updated syllabus/course-materials reference; changes each semester. |
| Constraints | Course catalog must be refreshed every semester; mismatches between professor-required editions and the catalog could mislead buyers. This is the riskiest dependency in the product: the university course catalog with ISBN/edition data is not something we currently have access to, and the AI price estimation service (PAS 11) depends on it as well. If access is never granted, the fallback is building our own catalog bottom-up from student-submitted listings, which is slower and noisier. |
PAS 6: Fear of scams when paying upfront to strangers
| Section | Content |
|---|---|
| Problem | First-year buyers (e.g., Valentina) are nervous about transferring money to unknown sellers before seeing the item in person. |
| Alternatives | Buyers limit themselves to sellers recommended by a friend, or require meeting in a public place and paying in cash instead of transferring money in advance. |
| Solution Statement | Restrict the platform to verified institutional accounts and recommend safe, on-campus meeting points for in-person exchange instead of remote payment. |
| Top Features | Valentina (buyer): "I want to only interact with verified university students and meet in a safe campus spot so that I can avoid being scammed." |
| App similar apps / what's different | Unlike general marketplaces open to the public, access is gated by institutional email verification, specifically the @uniandes.edu.co domain. |
| App info that stays on the phone | Verified session token; no payment credentials are stored (payments happen off-platform, in person). |
| App info queried from the phone | Institutional email for verification (one-time), optional location for meeting-point suggestions. |
| Backend Services | Authentication & Verification Service validates institutional email and manages sessions; Type of interface: REST API / OAuth-like flow. |
| Environmental Conditions | Requires access to the university's email domain for verification; campus locations must be pre-mapped for meeting-point suggestions. |
| Constraints | Verification must not store sensitive credentials; meeting-point suggestions limited to public, safe campus zones. No in-app payment gateway should be introduced anywhere in this flow — trust here comes entirely from identity verification plus in-person exchange, never from a payment product. |
PAS 7: Listings get buried in disorganized WhatsApp groups
| Section | Content |
|---|---|
| Problem | Frequent sellers (e.g., Mateo) drop items into large WhatsApp groups where messages get buried under unrelated chatter within minutes. |
| Alternatives | Sellers repost the same item every few days so it is not buried in the group chat, or contact individually the students they know are taking the course. |
| Solution Statement | Provide a persistent, searchable listing feed that doesn't disappear over time, replacing chat-based selling. |
| Top Features | Mateo (seller): "I want my listing to stay visible and searchable so that I don't have to repost it multiple times." |
| App similar apps / what's different | Unlike chat apps, listings persist until sold/removed and are indexed for search — a core marketplace behavior WhatsApp groups lack. |
| App info that stays on the phone | Draft/unsaved listing text before publishing. |
| App info queried from the phone | Listing text/photos entered by the seller. |
| Backend Services | Listing Service (shared with PAS 1) persists and indexes active listings; Type of interface: REST API. |
| Environmental Conditions | High listing turnover expected around start/end of semester. |
| Constraints | Old/sold listings must be archived or removed to keep the feed relevant; posting must be fast (under 2 minutes per Mateo's expectation). Auto-archiving unsold listings after a time window directly answers the business question of which listings never sell, how long they stay active, and what they have in common, using a survival-curve analysis fed by the same listing and event data. |
PAS 8: Privacy concerns from sharing personal contact info
| Section | Content |
|---|---|
| Problem | Sellers (e.g., Mateo) must share their personal phone number in open group chats to close a sale, raising privacy concerns. |
| Alternatives | Sellers use a secondary phone number for transactions, or restrict their sales to people already in their social circle. |
| Solution Statement | Provide in-app messaging so buyers and sellers can coordinate without exchanging personal phone numbers. |
| Top Features | Mateo (seller): "I want to message a buyer inside the app so that I don't have to share my personal number." |
| App similar apps / what's different | Similar to marketplace-native chat (e.g., Facebook Marketplace messaging), scoped to verified university accounts only. |
| App info that stays on the phone | Cached recent conversation threads for offline viewing. |
| App info queried from the phone | Push-notification permission for new messages. |
| Backend Services | Messaging Service — real time chat between buyer and seller; Type of interface: WebSocket / real time API. Thread data feeds the business question of how many messages are exchanged and how long it takes to reach agreement on a meeting point, computed by aggregating each thread up to its meeting confirmation. |
| Environmental Conditions | Requires stable connectivity for real time delivery; must degrade gracefully on poor campus Wi-Fi, queuing messages locally and syncing once connectivity returns. |
| Constraints | No personal contact info should be exposed through the chat by default; message history must be retrievable across devices. |
PAS 9: Bulk sellers under time pressure can't bundle items
| Section | Content |
|---|---|
| Problem | Graduating students (e.g., Camilo) need to sell many items quickly before a move-out deadline but have no efficient way to bundle related items into one listing. |
| Alternatives | Bulk sellers publish a single photo of all their items in a group chat with one combined price, and then answer the same questions individually for each interested buyer. |
| Solution Statement | Allow sellers to create multi-item bundle listings with a combined price and discount. |
| Top Features | Camilo (seller): "I want to bundle several related items into one listing so that I can sell them together quickly before I move out." |
| App similar apps / what's different | Unlike single-item listings on most marketplaces, bundles let a seller offload multiple related items in one transaction. |
| App info that stays on the phone | Draft bundle composition (items selected) before publishing. |
| App info queried from the phone | Photos and details for each bundled item. |
| Backend Services | Listing Service (extended) supports grouped/bundled item records; Type of interface: REST API. |
| Environmental Conditions | Time-pressured selling window (e.g., two weeks before lease ends). |
| Constraints | Bundle pricing logic must be simple enough not to slow down a fast listing flow; bundles must still be searchable by individual item. This is also the feature that directly generates revenue: a time-pressured seller like Camilo can pay a small fee to promote his bundle to the top of search results, so the bundling and boosting flows should be designed together as a single fast add-on rather than two separate steps. |
PAS 10: Unreliable buyers reschedule pickups at the last minute
| Section | Content |
|---|---|
| Problem | Sellers under time pressure (e.g., Camilo) lose time and money when buyers reschedule or fail to show up for agreed pickup times. |
| Alternatives | Sellers reconfirm the meeting over WhatsApp the same morning, or only accept buyers who contacted them through a group they recognize. |
| Solution Statement | Suggest and coordinate concrete on-campus meeting points and times directly in-app, with confirmations from both parties. |
| Top Features | Camilo (seller): "I want to confirm a specific pickup time and place with a buyer inside the app so that I can reduce no-shows." |
| App similar apps / what's different | Similar to ride-hailing pickup confirmation flows, adapted to peer-to-peer item handoff on campus. |
| App info that stays on the phone | Locally stored upcoming meeting confirmations (for offline reference). |
| App info queried from the phone | Optional real-time location to suggest nearby meeting points. |
| Backend Services | Meeting Coordination Service — recommends and confirms on-campus exchange points/times; Type of interface: REST API. Confirmation events populate the meeting coordination data used, together with the messaging data, to compute time-to-agreement metrics. |
| Environmental Conditions | Depends on a pre-loaded map of safe, recognizable campus locations. |
| Constraints | Meeting points must be restricted to public, well-known campus areas; scheduling conflicts (class times) should be considered. This confirmation is strictly about time and place, never about money, since payment always stays off-platform. |
PAS 11: Sellers don't know how to price their items fairly
| Section | Content |
|---|---|
| Problem | Sellers across personas (Isabella, Mateo) are unsure how to price used academic items competitively, leading to overpricing (no buyers) or underpricing (lost value). |
| Alternatives | Sellers search for similar items on MercadoLibre and Facebook Marketplace, estimate an average from the asking prices they find, and set the price by intuition. |
| Solution Statement | Offer an AI-assisted price suggestion: the seller uploads a photo of the item, and image recognition + comparison with similar listings suggests a fair price range. |
| Top Features | Mateo (seller): "I want the app to suggest a price based on a photo of my item so that I don't have to guess its value." |
| App similar apps / what's different | A smart differentiator not offered by informal channels or basic marketplaces. |
| App info that stays on the phone | Photo taken for price estimation until upload completes. |
| App info queried from the phone | Camera access to capture the item photo. |
| Backend Services | AI Price Estimation Service — interprets item photos and cross-references similar listings to suggest a price; Type of interface: REST API (image upload → JSON price suggestion). Its training data comes directly from the business question of how prices for the same item vary by seller, faculty, and condition — the resulting fair-price range is fed straight back into this service. |
| Environmental Conditions | Requires a growing dataset of past listings/prices to improve suggestion accuracy over time. Accurate comps for a specific edition also depend on the same university course catalog access flagged as a risk in PAS 5. |
| Constraints | Suggested price is advisory only (seller sets final price); model accuracy depends on image quality and available comparable listings. Under the freemium revenue model, unlimited AI price suggestions is a paid premium seller perk, so the free tier must cap how many suggestions a seller like Mateo can request per listing or per month. |
PAS 12: Students miss relevant listings buried among irrelevant ones
| Section | Content |
|---|---|
| Problem | Students only occasionally check the marketplace and miss new listings that match what they actually need, since nothing proactively notifies them. |
| Alternatives | Buyers stay in several WhatsApp groups and scroll them regularly, and ask classmates to notify them if a relevant item appears. |
| Solution Statement | Implement smart matching: automatically notify a student when a new listing matches their wishlist, degree, or current-semester courses. |
| Top Features | Isabella / Valentina (buyer): "I want to be notified when an item matching my program or wishlist is posted so that I don't have to keep checking manually." |
| App similar apps / what's different | A smart-feature layer on top of the core categorized-listing experience, similar to wishlist-alert features in e-commerce apps. |
| App info that stays on the phone | Push-notification tokens; locally cached wishlist for quick access. |
| App info queried from the phone | Notification permission; user's saved wishlist and degree/semester profile data. |
| Backend Services | Smart Matching Service compares new listings against saved wishlists/profiles and triggers notifications; Type of interface: REST API + push-notification gateway. Match and notification events directly answer the business question of how many saved wishlist items convert to a purchase after a notification, measured in a short attribution window after each match. |
| Environmental Conditions | Depends on notification delivery reliability (OS-level push service); listing volume must be high enough to make matching valuable. |
| Constraints | Over-notifying could annoy users — matching must be precise; requires up-to-date user profile data (degree/semester) to work well. Under the revenue model, premium sellers get priority placement in smart-matching notifications, so the matching algorithm needs a clear tie-breaking rule for when a free listing and a paid-priority listing both match the same buyer, to avoid a lower-relevance paid match crowding out a better free match and hurting conversion. |
3. Context Canvas
4. Personas
Prospective Persona 1: The Cost-Conscious Academic
Prospective Persona 2: The Academic Recycler
Prospective Persona 3: The Conscious Declutterer
Prospective Persona 4: The Cautious Newcomer
Analytics Persona: Product Manager
5. Empathy Maps
Empathy Map 1 — Isabella
Made by: Daniel Diab
1. Who are we empathizing with?
Isabella, 22, Audiovisual Communication student at Universidad de La Sabana. Owns unused course materials (calculator, books); has bought and sold secondhand academic items with mixed success. Her role spans both sides of the marketplace — she has things to sell and also buys occasionally.
2. What does she need to DO?
- Decide what to do with materials she no longer uses instead of letting them pile up in her room.
- Find real buyers for niche used items (e.g. language textbooks), without relying only on classmates.
- Trust an item's condition before buying it, without seeing it in person.
- Quickly filter listings relevant to her program, avoiding noise from other majors.
- Success looks like: selling what she doesn't use without extra effort, and buying secondhand with the same confidence as buying new.
3. What does she SEE?
- Her unused Introduction to Economics calculator sitting in her room.
- Informal, disorganized channels with no categories by academic program.
- Classmates who'd rather pay more for a new book than buy a used one with no guarantees.
- No photos or clear evidence of condition in the few secondhand listings she comes across.
4. What does she SAY?
- "It's just laying around in my bedroom." (about her calculator)
- "I usually just get things from my siblings."
- "The condition needs to be really clear — new, old, or stained."
- "I tried to sell my French book but nobody wanted the used one."
5. What does she DO?
- Buys a calculator for class, barely uses it, and defaults to her phone's calculator app instead.
- Relies on hand-me-downs from her siblings instead of searching among strangers.
- Attempts to sell a used book directly to classmates who need it.
- Imagines an ideal platform with condition tags and program-based categories.
6. What does she HEAR?
- Classmates saying they'd rather buy new "just in case" when there's no way to verify a used item's condition.
- Her siblings mentioning what materials they already have available before she buys anything new.
- Scattered comments from other students about how hard it is to find something specific to their major among posts from other programs.
- Little to no mention of a trustworthy secondhand platform within the university — the option barely comes up.
7. What does she THINK and FEEL?
| PAINS | GAINS |
|---|---|
| Ends up with unused materials taking up space with no easy resale channel. | Already has a family network that solves part of her sourcing needs, she knows the value of easy access. |
| Buyers prefer brand-new over used when trust/condition isn't clearly established. | Would adopt a platform that gives visual proof of condition and filters by program. |
| No categorization by academic program, browsing is inefficient and frustrating. | Feels optimistic and engaged when picturing a more organized, trustworthy system. |
Additional thoughts and feelings: Mildly frustrated about money spent on something redundant (the calculator); comfortable and low-stress when the source is family; disappointed and a little discouraged after failing to sell the French book.
Empathy Map 2 — Maria
Made by: Daniel Diab
1. Who are we empathizing with?
Maria, university student at Universidad de los Andes, a frequent online buyer who treats every marketplace purchase as a comparison exercise. Her role is that of a repeat, experience-hardened buyer who demands proof before committing to a purchase.
2. What does she need to DO?
- Compare price, quality, and delivery conditions across multiple listings without manually opening and cross-referencing every tab.
- Verify a seller's real reputation before messaging or paying.
- Spot red flags (new sellers, suspiciously low prices, photos that don't match reality) before wasting time or money.
- Success looks like: deciding with confidence without having to do the verification work the platform should already provide.
3. What does she SEE?
- Multiple open tabs with different listings she has to compare manually.
- Seller profiles with inconsistent history — some new, some with few reviews.
- Product photos that, in the past, didn't match what she actually received.
- Very low prices with no supporting information behind them.
4. What does she SAY?
- "I open a bunch of listings at once to compare them."
- "The first thing I check is the seller's reputation."
- "I've been burned by photos that don't match what showed up."
- "I want to see number of sales, response speed, and reviews — not just the price."
5. What does she DO?
- Keeps multiple tabs open, manually cross-referencing price, quality, and delivery conditions across listings.
- Screens seller profiles for history, activity, and prior reviews before messaging.
- Discards listings from new, low-activity, or suspiciously cheap sellers.
- Has messaged sellers directly to verify details when descriptions or photos feel incomplete.
6. What does she HEAR?
- Other buyers' stories of being scammed or receiving items that didn't match what was advertised.
- Informal advice to "check the profile carefully before buying from someone."
- Complaints that current platforms don't offer real protection to buyers.
- Little to no mention of any shared trust standard across sellers — everyone evaluates it their own way.
7. What does she THINK and FEEL?
| PAINS | GAINS |
|---|---|
| No platform consolidates price/quality/reputation comparisons — she has to do it manually. | Values structured trust signals (seller history, response speed, reviews) as a real substitute for the lack of formal buyer protection. |
| Listing quality is inconsistent; the verification burden falls entirely on the buyer. | Would engage more readily with a platform that surfaces comparison data and verified condition/reputation up front, reducing her manual research effort. |
| Reputation systems are one-directional — she has no way to signal trust back, and no shared standard exists across sellers. | Feels relieved when reputation signals are strong enough to move forward with a purchase. |
Additional thoughts and feelings: "Is this seller even real? Their profile looks new." — distrust as her first instinct; mentally taxed treating routine purchases like research tasks; defensive and cautious, actively looking for reasons to distrust; frustrated when she has to do extra legwork the listing should have covered; her biggest fear is paying and never getting the item.
Empathy Map 3 — Valentina, a Student Buyer
Made by: Carla González
1. Who are we empathizing with?
Valentina, 18, first-year Business Administration student at Universidad de los Andes. She is a budget-conscious, risk-averse buyer who needs to purchase expensive introductory textbooks and academic materials for her first semester while keeping costs as low as possible.
2. What does she need to DO?
- Find all required first-year reading materials without spending her entire semester budget at the campus bookstore.
- Ensure she is buying the exact book edition required by her professors without risking buying outdated material.
- Avoid scams or paying upfront to sellers she doesn't know.
- Success looks like: securing all her required course materials at a fraction of the retail price with zero financial risk.
3. What does she SEE?
- High retail prices for new textbooks and course materials at official stores.
- Unorganized secondhand listings scattered across WhatsApp and Facebook groups.
- Older students selling previous editions without specifying if they match current course syllabi.
- Postings with vague condition descriptions like "good shape" without showing highlighted or damaged pages.
4. What does she SAY?
- "I can't afford $300,000 COP for a single finance textbook I'll only use for four months."
- "Is this the 5th or 6th edition? The syllabus specifically asks for the 6th."
- "I'm nervous about transferring money to someone I've never met before seeing the book."
5. What does she DO?
- Asks senior students in student associations for advice on which materials are strictly necessary.
- Cross-checks course reading lists with listings on informal social groups.
- Requests extra photos of book pages to verify how much highlighting or wear exists before buying.
6. What does she HEAR?
- Professors insisting that having the exact textbook edition is mandatory for homework.
- Parents advising her to be cautious with online transactions and meet in safe campus places.
- Senior students telling her that buying brand-new books is a waste of money.
7. What does she THINK and FEEL?
| PAINS | GAINS |
|---|---|
| Anxiety over making financial mistakes or buying the wrong book edition. | Transparent edition details linked directly to specific university courses. |
| Fear of losing money in scams when paying upfront to unknown sellers. | Confidence when purchasing from verified peers within the university campus. |
| Overwhelmed by the transition to university expenses and material requirements. | Empowered and smart when saving money on essential academic supplies. |
Additional thoughts and feelings: Stressed about starting university costs; cautious about peer-to-peer transactions; relieved when she finds structured, clear course-specific listings.
Empathy Map 4 — Mateo, Student Seller
Made by: Carla González
1. Who are we empathizing with?
Mateo, 20, Industrial Engineering student at Universidad de los Andes. He is a frequent seller and opportunistic buyer who wants to monetise his past course materials and buy specialized engineering tools (e.g., drawing sets, scientific calculators) without overcomplicating transactions.
2. What does he need to DO?
- Post items for sale in under 2 minutes without filling out lengthy, non-relevant forms.
- Coordinate safe physical handoffs on campus between classes without sharing his personal phone number with strangers.
- Sell off last semester's specialized materials to fund current course requirements.
- Success looks like: clearing out unused course items efficiently and closing sales with minimal back-and-forth messaging.
3. What does he SEE?
- Messy, unorganized WhatsApp group chats flooded with irrelevant chatter and buried listings.
- Fellow engineering students asking to buy specific tools in last-minute study sessions.
- External platforms demanding personal phone numbers or off-campus logistics for simple, low-value items.
4. What does he SAY?
- "I don't have time to answer twenty questions from someone who isn't actually going to buy."
- "I just want to hand this over near the Mario Laserna building between my 10 AM and 11 AM classes."
- "Why do I have to post this three times on different chats just to get one reply?"
5. What does he DO?
- Drops items in large university WhatsApp groups and hopes someone sees them before the chat moves on.
- Prefers cash or instant bank transfers on the spot during campus meetups.
- Abandons listings if potential buyers ask for time-consuming shipping or off-campus meetings.
6. What does he HEAR?
- Friends complaining about buyer ghosting after agreeing on a price.
- Classmates saying they can't find specific engineering gear on general marketplace apps.
- Warnings from peers about sharing personal contact information on open social media groups.
7. What does he THINK and FEEL?
| PAINS | GAINS |
|---|---|
| Waste of time negotiating with non-serious buyers or dealing with ghosting. | Having a centralized, campus-only space where buyers are verified students. |
| Privacy concerns when giving out personal contact info in public chats. | Frictionless listing and quick in-person campus exchanges. |
| Inability to reach students outside his immediate social circle who actually need his specific items. | Feels relieved when he converts unused gear into instant pocket money. |
Additional thoughts and feelings: Slightly annoyed by the inefficiency of current channels; skeptical about complex platforms; motivated by quick cash and hassle-free campus logistics.
Empathy Map 5 — Camilo, Graduating Seller
Made by: Carla González
1. Who are we empathizing with?
Camilo, 22, graduating Architecture student at Universidad de los Andes who is moving out of his student apartment near campus. He is a bulk seller under time pressure who needs to clear out furniture, drawing boards, and design supplies within two weeks.
2. What does he need to DO?
- Sell multiple items quickly before his apartment lease ends.
- Coordinate pickup for larger items directly at his apartment or nearby campus spots.
- Bundle related items (e.g., cutting mats + drafting tools + scale rulers) to sell them together efficiently.
- Success looks like: emptying his apartment, recovering capital, and handing over items to younger students in his major before his move-out deadline.
3. What does he SEE?
- A room crammed with architecture models, drafting boards, and mini-appliances he can't take home.
- Incoming freshmen looking for cheap apartment setups and specialized design tools.
- Unresponsive buyers on generic secondhand apps who live too far from the university area.
4. What does he SAY?
- "I'm moving out next week and I can't take any of this furniture with me."
- "If you take the drafting table, I'll throw in all these cutting mats for free."
- "I need buyers who can pick this up nearby; I don't have a car to move things."
5. What does he DO?
- Creates multi-item bundle posts on social media with discounted prices.
- Prioritizes buyers who live near the campus area and can pick up items immediately.
- Lowers prices progressively as his moving deadline gets closer.
6. What does he HEAR?
- Landlord reminding him that the apartment must be completely empty by the end of the month.
- Junior architecture students complaining about how expensive design tools are to buy new.
- Friends telling him to just donate or throw away items if he can't sell them in time.
7. What does he THINK and FEEL?
| PAINS | GAINS |
|---|---|
| High stress due to strict move-out deadlines and logistical constraints. | Quick bundle sales that clear space fast. |
| Dealing with unreliable buyers who reschedule pickup times at the last minute. | Connecting directly with incoming students from his same major who need his exact setup. |
| Financial loss if forced to give away or discard valuable supplies. | Satisfaction in passing down tools to younger students while recouping money. |
Additional thoughts and feelings: Anxious about timing; overwhelmed by moving logistics; practical and willing to discount prices for speed and convenience.
6. Business Questions
| # | Business Question | Type | Why it is useful |
|---|---|---|---|
| 1 | In which screens and features of the app do crashes happen most often, and on which OS versions and device models? | 1 | Tells the team where to debug first and which devices to prioritize in testing. |
| 2 | How many listings does a buyer open before contacting a seller, and how many before completing an exchange? | 2 | Maria compares many listings manually. If the number is very high, our search and comparison screens are not giving enough information at first sight. |
| 3 | Which photos do sellers upload most (number of photos, angles, close-ups of damage), and how does that relate to the number of buyers who contact them? | 2 | Isabella and Valentina both said condition must be clear. If listings with 3+ photos get more contacts, we can guide sellers with a photo checklist. |
| 4 | How many messages do a buyer and a seller exchange in the app chat before they agree on a meeting point, and how long does this conversation take? | 2 | Mateo complains about "twenty questions" before a sale. If the number is high, the listing is missing information (condition, edition, price), and we can improve the listing template. |
| 5 | At what time of the day and which days of the week do students publish and browse the most? | 2 | Helps us schedule notifications so they arrive when students are free, instead of being ignored. |
| 6 | Which categories of items (books, calculators, lab equipment, furniture) generate the most listings and the most completed exchanges? | 3 | Shows if we need specialized categories, or if some categories are dead and should be merged or removed. |
| 7 | How many buyers save items in the wishlist, and how many of those saved items end in a purchase after a Smart Matching notification? | 3 | Tells us if Smart Matching is really working or if it is just sending noise. If conversion is low, the matching rules need to change. |
| 8 | Which fields of the listing form do sellers leave empty most often (course, edition, condition, faculty)? | 3 | Empty fields break our filters; we can decide to make a field required, optional, or automatic (for example, taking the faculty from the user profile). |
| 9 | How do prices of the same item vary (same book edition, same model) between sellers, faculties, and item condition? | 4 | This price history is the data that feeds the AI Price Estimation and lets us show a "fair price" range between both sides of the transaction. |
| 10 | Which listings are published but never sold, how long do they stay active, and what hidden patterns do they have in common (clustering by price, category, photos, seller rating)? | 4 | Shows the exact pattern of a "dead" listing, so we can warn sellers or suggest a price drop before they give up. |
| 11 | What is the average time (in days) it takes for a newly listed academic item to be marked as sold? | 1 | Helps the Analytics Manager (Jesús) understand market liquidity and set realistic expectations for new sellers joining the platform. |
| 12 | Which specific campus locations (visualized as a heat map) are most frequently used for item exchanges, and how does this density shift during different hours of the day? | 3 | Allows the app to dynamically suggest the safest and most convenient meeting spots based on real spatial density and time. |
| 13 | What are the most frequently used words and phrases (word cloud) in the in-app chat messages immediately before a transaction is cancelled or abandoned? | 5 | Helps identify hidden friction points (e.g., "too far", "cash only", "scam") that prevent sales from closing, guiding future app improvements. |
| 14 | What is the emotional sentiment (positive, neutral, negative) and the most common keywords found in the written reviews left for buyers and sellers? | 5 | Goes beyond a simple 5-star rating to understand why users trust or distrust peers, improving the platform's overall security and reputation system. |
7. Visualization Data Map (VD-Map)
made by: Carla González The VD-Map shows how the 14 business questions of section 6 will actually be answered. Every chain is read from the centre outwards; a data source (cylinder) feeds a transformation (circle, with the operation written in the grey box under it), the transformation produces a visualization (rectangle), and that visualization answers the business question (cloud, coloured by its type). Each question has its own colour and its BQ number written on the cloud and on the transformation, so a chain can be followed even when it crosses the map.
Data sources
The databases are drawn in a single column in the middle because they are shared between questions, and every one of them is obtained through a backend service of CampusSwap. None of them comes from outside the designed solution.
| Data source | Backend service (PAS) | Questions it feeds |
|---|---|---|
| App telemetry and crash DB | Analytics and Crashlytics SDK embedded in the app | 1 |
| Wishlist and notification DB | Smart Matching Service (PAS 12) | 7 |
| Interaction event log DB | Analytics SDK embedded in the app | 2, 5, 7, 8 |
| Messaging DB | Messaging Service (PAS 8) | 2, 4, 13 |
| Meeting coordination DB | Meeting Coordination Service (PAS 10) | 2, 4, 6, 12, 13 |
| Listing DB | Listing Service (PAS 1, 7, 9) | 3, 5, 6, 8, 9, 10, 11 |
| Reputation and reviews DB | Reputation Service (PAS 4) | 10, 14 |
| Media storage DB | Media Storage Service (PAS 2) | 3, 10 |
| Image recognition DB | AI Price Estimation Service (PAS 11) | 3 |
| Course catalog DB | Course Catalog Service (PAS 5) | 9 |
Chains
| BQ | Type | Visualization | Transformation | Data sources |
|---|---|---|---|---|
| 1 | 1 | Heat map: one row per screen or feature, one column per OS version and device model, coloured by crash rate | Crash clustering and normalization by sessions | Telemetry and crash |
| 2 | 2 | Funnel with one step per stage, plus histogram of listings opened per buyer with median and p75 | Sessionization of events into funnel stages | Event log, Messaging, Meeting |
| 3 | 2 | Scatter plot of photos against contacts received, one point per listing, and box plot by photo bucket | Photo count and photo tags joined with contacts | Listing, Media, Image recognition |
| 4 | 2 | Histogram of messages per thread until the meeting is confirmed, and box plot of time to agreement | Thread aggregation up to the meeting confirmation | Messaging, Meeting |
| 5 | 2 | Two heat maps, hour of the day against day of the week: one for publishing and one for browsing | Local time conversion and hour by weekday aggregation | Event log, Listing |
| 6 | 3 | Pareto chart of listings per category with the completion rate as an overlaid line | Grouping by category and completion rate | Listing, Meeting |
| 7 | 3 | Conversion funnel from wishlist saved to exchange, and conversion rate per matching rule over time | Notification attribution in a 7 day window | Wishlist, Event log |
| 8 | 3 | Bars with the percentage of listings where each field is empty, split by sold or never sold | Field completeness joined with the listing outcome | Event log, Listing |
| 9 | 4 | Box plots of price by condition, faceted by faculty, with the p25 to p75 fair price band | Item identity resolution, outliers and percentiles | Listing, Course catalog |
| 10 | 4 | Survival curve of days active, plus clusters of unsold listings by price, category, photos and rating | Lifecycle labeling and clustering of unsold listings | Listing, Media, Reputation |
| 11 | 1 | Distribution of days from publication to sale with average and median marked, split by category | Time from publication to sold status, excluding active listings | Listing |
| 12 | 3 | Heat map of the campus with the density of confirmed exchange points, with a control to change the hour | Grouping of confirmed meeting points by location and hour | Meeting |
| 13 | 5 | Cloud of words built from the last messages of threads that ended without an exchange | Thread selection with no confirmation, text cleaning and word frequency | Messaging, Meeting |
| 14 | 5 | Bars with the share of positive, neutral and negative reviews, and a cloud of words per sentiment | Sentiment classification and keyword extraction from reviews | Reputation and reviews |
What the map told us
The Listing DB feeds seven of the fourteen questions and the Meeting coordination DB feeds five. We do not need to add services to answer these questions, we need the ones already declared in the PAS to be well instrumented from the first version of the app.
Two chains close the loop back into the product instead of ending in a report. Question 9 produces the p25 to p75 price range that the AI Price Estimation Service (PAS 11) needs to suggest a price, and question 12 produces the exchange density per hour that the Meeting Coordination Service (PAS 10) needs to recommend a safe meeting point. Question 3 works the other way around: the photo tags it needs are already produced by the image recognition that the price suggestion runs on every uploaded photo, so we do not have to label images by hand.
The two type 5 questions are the ones that depend on text we do not control. Both the chat messages of question 13 and the reviews of question 14 are free text written by students, so the transformations there include cleaning and classification steps that the other chains do not need.
8. Functional Scenarios
Personas used: Isabella (seller/buyer), Maria (comparison-driven buyer), Valentina (budget-conscious first-year buyer), Mateo (frequent seller/opportunistic buyer), Camilo (graduating bulk seller).
Scenario 1 Publishing a Course-Tagged Listing
Related to: PAS 1 (Unused materials with no organized resale channel)
| Element | Description |
|---|---|
| Persona action | Isabella opens CampusSwap between classes and creates a new listing for her unused Introduction to Economics calculator. She selects her faculty, degree, and the exact course code (ECON-1101) from a dropdown instead of typing free text. |
| System reaction | The app validates the course code against the Course Catalog Service, auto-fills the faculty/degree fields from her verified student profile, and publishes the listing to the Listing Service, making it immediately visible in ECON-1101 filtered searches. |
| Execution context | Isabella is on campus Wi-Fi, has 6 minutes between classes, is using a mid-range Android phone, and is logged in with her verified institutional session. |
Scenario 2 Adding Condition Proof to a Listing
Related to: PAS 2 (Buyers distrust used items with no proof of condition)
| Element | Description |
|---|---|
| Persona action | Isabella attaches three real photos of her book (cover, spine, and a page with highlighting) and selects the "Fair" condition tag before publishing. |
| System reaction | The app compresses and uploads the photos to the Media Storage Service, blocks submission if fewer than the minimum required photos are attached, and displays the condition tag prominently on the listing card in search results. |
| Execution context | Isabella is in a dorm room with average lighting and a stable but not fast home Wi-Fi connection; storage on her phone is limited, so photo compression matters. |
Scenario 3 Comparing Listings Side by Side
Related to: PAS 3 (Buyers manually cross-reference listings and sellers across tabs)
| Element | Description |
|---|---|
| Persona action | Maria searches for "Calculus I textbook" and opens the comparison view to see three matching listings from different sellers at once. |
| System reaction | The Search & Ranking Service returns matching listings ranked by relevance and displays price, condition, and seller rating together in a single comparison screen, without needing Maria to open separate listing pages. |
| Execution context | It is the first week of the semester, so search volume is high; Maria is on campus Wi-Fi during a break between classes. |
Scenario 4 Checking Seller Reputation Before Messaging
Related to: PAS 4 (No shared trust/reputation standard across sellers)
| Element | Description |
|---|---|
| Persona action | Before contacting a seller, Maria taps on the seller's profile to check their star rating, number of completed sales, and average response time. |
| System reaction | The Reputation Service returns the aggregated score computed only from verified completed transactions and flags the profile as "New seller" if there is not yet enough transaction history to generate a meaningful score. |
| Execution context | Maria is deciding between two sellers with similar prices; one is a first-time seller, so the cold-start case is triggered. |
Scenario 5 Filtering by Exact Edition
Related to: PAS 5 (Uncertainty about exact textbook edition required)
| Element | Description |
|---|---|
| Persona action | Valentina filters listings for her Finance course by the exact edition (6th) required in her syllabus, instead of scrolling through all "Finance textbook" posts. |
| System reaction | The Course Catalog Service cross-references the course code with its required edition/ISBN, and the app hides listings that don't match that edition unless Valentina explicitly expands the filter to "all editions." |
| Execution context | It's the start of the semester, catalog data was just refreshed for the new term, and Valentina is on a tight book-buying budget. |
Scenario 6 Verified-Only Access and Safe Meeting Point
Related to: PAS 6 (Fear of scams when paying upfront to strangers)
| Element | Description |
|---|---|
| Persona action | Valentina, a first-year student, tries to message a seller for the first time and is prompted to verify her institutional email before any chat is enabled. |
| System reaction | The Authentication & Verification Service confirms her @uniandes.edu.co address via OAuth, activates her account, and only then does the app suggest a pre-mapped, public, on-campus meeting point for the eventual handoff; no payment credentials are requested at any point. |
| Execution context | Valentina is a new user opening the app for the first time on her personal device; she is nervous about the transaction and reads the verification and safety messaging carefully. |
Scenario 7 Persistent, Searchable Listing Feed
Related to: PAS 7 (Listings get buried in disorganized WhatsApp groups)
| Element | Description |
|---|---|
| Persona action | Mateo publishes a listing for a drafting set and does not have to repost it days later because messages don't get buried like in his old WhatsApp group. |
| System reaction | The Listing Service keeps the listing indexed and searchable until Mateo marks it sold or removes it, and the app automatically archives listings that remain unsold beyond a configurable time window. |
| Execution context | It's mid-semester, so listing turnover is moderate; Mateo expects the whole publishing flow to take under 2 minutes. |
Scenario 8 Messaging Without Sharing a Phone Number
Related to: PAS 8 (Privacy concerns from sharing personal contact info)
| Element | Description |
|---|---|
| Persona action | A buyer messages Mateo about his drafting set through the in-app chat; Mateo replies and negotiates pickup details without giving out his personal phone number. |
| System reaction | The Messaging Service delivers messages in real time over WebSocket, sends a push notification for new messages, and never surfaces either party's phone number in the conversation by default. |
| Execution context | Mateo is walking between the Mario Laserna building and his next class, on patchy campus Wi-Fi, so the chat needs to degrade gracefully and sync once connectivity returns. |
Scenario 9 Bundling Multiple Items Before Moving Out
Related to: PAS 9 (Bulk sellers under time pressure can't bundle items)
| Element | Description |
|---|---|
| Persona action | Camilo, moving out in two weeks, selects his drafting table, cutting mats, and scale rulers and groups them into a single bundle listing with one combined discounted price. |
| System reaction | The extended Listing Service stores the bundle as one grouped record with a combined price, while still keeping each item individually searchable so buyers looking for just a scale ruler can still find it inside the bundle. |
| Execution context | Camilo is under a strict move-out deadline, has many items to list quickly, and needs the bundling flow to stay fast so it doesn't slow down his listing session. |
Scenario 10 Confirming a Pickup Time and Place
Related to: PAS 10 (Unreliable buyers reschedule pickups at the last minute)
| Element | Description |
|---|---|
| Persona action | Camilo agrees on a price with a buyer and uses the in-app scheduling feature to propose a specific pickup time and an on-campus location. |
| System reaction | The Meeting Coordination Service checks the suggested time against known class-schedule conflicts, requires both parties to confirm the appointment in-app, and sends a reminder notification to both shortly before the scheduled time. |
| Execution context | Camilo has already been burned by no-shows before, so he wants an explicit two-sided confirmation rather than an informal verbal agreement. |
Scenario 11 Getting an AI-Suggested Price
Related to: PAS 11 (Sellers don't know how to price their items fairly)
| Element | Description |
|---|---|
| Persona action | Mateo takes a photo of his used scientific calculator while creating a listing and taps "Suggest a price." |
| System reaction | The AI Price Estimation Service analyzes the photo, cross-references similar past listings and their sale prices, and returns a suggested fair price range that Mateo can accept, adjust, or ignore — the final price is always his choice. |
| Execution context | Mateo has never sold this type of item before and has no reference for pricing it; the suggestion quality depends on there being enough historical listings for that item category. |
Scenario 12 Getting Notified of a Matching Listing
Related to: PAS 12 (Students miss relevant listings buried among irrelevant ones)
| Element | Description |
|---|---|
| Persona action | Isabella had earlier saved "French textbook, any edition" to her wishlist. Days later, without opening the app, she receives a push notification that a matching listing was just published. |
| System reaction | The Smart Matching Service compares the new listing against all active wishlists and course/degree profiles, and triggers a push notification only for the students whose saved criteria match, avoiding notifying the whole user base. |
| Execution context | Isabella has notification permissions enabled and hasn't opened the app in three days; the match must be precise enough that she doesn't feel spammed by irrelevant alerts. |
9. Quality Scenarios
| Scenario Name | Quality Attributes | App Status and Context | Changes in the Context | System Reaction |
|---|---|---|---|---|
| Image Upload Timeout | Eventual connectivity, Resilience | The user is uploading 5 high-res photos of a textbook to create a new listing. | The user walks into an elevator and entirely loses their Wi-Fi and mobile data connection. | The app saves the listing draft locally, alerts the user, and auto-resumes the upload silently once the connection is restored. |
| Start of Semester Rush | Scalability, Performance | The app is running with standard traffic loads during the summer break. | The first day of class hits, and active user traffic spikes by 1000% as everyone lists materials. | The backend auto-scales its server instances to handle the concurrent load without degrading search query response times. |
| Payment Gateway Timeout | Security, Resilience | A user is initiating a digital peer-to-peer payment via Nequi to secure a lab coat. | The payment API takes longer than 15 seconds to respond due to external network issues. | The app safely cancels the transaction block, informs the user of the timeout, and prevents double-charging. |
| High Sun Glare | Usability, Accessibility | The app is displaying the barcode scanner interface to verify a textbook edition. | The user steps outside into direct, harsh sunlight, making the screen almost unreadable. | The UI provides high-contrast visual cues and haptic feedback (a distinct vibration) to confirm a successful scan. |
| Rapid Scrolling | GUI Responsiveness, Performance | The user is browsing a massive list of available engineering materials. | The user swipes down vigorously to scroll through hundreds of listings in seconds. | The app uses lazy loading and placeholder images to keep the frame rate smooth without freezing the UI. |
| Unauthorized Access Attempt | Security | A new user is on the registration screen attempting to create an account. | The user inputs a generic email address (e.g., @gmail.com) instead of a university one. | The system immediately rejects the input, explicitly explaining that only verified institutional emails are accepted. |
| Memory Pressure | Performance, Resilience | The user has 15 other heavy apps open while writing a description for a used calculator. | The OS begins killing background tasks to reclaim memory while the user briefly switches to WhatsApp. | The app saves the text input state locally so it restores instantly when the user brings the app back to the foreground. |
| Screen Reader Navigation | Accessibility | The app is open on the main marketplace feed. | A visually impaired user navigates the app using native OS screen reading tools (VoiceOver/TalkBack). | All UI elements, images, and buttons have descriptive alt-text and logical focus ordering for seamless voice navigation. |
| Database Outage | Availability, Resilience | Users are actively browsing active listings on the app. | The primary cloud database experiences a sudden crash and goes offline. | The app displays a friendly "maintenance" screen and serves cached offline data rather than crashing completely. |
| Foreign Exchange Student | Internationalization | The app is installed on a smartphone where the OS default language is set to English. | An exchange student opens the app to look for course materials. | The app detects the device language and dynamically translates the static UI elements (menus, buttons) to English. |
| Dead Battery Mid-Chat | Resilience | A buyer and seller are chatting in the app to finalize a campus meeting spot. | The buyer's phone battery dies immediately after they hit "send" on a message. | The message remains in a local pending state; upon reboot, the app syncs with the cloud and sends the message successfully. |
| Spam Listing Attack | Security, Availability | The app is operating normally. | A botnet attempts to create thousands of fake, duplicate textbook listings within seconds. | Rate limiting triggers, blocking the suspicious IP addresses and requiring a CAPTCHA challenge for rapid successive uploads. |