Case study — 01

Colab

Open interactive prototype 9 clickable flows in Figma — sign in, onboarding, posting & applying to projects, collaboration, disputes, and more.

A mobile marketplace where creative projects actually get finished — taken end to end, on my own.

Mobile appEnd-to-end UX/UISelf-directed2026
Overview

From idea to finished project, in one place.

Colab is a mobile marketplace for creative collaboration. People post a project and find collaborators, or apply to join someone else's — then agree on terms, work together, and get paid through payments the platform holds until the work is done.

I took it end to end on my own: research, information architecture, user flows, branding, a full design system, high-fidelity screens, and a prototype.

Role
Everything — UX, UI, branding, system
Type
Self-directed capstone
Platform
iOS mobile app
Tools
Figma, After Effects
Product walkthrough
The problem

Creative projects start with energy and stall without structure.

Problem

Too many creative projects go unfinished. Finding the right collaborators is hard, and networking the traditional way is slow.

Solution

Colab brings creative collaboration into one structured space — find the right people, work on real projects, get paid, and grow as you go.

Problem and solution
Research

A gap between two kinds of platform.

Benchmarking against BandLab and Upwork surfaced the opening: BandLab has creative collaboration but no structure or held payments; Upwork has the structure and payments but isn't built for creative work. Colab sits in between.

Benchmarking table
Feature benchmark — where BandLab and Upwork each fall short

Two personas anchor the product, pointing in opposite directions: Alex has the idea and needs people to build it with; Emma has the skill and needs projects to work on. Same platform, opposite needs — which is why every Colab user is both a creator and a collaborator.

Persona — Alex Carter
Persona — Emma Lewis
Process

Discovery → Branding → UX → UI.

I worked structure-first: research and problem definition before branding, flows and sitemap before screens, and a component library before polishing details.

Design process
Product decisions

The parts I'm proudest of are about behaviour, not looks.

Held payments protect both sides: the money is locked when both agree and released the moment the work is approved — so paying a stranger isn't a leap of faith.

Held payments

Colab AI shows up at the hard moments — finding the right project, writing a brief, pitching yourself, resolving a dispute. It drafts, suggests and proposes; you always edit, choose and decide.

Colab AI

Reputation turns free work into future paid work. Credits are earned only at completion, at a fixed platform-set value, and can't be farmed.

Reputation and credits
Structure & flows

Mapping the whole product before drawing a single screen.

A five-branch information architecture — Home, Explore, Create, Messages, Profile — then flows for every path, including the ones most portfolios skip.

Sitemap
Sitemap

The cancellation flow was the hardest to get right — it has to stay fair when a collaboration falls apart, branching on how much work was done and whether both sides agree.

Cancel collaboration flow
User flow — cancel collaboration
Design system

A system so decisions stop being guesses.

Space Grotesk throughout, a 4-point spacing grid with named tokens, a 44px tap target on every interactive element, and colour named by role rather than by appearance — so meaning stays clear even when hues repeat.

Colours
Typography
Components and states
Cards
High-fidelity screens

Where the thinking becomes a product.

Colab projects need several roles at once, so applying had to handle multiple selections in one submission — each role card carries its own state and rate, and the button counts what you're committing to before you send.

Explore and apply screens
Explore & apply
Review applicants screens
Review applicants — triage fast, then look closer without losing your place
Iterations

Four times the first answer was wrong.

01

The cancellation flow asked one person to answer for two

First version

The flow opened with "Has this been agreed with the other side?"

The problem

Whoever starts a cancellation can't honestly answer that — they'd be speaking for someone who hasn't been asked yet.

What I changed

Cancellation became a request. One person states their reason, the app notifies the other side, and they respond independently. The platform coordinates the agreement instead of assuming it.

02

Credits were farmable

First version

Credits were earned for creating a project, with a value the creator could set.

The problem

Both are gameable — post ten empty projects, collect the credits, inflate the value to attract applicants.

What I changed

Credits are earned only at completion, at a fixed platform-set value, per role. The reward now tracks real work rather than activity.

03

An onboarding step that couldn't be answered

First version

Onboarding asked whether you were joining as a creator or a collaborator.

The problem

Nobody can answer it — everyone on Colab is both. The question forced a choice the product doesn't actually make.

What I changed

Removed the step. Onboarding now asks what you do — your roles and skills — which is answerable, and which the app can use to match projects.

04

Dispute was offered too early

First version

When a collaboration went wrong, "cancel" and "open a dispute" sat side by side as equal choices.

The problem

Handing someone the dispute option upfront invites escalation before anyone has tried to resolve things calmly.

What I changed

Made cancellation the default and dispute a fallback — the design should guide people toward resolving things calmly, not hand them the nuclear option first.

Conclusions

What I took away.

  • Product thinking comes before pixels.The decisions I'm proudest of — held payments, the cancellation fix, the credit system — were about how the system behaves and whether it's fair.
  • Lead with why before what.The strongest parts of Colab came from asking how something should work before designing how it looks.
  • A system beats instinct.Once I had tokens, a type scale and components, decisions got faster and the product got more consistent — I stopped choosing spacing by eye.
  • The happy path was the easy part.The scenarios around it — a rejected applicant, a stalled collaboration, a payment disagreement — needed far more thought.
  • Design the language, not just the interface.How something is worded changes how it feels to use.
Full deck

All 39 slides.

The curated story above pulls the highlights. Here's the complete presentation — tap any slide to view it full-size.

Close ✕