M.Sc. Project · 2024-2026
SkillSwap
An end-to-end product design project, from research to a high-fidelity prototype.

01
The Challenge
SkillSwap is a mobile concept for trading skills without money. You teach what you know, you learn what someone else knows. The interesting problem was never “build a learning app.” It was designing the conditions that make peer learning actually happen: clear discovery, enough trust to reach out, and scheduling that does not turn into ten messages of back and forth.
How might we help people find a relevant exchange partner, judge whether to trust them, and book a session, all without money changing hands?
02
Understanding the User
I started by listening. A handful of short interviews with students and early-career learners surfaced the same story again and again: people want to swap skills, but the path from interest to a real session is full of friction.
I’d happily teach Photoshop if someone taught me German, but where do I even find that person?
I never message strangers unless I can see they’re legit somehow.
Half the time the chat just dies trying to find a time that works.
I know things people would pay for, I just want to trade, not sell.
Synthesizing those conversations, three insights shaped the whole product.
Discovery is not search
People rarely know the exact skill name. They need to browse and filter, with previews that make a match obvious at a glance.
Trust is the real blocker
No one reaches out until they feel safe. Credibility has to be visible before the request, not after.
Scheduling kills momentum
Exchanges die after the first message when coordination moves to chat. It has to live inside the product.
03
Meet the Users
Two personas kept me honest about who I was designing for, and they pull in slightly different directions, which made the trade-offs sharper.

Aisha
22
Student, new to the city
Aisha just moved to Göttingen for her master's. She wants to pick up practical skills like design and conversational German, but a student budget rules out paid courses. She is happy to teach what she already knows in return.
Goals
- Learn practical skills without paying for courses
- Find people nearby she can actually meet
- Offer a skill she is confident in as a fair trade
Frustrations
- Courses and tutors are too expensive
- She does not know who is credible enough to learn from
- Coordinating a time over chat never seems to work
04
Defining the Problem
Paid courses get expensive, content platforms feel passive, and communities are hard to navigate. Even when you find someone, the exchange falls apart without trust, structure, or a clear time to meet. So I framed a clear value proposition to design against.
A fair trade
No money, just a skill for a skill.
Visible trust
Credibility you can read before you commit.
Availability up front
When someone is free is part of the match.
Local or online
Both formats work, your choice.
Reputation that grows
Each completed swap builds standing.
Just enough structure
Guided exchange, not a paid marketplace.
I also audited how people currently learn skills. Each alternative solves part of the problem, but none covers fair two-way exchange, visible trust, and built-in scheduling together, which is exactly the gap SkillSwap targets.
| Approach | Free | Two-way | Trust signals | Built-in scheduling |
|---|---|---|---|---|
| Paid courses | ||||
| Content platforms (YouTube) | ||||
| Informal communities | ||||
| SkillSwap |
05
Information Architecture
Before designing a single screen, I mapped the full structure so every screen had a clear home: onboarding, a home dashboard, find-skill and post-skill flows, matches, profile, rate-user, and a settings menu. Getting this skeleton right kept the discovery and exchange flows simple later.

06
Ideation
With the structure set, I sketched fast and broad in low fidelity, exploring how discovery, profiles, and posting a skill could feel before committing to any visual direction.






07
The User Flow
I mapped the primary task flow with explicit decision points, the two moments where people drop off: whether they trust the person enough to reach out, and whether both sides can lock a time. Designing those branches up front is what kept the happy path short.
Onboard
Pick what you want to learn
Discover
Browse or search skills
Filter
Category, level, format, availability
Open a profile
Read the trust signals
Decision
Do the trust signals check out?
Send a request
Offer a skill back and propose a time
Decision
Do both people confirm?
Attend the session
08
Wireframe to Screen
The low-fidelity home was plain blocks: a “find a skill” search, a profile nearby, and quick actions to post a skill or check sessions. In high fidelity that same structure became a warm, scannable home, a personal greeting, a “Trending in Göttingen” feed, and a clear “Teach & Swap” split. Same skeleton, far more confidence. Drag the handle to compare.
Final
WireframeDrag to compare the wireframe and the final screen
09
Visual Design
Only once the flow held up did I move to visual design. A calm, trustworthy system: a confident blue primary, generous spacing, rounded cards, and clear hierarchy so the trust signals and the call to action always stand out.
Color
Primary
#2F6BFF
Ink
#0F172A
Slate
#64748B
Surface
#F1F5F9
Success
#22C55E
Warn
#F59E0B
Typography
10
Final Designs
The high-fidelity screens carry the exchange end to end, from discovery and search to a trust-rich profile, posting your own skills, and the request and scheduling flow.










11
Outcome & Reflection
Back to the two people I started with.
Aisha can now
Browse and filter for a free, local match, read trust signals before reaching out, and lock a time inside the request, no more dead-end chats.
Leon can now
Judge credibility at a glance, trade a skill he is strong in for one he needs, and book in a couple of taps instead of negotiating over messages.
This is a concept, so I frame the rest as what I would test next: less browsing effort because discovery filters around real exchange criteria, more confidence before connecting because trust shows up earlier, and less scheduling friction because availability lives in the request.
What I would do next
- Run a moderated usability test on the trust and request flow.
- Add in-app messaging and reschedule, then measure drop-off before confirmation.
- Explore a light reputation and time-credit system for repeat swaps.
SkillSwap pushed me past screens and into behavior. It is not hard because of visual design. It is hard because peer learning runs on motivation, trust, fairness, and timing. If I took it further, I would validate the trust model first: a peer product can look polished and still fail if people do not feel safe enough to reach out.
Want the full story behind this work?
Let's Chat