Micro Sprint 4 - Moviles-G23-20262/General-Wiki GitHub Wiki
1. Description of the problem and the proposed solution
made by: Carla Fernanda González Mina
In university communities there is a massive waste of academic resources. Brand new materials are too expensive, and finding a specific second hand item is difficult because the places where students look today (Facebook Marketplace, WhatsApp groups, MercadoLibre) are unorganized, full of non students, and give no way to check if a book matches the edition that a course actually requires.
We are the Mobile App Development Team, and we are developing CampusSwap, a marketplace restricted to verified students of Universidad de los Andes, to solve the problem of wasted academic materials and to create a trustworthy, organized and course specific place to buy, sell and reuse books, calculators, lab equipment and design tools.
The app is organized around four ideas that come directly from our personas and from the Context Canvas in section 6:
- Course specific search. Listings are filtered by faculty, degree and course code, so students find exactly what their syllabus asks for.
- 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 in the negotiation. Buyer and seller talk through in app messaging, so nobody has to publish a personal phone number, and they agree on a campus meeting point inside the app.
- Smart features. 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 their current courses. Payments stay outside the platform: the exchange is in person on campus, so the app never stores payment credentials. The main constraints we have to respect are the short time windows students have between classes, weak connectivity in basements and large buildings, budget devices with limited battery and storage, and the privacy of student data.
All of this is a set of hypotheses about how students behave, so the app also has to produce data. That data is for our analytics persona, Jesús Lievano, a product manager who needs to see supply and demand of course materials by faculty in real time, detect scam patterns, prove the impact of the platform to the University Administration, and get clean historical prices to train the AI price model. Sections 5 and 7 define exactly what we have to measure for him.
2. Analytics Persona
3. Problems–Alternatives–Solutions (PAS) Hypotheses
made by: Daniel Diab Source: Empathy maps & personas from MS3 (Isabella, Maria, Valentina, Mateo, Camilo)
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. |
| 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. |
| 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. |
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. |
| 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. |
| 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. |
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. |
| 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; needs to perform well on campus Wi-Fi. |
| Constraints | Ranking algorithm must avoid bias toward paying/sponsored sellers (none exist yet, but must be future-proof); response time must stay low for a good UX. |
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. |
| 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. |
| 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. |
| 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. |
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. |
| 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. |
| 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. |
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. |
| 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). |
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. |
| 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. |
| Environmental Conditions | Requires stable connectivity for real time delivery; must degrade gracefully on poor campus Wi-Fi. |
| 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. |
| 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. |
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. |
| 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. |
| 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. |
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). |
| 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 (from the "Darling" feature category) 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). |
| Environmental Conditions | Requires a growing dataset of past listings/prices to improve suggestion accuracy over time. |
| Constraints | Suggested price is advisory only (seller sets final price); model accuracy depends on image quality and available comparable listings. |
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. |
| 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 "Most Likely to Delight" / 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. |
| 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. |
5. 10 Business Questions
| # | Business Question | Type | Why it is useful |
|---|---|---|---|
| 1 | In wich screens and features of the app do crashes happen most often, and on wich OS versions and device models ? | 1 | Tells the team where to debug first and wich devices to proritize 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 givin enough information aat first sight. |
| 3 | Wich 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 checlist |
| 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 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 listing template or the meeting point suggestion |
| 5 | At what time of the day and wich days of the week do students publish and browse the most ? | 2 | Help 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, 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 | Tell 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 | Wich fields of the listing form do sellers leave empty most often (course, edition, condition, faculty) ? | 3 | Empty field breaak our filters, we can decide to make a field required, optional, or automatic (for example, taking the faculty from the 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 AI Price estimation and let 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 do they have in common (price, category, photos, seller rating) ? | (2/3/4) | Combines user experience, feature decisions and data value: it shows the exact pattern of a "dead" listing, so we can warn sellers or suggest a price drop before they give up |
6. Context Canvas
To clearly illustrate the environment and overall structure of our proposed solution, we developed a Context Canvas for the selected problem. The image is provided in high resolution and can be enlarged for detailed viewing.
Our Context Canvas presents a mobile marketplace exclusively for university of los Andes students, designed to facilitate the buying, selling, exchanging, and reuse of academic materials such as books, calculators, lab coats, and equipment. It addresses the difficulty of finding affordable and specific academic products while providing a more organized and trustworthy alternative to general marketplaces and social media groups. The app is mainly used around campus, allowing students to quickly search for items, publish products, communicate with buyers or sellers, and coordinate exchanges.
It integrates university authentication, camera/gallery, notifications, and cloud services to manage users and listings. The solution differentiates itself through academic-specific categories, faculty and degree filters, student verification, and smart features such as personalized recommendations, buyer-seller matching, and approximate price suggestions. Key constraints include privacy, reliable connectivity, quick interactions between classes, and efficient mobile performance.
7. VD-Map the Visualization Data Map
made by: Carla Fernanda Gonzalez Mina
The VD-Map shows how we plan to answer the ten business questions of section 5. Each chain starts in a database, passes through a transformation (the circle, with the operation written in the grey box under it) and ends in a visualization (the rectangle), and that visualization is what answers the question (the cloud, coloured by its type). The image is in high resolution and can be enlarged.
We drew the databases in the middle on purpose, because almost all of them are shared. The Listing DB is used by seven of the ten questions and the event log by five. That was probably the most useful thing the map showed us: we do not need to add new services to answer these questions, we need the ones we already declared in the Context Canvas (the cloud database and storage, the messaging engine, the identity provider) to be well instrumented from the first version of the app.
The two dashed cylinders are sources we do not have. One is a database with labels for the photos (angle, close up, damage), which we would need for the second half of question 3. Without it we can count how many photos a listing has, but we cannot say what kind of photos they are. The other is the course catalog with the ISBN and the edition that each course requires, and that one depends on the university publishing the reference every semester. It worries us more, because the AI price suggestion needs it too. If we never get access to it we would have to build our own catalog from the listings that students publish.
Question 9 is the clearest case of the data coming back into the product. The price range it calculates is exactly what feeds the AI Price Estimation Service, so it is not only a report for the team. Question 10 was the last one we added, and it was easy because it reuses four sources that were already in the map for other questions.