Micro Sprint 6: Value Proposition & UI/UX Design Foundations

1. Value Proposition

1.1 Core Problem & Market Gap

University students routinely acquire high-cost, course-specific materials — calculators, lab equipment, technical textbooks — that become dead weight the moment a semester ends, while incoming students face the same items at full retail price with no reliable way to source them second-hand. The channels students currently improvise around this — WhatsApp groups, general Facebook groups and marketplace pages, and generic e-commerce sites like MercadoLibre — were never built for this problem, and it shows in three specific, recurring frictions:

• Information decay. A listing in a WhatsApp group has a shelf life of minutes before it's buried under unrelated chatter; there is no persistent index, and nothing lets a buyer filter by faculty, program, or exact course code.
• A trust vacuum. These channels are open to anyone, not just verified students, so buyers have no way to confirm a seller is real, no structured proof of an item's condition, and no shared reputation signal to fall back on.
• Frictional pricing and coordination. Sellers guess at fair prices with no comparable data, and both sides burn time negotiating logistics and a safe place to meet — with no institutional layer making any of it easier.

1.2 The CampusSwap Value Proposition

CampusSwap is a hyper-localized, closed-loop marketplace built exclusively for verified university students — not a general marketplace with a student filter bolted on, but a product designed around how academic materials actually move through a campus.

For university students who need affordable, course-specific academic materials and want a responsible way to offload the ones they no longer use, CampusSwap is a peer-to-peer marketplace restricted to verified students that makes buying and selling academic materials organized, trustworthy, and course-specific. Unlike WhatsApp groups, Facebook Marketplace, or general e-commerce platforms like MercadoLibre — which are disorganized, open to non-students, and offer no way to verify condition, edition, or seller legitimacy — CampusSwap turns that same exchange into a structured, verified, academic-first experience.

That difference holds up feature by feature, not just in positioning:

Friction today	WhatsApp / Facebook groups	General e-commerce (MercadoLibre)	CampusSwap
Finding the right item	Buried in chat history, no filters	Filterable, but not by faculty/course	Filtered by faculty, program, and exact course code
Verifying who you're dealing with	Anyone can join and post	Open to the public	Institutional-email verification only
Proof of condition	A vague description at best	Seller-written, unverified	Required real photos + explicit condition tag
Reputation	None	Generic buyer/seller reviews	Peer ratings scoped to a community you actually belong to
Contact & safety	Personal phone number shared openly	Off-platform contact, no safety layer	In-app messaging, no number shared, pre-mapped safe on-campus meeting points
Pricing an item	Pure guesswork	Broad market comps, not academic-specific	AI-suggested price range trained on comparable academic listings
Discovery of new matches	Manual re-checking of chats	Generic keyword alerts	Wishlist-based smart matching tied to your program and courses

The three pillars that make this possible:

1. Academic-specific taxonomy — items map directly to faculties, programs, and course syllabi, so search means "what my course needs," not "everything anyone posted this week."
2. Community-grounded trust — institutional email verification, peer ratings, and explicit condition badges (Like New, Good, Fair) replace the guesswork of dealing with strangers.
3. Smart friction reduction — wishlist-based smart matching, AI-assisted price suggestions, and designated safe on-campus meeting points remove the manual coordination cost that kills deals on informal channels.

No single one of these is unique in isolation — marketplaces have filters, e-commerce sites have reviews. What's differentiated is that all three are scoped to one closed, verified academic community solving one specific problem, which is exactly the trade-off a general-purpose platform can't make without losing its broader reach.

---

2. UI/UX Design Specification

2.1 Colour Palette and Rationale

The visual identity uses a focused palette built around deep navy, multiple shades of blue, and soft blue-lavender tones. This combination creates a modern, polished, and approachable aesthetic while providing a clear visual hierarchy across the application's interface.

• Deep Navy — #0E122F: Used as the darkest foundational color for high-emphasis elements, primary text, headings, navigation components, and other areas requiring strong contrast. Its deep tone provides a sense of stability and gives the interface a strong visual foundation.

• Primary Blue — #202A6A: Used for primary interface elements such as buttons, important actions, active navigation states, and prominent UI components. It provides strong contrast while maintaining the application's blue visual identity.

• Accent Blue — #3B4DC4: Used as the primary accent color for interactive elements, links, highlights, selected states, and other components that need to attract the user's attention. Its brighter tone establishes a clear distinction from the darker primary colors.

• Secondary Blue — #8B94D0: Used for secondary interface elements, supporting text, borders, icons, inactive states, and other lower-emphasis components. This softer blue helps establish visual hierarchy without competing with primary actions.

• Light Blue — #C6C9E2: Used primarily for light surfaces, backgrounds, cards, subtle highlights, and decorative elements. Its pale tone provides visual separation while keeping the interface clean and lightweight.

The application should maintain these five colors as its core visual identity. Additional colors should be avoided unless they are required for functional states such as errors, warnings, or success indicators. Opacity and tonal variations of the established palette may be used when additional visual hierarchy is required.

2.2 Typography & Fonts

The typography system uses three dedicated typefaces, each assigned a specific role within the interface:

• Heading Font — Fraunces:

  • Usage: Screen titles, major headings, section headers, prominent metrics, and other high-emphasis display text.
  • Rationale: Fraunces is a distinctive serif typeface that gives the interface a refined and expressive character. Its strong contrast and organic forms create a visual identity that feels sophisticated while remaining approachable.

• Body Font — Outfit:

  • Usage: Paragraphs, item descriptions, form fields, buttons, navigation elements, labels, prices, and other general interface content.
  • Rationale: Outfit provides a clean, contemporary sans-serif appearance with excellent readability across digital interfaces. Its geometric construction complements the structured blue color palette while keeping the interface modern and accessible.

• Monospace Font — JetBrains Mono:

  • Usage: Source code, code snippets, technical identifiers, terminal commands, and other content that benefits from a fixed-width typeface.
  • Rationale: JetBrains Mono is specifically designed for programming and technical content. Its distinct character shapes and consistent spacing improve readability when displaying code and other monospaced information.

The typography hierarchy should therefore follow Fraunces for headings, Outfit for body and interface text, and JetBrains Mono for monospace code, maintaining consistent font usage throughout the application.

2.3 Icons and Imagery

• Iconography: Clean, modern line icons with rounded strokes (Material Design Icons / Feather Icons) representing essential navigation: Home, Search, + Sell, Cart, and Profile/Seller. Specialized status badges (star ratings, condition tags, verified checks) feature consistent 2px stroke weighting.
• Imagery Standard:
  • Product Photography: Displayed in fixed aspect-ratio rounded containers (12px border radius) to maintain uniform grid alignment.

2.4 UI Prototype

The UI prototype was made with Figma Make, you can see it here

The proposed wireframes standardize authentication, profile information, and product publication through shared components and consistent interactions. These flows follow the colour palette, typography hierarchy, and imagery standards defined in Sections 2.1 until 2.3.

Authentication and Login Assets

• Brand Identity: The login screen should use the CampusSwap mascot and badge container consistently with the application's visual identity. Outfit is used for headings, Nunito for labels and buttons, and Inter for supporting information.
• Email Access: The proposed form includes email and password fields, aligning the interface with the verified university community described in the value proposition. Verified status requires a separate verification step.
• Primary Action: The Log in button uses deep violet (#734A91) and a consistent rounded shape. Password visibility controls and persistent field labels support form completion.
• Feedback: Empty, loading, and error states provide clear guidance. Validation messages appear beside the relevant fields, and demonstration access remains separate from the intended login experience.
• Supporting Navigation: Registration and password-recovery links should connect to their corresponding flows when available. Successful simulated authentication leads to Home.

Profile and Seller Interface

• User Identity: The proposed profile displays an avatar, display name, and institutional verification status without publicly exposing the full institutional email address.
• Community Trust: Ratings follow a consistent visual treatment. Users without reviews receive a No reviews yet state instead of a fabricated score.
• Listing Overview: A My listings section provides access to the user's published items. Cards reuse the image containers, prices, and condition badges defined for product publication.
• Visual Consistency: The profile reuses the typography and components of the authentication and publishing screens. A single label should be agreed for the existing Profile/Seller navigation destination.

Sell Product Publishing Flow

The proposed flow organizes publication into product information, academic classification, review, and confirmation:

1. Product Information and Photo Upload: An Add photos area offers camera and gallery options, image previews, removal controls, and cover-photo selection. The form includes title, description, category, and price with an explicit currency label. Failed uploads should allow a retry without losing the remaining form data.
2. Course Selection and Condition: A searchable selector displays course codes and names to support academic classification. A Not associated with a course option is proposed for general-purpose items, subject to the team's classification rules. Sellers select exactly one condition badge: Like New, Good, or Fair.
3. Listing Review: A preview displays photos, title, price, description, category, course, condition, and seller information. An Edit action allows corrections while preserving previously entered information.
4. Publication Feedback: The Publish listing action displays a loading state followed by confirmation or a recoverable error. Successful simulated publication offers View listing and Back to Home actions.

Flow Consistency and Navigation

• Entry Point: The central Sell action opens the publishing flow.
• Sequential Navigation: Continue, Back, and Review listing actions use consistent placement and preserve information when moving between steps.
• Exit Behaviour: Leaving an unfinished listing should request confirmation before discarding changes. The proposed focused form temporarily hides BottomNav and restores it when returning to a main destination.
• Profile Integration: Listing previews, product details, and My listings should share the same product presentation and condition labels.
• Prototype Scope: Authentication, image upload, and publication may be simulated for this design deliverable. Evidence should clearly distinguish completed frames from planned interactions.

2.5 Navigational Patterns

The mobile app leverages established, ergonomic Android/iOS interaction patterns, so navigation feels native on both platforms and requires no learning curve. The navigation system is organized in four layers:

Layer	Purpose	Pattern used
Primary	Move between top-level areas	Persistent bottom navigation bar (5 destinations)
Secondary	Go deeper inside an area	Hierarchical push to detail screens
Lateral	Narrow the current content	Category chips and an expandable filter panel
Transient	Focused tasks that take over the screen	Full-screen modal flow

Persistent bottom navigation bar

• Destinations (5): Home, Search, + Sell, Cart, Seller. The count respects the recommendation of three to five top-level destinations.
• Central FAB-style action: + Sell is a raised, filled button at the centre of the bar, in the most reachable point of the thumb zone.
• Persistence: the bar remains visible on detail screens, keeping every primary area one tap away.
• Theme awareness: the bar adapts to the light and dark themes exposed by the header theme toggle, preserving contrast in both.

Publishing flow

The + Sell action opens the listing flow as a full-screen modal, hiding the bottom navigation bar for its duration to signal a focused task. The flow follows Product Info & Photos → Course & Condition → Review → Confirmation, with a step indicator, consistent Continue and Back placement, and data preserved when moving between steps.

Home header

• A fixed header holds the brand mark, a search field, and three utility actions: theme toggle, notifications, and wishlist. Notifications and Wishlist are defined as header-level destinations rather than bottom-bar destinations, to keep the primary bar at five items.

Direct category filtering (horizontal chips)

• A horizontally scrollable chip container (All, Calculators, Textbooks, Lab Supplies, Supplies, Notes, Electronics) changes category without a screen transition: the content updates in place.
• Single-select: exactly one category chip is active at a time, with All as the default.
• Section-level "See all" links move the user from a curated Home carousel into the full results view.

Hierarchical stack navigation

Browsing pushes from a listing to Product Detail, which presents an image carousel with position dots, category / course / condition badges, price and rating, seller summary, description, Add to Cart and Buy Now, and related materials.

• A floating back control (←) sits over the image at the top left, paired with a wishlist control at the top right.
• The bottom navigation bar stays visible, so the user can leave the branch for any primary destination at any time.

Back navigation

• Each primary destination keeps its own back stack and scroll position, so a product opened from Search returns to the search results rather than to Home.
• Tapping the already-active destination pops its stack to the root screen and scrolls the content to the top.
• On Android the system back gesture pops the current stack; on a root destination it returns to Home, and on Home it triggers the standard confirm-to-exit behaviour. On iOS the edge-swipe-back gesture is supported on every pushed screen.
• Any screen holding uncommitted input intercepts back and asks for confirmation before discarding it.

Search and filters

The Search destination shows a result count and a results grid. The filter control expands an inline panel beneath the search field so the results stay visible while the query is refined and no context is lost. The panel exposes Category, Condition (All, New, Like New, Good, Fair), a Max Price slider, and Sort by (Relevance, Price low, Price high, Rating).

Navigation states

The Cart defines an empty state that carries a navigational action ("Cart is empty" → Browse Items), so a dead end always offers a way forward. Every list surface should apply the same treatment, with skeleton loading and inline retry on error.