UX/UI design for a P2P marketplace mobile app. Collegial

Collegial - P2P marketplace mobile app where every student is both poster and doer

Collegial is a P2P marketplace mobile app (iOS and Android) where US college students post small paid tasks and complete tasks for other students on their own campus. We designed the product from scratch: the information architecture, the UI for both roles, an interactive prototype tested in Maze, and a design system.

Domain: P2P marketplace, EdTech, EdTech, Consumer Services, Gig Economy Platform: Mobile App (iOS and Android) Year: October 2023 – December 2023 Service type: Full-cycle product and UX/UI design

Client problem: Students are short on time, and many need flexible income: about 67% of US undergraduates work for pay, and 56% of working students say the job gets in the way of activities or social events (Trellis Strategies via BestColleges, 2025). The founder wanted a marketplace inside a single college, where students hire each other for tutoring, coursework help, cleaning, or copywriting.

Our role: Full-cycle product design of the mobile app. We ran discovery, built the information architecture, set the visual direction, designed the UI for every flow, tested the prototype in Maze, created the design system, and prepared the handoff.

Challenge: Any student can be the one who posts a task and the one who does it. The client didn’t want two app versions or a mode switch, so both roles had to live in one interface without confusing people who move between them.

Strategic approach: We started by working out how future users think and what they expect: what a student needs to see before trusting a peer, and which patterns they already know from apps like Uber and TaskRabbit. The information architecture, approved by the client before any UI work, then let us plan the whole app at once instead of screen by screen. Poster and doer flows sit side by side: easy to reach, but separated enough that users always know which role they’re acting in. One interface for two roles

We designed one My tasks section instead of separate poster and doer modes. It groups everything a student is involved in by their relationship to the task: Posted for tasks they created, In progress for tasks they’re doing, and Invites for tasks they’ve been asked to take on. Each tab has its own empty state that explains what will appear there and points to the next action. Context menus let a poster manage a task that still has no tasker without leaving the list.

The same student can apply for one task and manage applicants on another, and we didn’t want them to learn two apps for that. So we designed the UI to read the user’s role in each task and put forward only the action that matters for that role, leaving the rest out of the way. The same principle runs through chats and notifications: each side sees what its role needs, and a student who mostly posts can turn down tasker alerts without missing anything important. The aim was one familiar interface where users never have to stop and work out which role they’re in. UX for posting and finding work on campus

We split task creation into two short steps, so no one faces a single long form. The first step covers what the task is: category, title and description. The second sets the terms, starting with the pricing model, fixed or hourly, then budget and timing. The pricing model comes first because it shapes the whole completion and payment flow later on.

The feed is where both roles meet, so we designed it around quick decisions. We kept it inside the student’s own campus to make the closed community visible from the first screen, and designed task cards so a student can tell whether a task is worth opening before opening it. Filters adapt to the type of task, so no one deals with controls that don’t apply. Posting stays one tap away from browsing, because the same people do both. And posters don’t have to wait for applicants: they can find a tasker themselves and go back to students they’ve hired before, since in a closed community repeat collaboration is an important trust signal. Verified students and visible reputation

In a campus-only marketplace, the .edu check could easily feel like a gate. We designed sign-up to turn it into the reason to join: the first screen talks about a community of your own college, not about rules. Sign-in uses the college email and a one-time code instead of a password, so verifying the student and letting them in happen in one step. We didn’t push anyone into a public profile either. It’s offered as a choice, and the copy explains what it unlocks, so the decision is informed rather than forced.

Students hire peers they may never have worked with, so we designed the profile to answer one question at a glance: can I rely on this person? That’s why reputation sits next to who they are, their major, and college. We kept rating to a simple Positive or Negative choice, because a review should take seconds to give, and every one of them adds up to the score on the profile. Reporting follows one anonymous pattern for tasks, users, and chats. Anonymity removes the social cost of reporting a fellow student. Process

The work began with a brainstorm session. We went through the client’s spec to understand the dual-role model and its constraints, such as .edu-only access and payment after confirmation. Then we studied competitors and the products the client named as references, Uber, TaskRabbit, Airbnb and Depop, to find UX patterns students already know.

We built the app’s information architecture to show the client the full functionality and app logic before any UI work. Once he approved it, it became the map for fitting both roles into one interface.

The client named Uber as a reference and left the look and feel to us. We put together moodboards, explored several visual directions and presented different options to the client. The direction he chose, sleek and minimal but with the energy of college life, became the UI for both roles, covering empty, error, modal and notification states in every flow.

The client wanted a continuous feedback loop with his focus group. We built clickable prototypes in Figma with micro-interactions and an animated onboarding, so testers would feel they were using a real product. Then we prepared Maze prototypes of three core user flows and ran each one with the client’s focus group. The tests helped us understand how users actually move through the app, and we refined the interface based on what we learned.

The client wanted a modular product that could grow with new task types. We built a separate Figma library with colors and typography, UI components in 12 groups, a dedicated icon set, a tutorial page on how to use the system and an updates log. It makes adding features faster and keeps design and development consistent.

We prepared the work for the implementation team: 200+ screens covering both roles, the design system, the interactive prototype with animations, and the approved information architecture.