Go Back To Home
SPORTSCOVE | March 2025 - October 2025

Rebuilding a dual-sided marketplace for launch

I audited and redesigned Sportscove's learner and coach experiences, building a shared design system and reworking the core discovery, booking, and onboarding flows for launch.

My contribution UX audit · Research synthesis · Information architecture · Interaction design · Design system · UI design · Prototyping
Sportscove platform overview
Project overview

Bringing structure to a product three months from launch

Sportscove is a sports coaching marketplace connecting learners with coaches across the US, Canada, and India. With three months until launch, the product had an incomplete set of screens and flows but no consistent system tying them together. I was brought in to audit the experience, identify the highest-risk gaps, and rebuild the core product foundations.

Role
UX/UI Designer
Timeline
3 months to launch
Team
2 designers, 3 developers, CEO & advisors
Constraint

The initial design window was one month, so I had to prioritise the highest-impact product decisions and establish reusable patterns quickly.

01 — Diagnosing the product

The existing product had pieces of the experience, but no clear system connecting them

I started by auditing what already existed rather than redesigning screens in isolation. I reviewed existing research and testing, walked through the core journeys myself, benchmarked comparable marketplaces, and worked with the CEO and developers to understand what mattered most for launch.

Existing research
Learner + coach interviews
Product audit
Screen & flow gaps
Usability review
Journeys + heuristics
Competitive review
Skillest, CoachUp, ADPList

What the existing research gave me

With launch three months out, I used the team's existing learner and coach interviews as a starting point rather than restarting research from scratch.

  • Existing interviews provided directional insights, but some questions were hypothetical or feature-led rather than grounded in recent behaviour.
  • I supplemented them with product auditing, usability findings, competitive benchmarking, and stakeholder discussions.
  • With limited time, I focused research effort on decisions that could materially change the product.
Where I found gaps in the existing research
View the original questionnaire used →

A few of the questions I would have changed across both interviews, not the full list.

Learner research

What they asked What I would ask instead

✕"If you could design an app for training with certified coaches, what features would you want?"

✓"Tell me about the last time you tried to improve at your sport. What did you do?"

Why

A wishlist of features reveals what people think sounds good, not what actually helps them improve — a real attempt surfaces what they tried, what worked, and where they got stuck.

✕"Do you think learning in a group would be beneficial for you?"

✓"If you were booking a coaching session for your sport, would you want it to be one-on-one or with other learners? What would make you choose one over the other?"

Why

A yes/no question about whether group learning is "beneficial" asks users to evaluate an abstract idea. Asking them to imagine an actual booking decision makes the choice concrete and reveals why they prefer one format, whether that is individual attention, learning from others, social interaction, cost, or something else.

✕"What factors would make you choose one coaching platform over another?"

✓"Tell me about the last time you were deciding between a few different coaches. What made you hesitant about any of them?"

Why

Asked as "what factors would make you choose," this is hypothetical and invites a generic list like price or reviews — asking about real hesitation surfaces the actual trust gaps a coach profile needs to close.

✕"What do you look for in a sports coach?"

✓"Think about the last time you compared a few coaches before choosing one. Walk me through how you compared them, and what ultimately tipped it."

Why

A general checklist answer isn't tied to any real decision — walking through an actual comparison surfaces the process itself, which is directly useful for designing how multiple coaches get shown side by side.

Coach research

The coach interviews were more grounded in real coaching experience, but I would have pushed further into how coaches currently acquire, manage, and retain learners.

What they asked What I would ask instead

✕"What are your biggest challenges with virtual coaching?"

✓"Tell me about the last virtual session that didn't go as planned. What happened?"

Why

"Biggest challenges" invites a general, abstract complaint — a specific session surfaces the real friction point and exactly how it played out.

✕"What factors would make you choose one coaching platform over another?"

✓"How do you currently find students, and what does that process look like from first contact to booking?"

Why

Most coaches hadn't used a comparable platform, so comparing them was hypothetical — mapping their actual acquisition process reveals what a platform would genuinely need to support.

✕"What would your ideal sports coaching app look like?"

✓"What tools or workarounds do you currently use to manage your coaching?"

Why

"Ideal app" invites wishlist thinking disconnected from reality — current workarounds reveal what's actually missing and what they're already solving for themselves.

✕"What tools would you like to see to bridge the gap between virtual and in-person coaching?"

✓"If you teach more than one sport, tell me how you decide what to offer a new student, and how each sport shows up when someone's looking for a coach."

Why

Multi-sport coaching wasn't asked about at all, even though it later becomes a real design problem — how a coach's sports get shown on a card. Asking it here creates a direct line from research to that decision instead of the logic appearing out of nowhere.

One product question remained open
Learners
1Sport
2Skill level
3Goal
4How they find coaches
5How they compare
6What builds trust
7What happens after booking
Coaches
1Sports taught
2Learner types
3How they find students
4How they manage sessions
5Marketplace frustrations
6What would make the platform valuable

This would help answer a larger product question:

Larger product question

Should Sportscove offer one universal coaching experience, or should discovery and booking adapt to the learner's sport, skill level, and goal?

What I would explore with more time
1

Survey

Identify patterns across sports and user types.

2

Interviews

Understand the behaviours and motivations behind those patterns.

3

Segmentation

Sport × Skill level × Goal × Coaching format

4

Product decisions

Use those findings to determine what should be universal across Sportscove and what should adapt to different user contexts.

What the product audit surfaced

I audited the existing screens against the product requirements to flag what was complete, incomplete, or missing.

What I found
  • Incomplete end-to-end flows
  • Missing key product states (error, empty)
  • Gaps in session, task, and account management
  • Subscription experience missing key scenarios
  • Limited consideration for different user types and contexts (new vs. returning, active subscriptions, past activity)
UX audit table showing required screens, existing screens, status, and missing screens by product area

Walking through the old flows end to end

I walked every core flow as a first-time user and reviewed it against standard usability heuristics.

What I evaluated
  • Navigation & wayfinding
  • Consistency across patterns
  • Error prevention & recovery
  • Feedback & status visibility
  • Task completion & continuity

The end-to-end review surfaced patterns that isolated screens hid.

What stood out
  • Features existed but were difficult to reach
  • Inconsistent wording across interactions
  • Same entity displayed differently
  • Key info placed before the decision
  • Visual styling varied across flows

Learning from testing already completed

Prior testing on the existing design pointed directly at several problems the redesign later addressed.

Learners wanted to see a coach before completing a self-assessment
Satyanshu Singh
"I don't want to do my self assessment now. Can I not just see the coach profile without it?"
The coach profile felt really cluttered and hard to scan
Tanner Smith
"The coach profile has way too many things that I really don't know where to look"
Uncertainty around individual and group sessions
Priya Malhotra
"Is group session and individual session the same thing taught but in group and 1 on 1?"
The booking filter existed as a button with no screen behind it
Devraj Oberoi
"I tapped filter expecting to narrow things down by price or rating, and nothing happened. I just gave up and scrolled."

Competitive signals

Skillest and CoachUp were the closest competitors, with ADPList reviewed too for its similar (if not sports-specific) mentorship model.

What I found
  • How intuitive and complete the overall experience felt
  • What built a sense of trust
  • How accessible the experience was for different users
  • How well the platform supported ongoing use, not just a single transaction
  • How balanced the experience was for both sides of the marketplace
Competitor comparison across CoachUp, Skillest, and ADPList, with opportunities identified for Sportscove

Business constraints

I ran a prioritisation session with the CEO to rank flows by business impact, then synced with developers to confirm what was realistically buildable in three months.

Why the platform's mission shaped who came first
CEO
"One of the biggest reasons for making this app is to encourage retired people to find a place to share their skills and earn."
Why coach-side flows got equal priority to learner-side flows
CEO
"The coach side was a big part of the product, since this is where coaches would sign up, verify their eligibility, build their profile, and set their prices"
Why the design system became the first priority, not an afterthought
CEO
"We need a system to maintain the design and make sure all screens look like they're part of the same app."
Why the system needed to be developer-facing too, not just visual
Developer
"A design system could be helpful so that the button sizes, component spacings, colours and styles used can be easily executed."

This made the design system a product priority, not a visual cleanup exercise.

02 — Connecting the findings

Four connected problems were holding the product back

A product and UX audit, competitive benchmarking, and conversations with the CEO and developers surfaced four connected problems. The decisions that follow trace back to these gaps.

01
System problem

No shared foundation

No shared components, colors, or patterns existed, so every screen was designed from scratch.

02
Learner problem

Core flows lacked clarity

Inconsistent navigation and ambiguous screens made it harder to find information and complete basic tasks.

03
Discovery problem

Discovery ignored user context

Search needed to be more forgiving for less experienced users, while multi-sport coaches needed logic that let them appear across relevant searches.

04
Coachside complexity

Coach workflows were incomplete

The coach experience lacked clear structure across onboarding, availability, offerings, and the information learners needed to make a booking decision.

03 — Building the foundation

Before adding more screens, I needed to make the product easier to design

A shared foundation for designing and building at speed.

Design System

Consistency and efficiency at scale

The existing product repeatedly solved the same visual and interaction problems from scratch. I established a shared design system with 60+ reusable components covering colour, typography, buttons, cards, and interaction states, giving design and development a common foundation to work from.

Color system Typography system
Component library
Impact: Standardised recurring patterns and states, reducing repetitive design work and giving developers a consistent implementation reference across the product.
04 — Simplifying the core transaction

Booking a coach was supposed to be the most important step and that wasn't easy

Booking was Sportscove's core transaction, but learners had to complete a multi-page self-assessment before they could even see a coach's availability. The journey added several steps before users could reach the decision they came to make.

The redesign separated finding the right coach from understanding coaching needs. The self-assessment was not the problem. Its position in the journey was.

Old session booking flow
User flow
Old user flow diagram
Not working
  • Cluttered screens
  • Blocked path to coach
  • Sports split across 2 screens
  • No direct coach access
  • No skip option
New session booking flow
User flow
New user flow diagram
What changed
  • Self-assessment as banner
  • Multiple entry points
  • Visual cleanup
  • Sports in 1 screen
  • Filters added

Key screens redesigned

Home screen

From the initial interview, 80% of surveyed users were either open to exploring sports beyond their primary one or wanted to focus on one sport while still seeing what else was available.

I shaped the Home screen around this, surfacing coach visibility across sports through the Super Coaches and Popular Sport Coaches sections.

Old
Old home screen
New
New home screen

Coaches list

The initial interview showed that 100% of users used specific criteria when thinking about coach selection, including rating, price, experience level, location, and virtual or in-person preference.

The old filter existed only as a button with no screen behind it. I built the new coaches list around a fully functional filter based on exactly these criteria.

Old
Old coaches list
New
New coaches list

Coach profile

During testing, 80% of interviewed users found the coach profile messy and confusing, so I restructured it to make key information easier to scan.

2 of 5 coaches interviewed said they intended to teach more than one sport, so the profile now separates each sport and its details instead of blending them together.

Old
Old coach profile
New
New coach profile

Sessions screen

During testing, 60% of learners were unsure what separated a group session from an individual session. The two options sounded too similar.

I reworked the sessions screen so that distinction is clear at a glance, instead of something a learner had to guess at.

Old
Old sessions screen (placeholder)
New
05 — Making discovery context-aware

Making discovery respond to user intent

Sportscove was expanding into a wider range of sports and wellness categories, making a single browse-first approach difficult to scale.

Not every Sportscove user would approach discovery like a power user.

Design decision

Making multi-sport coaches visible without overwhelming the card

A coach's card should reflect the sport the learner is looking for

Coaches on Sportscove are not always specialists in a single sport. Some teach multiple disciplines, which created a discovery problem: how could a coach appear under every relevant search without turning the card into a wall of text?

Initial exploration

The first approach I tried displayed every one of a coach's sports directly on the card.

Coach card option 1 showing Boxing and Yoga tags
Option 1

Works with two short sport names, but becomes crowded as more sports are added.

Coach card option 2 showing Boxing and Muay Thai tags
Option 1 (With a longer sport name)

A longer name like "Muay Thai" still fits, but leaves little room for another sport.

Coach card option 3 showing Boxing and a truncated Muay Thai tag
Option 2

Truncation keeps the card compact, but makes the label harder to scan.

A simpler card, with smarter logic

Coach card before and after, showing the shift to a single sport plus a +N indicator

I landed on a +N indicator to keep the card concise while still signalling that the coach offered additional sports.

But that solved only half the problem. A multi-sport coach can surface under several different searches, so the first sport shown needed to reflect how the learner found the coach, not just how the coach was configured in the system.

Flow diagram showing context-aware logic for which sport displays first on a coach card
Homepage / no sport selected

Primary sport shown → years of experience for primary sport

Search: Muay Thai

Muay Thai shown first → years of experience for Muay Thai → remaining sports → +N

The card became context-aware: what it showed depended on user intent, not just coach data.

06 — Designing beyond the happy path

Designing coach onboarding for the real world

Coach onboarding was where the marketplace's two sides came together. A coach's profile, verification, offering, and pricing all had to become information a learner could trust and book from. The existing flow treated onboarding as one linear form, with little separation between those responsibilities and limited recovery when something went wrong.

01 / Restructuring the flow

I restructured the existing onboarding into clearer stages, separating profile, verification, offering, and availability so each step had a distinct purpose.

Old
Old coach onboarding flow: Profile, Verification, Course, Start Coaching
New
New coach onboarding flow: Pick Sport, Profile, Verification, Course, Schedule, Go Live
Mixed responsibilities → Clear stages
Profile-focused → Marketplace-focused
Linear setup → Coach readiness

02 / Testing what broke

I built a first prototype from the restructured flow and tested it with four coaches. The sessions exposed a gap in the model: the flow worked when everything went as expected, but had limited prevention, feedback, or recovery when it did not.

Completion state wasn't clear
"I thought I had completed it, so why can't I move forward?"
No way to pause and resume verification
"I don't have my certificate right now. Can I come back to this later?"
Verification requirement surfaced too late
"I filled everything out… and only now I'm being told I need to verify?"
Payout math wasn't transparent during pricing setup
"If the learner pays $100, how much do I actually make?"
No confidence that in-progress work would be saved
"I don't want to finish this right now, but I don't want to lose everything."

03 / Designing the missing states

The first flow mapped the happy path. Testing and a closer pass over the form surfaced the states and dependencies it had not accounted for.

Profile setup fields mapped against required, limit, conditional, and dependent-data behaviours

Required fields

Users could reach the end of onboarding without completing required fields, only discovering what was missing at submission.

Change

Required fields now have inline validation, with the flow automatically scrolling to the first incomplete field.

Inline validation message with the flow scrolled to the first incomplete field

Content limits

The About and Training Style fields had a 200-word limit, but users weren't aware when they reached it.

Change

The fields stop accepting text after 200 words and provide immediate feedback — "200-word limit reached. Additional text not added."

Conditional fields

Selecting "Other" as an affiliation required additional information, but the original flow didn't account for it.

Change

The form dynamically reveals a new field when "Other" is selected.

Additional field appearing after selecting Other as an affiliation

Dependent data

City was dependent on country, but changing the country could leave an outdated city selected.

Change

Changing the country now clears the existing city so the selection always stays valid.

Other screens worked on
Pick a sport screen Create syllabus screen, step 1 Create syllabus screen, step 2 Add schedule screen
Centerpiece

04 / Building a flow that could recover

The final onboarding flow brought the tested edge cases into one coherent experience. Required fields validate inline, conditional and dependent fields respond to what a coach enters, content limits are enforced as they type, and progress is saved so a coach can leave and return. The result is a flow designed to guide, prevent, and recover, rather than only work on the happy path.

Required fields Conditional fields Content limits Dependent data Save & return

The first flow accounted for the happy path.
The final flow accounted for what happens when it breaks.

07 — Beyond the core work

Beyond the core work

I also designed the splash and loading experiences to carry Sportscove's visual language into moments outside the core journeys.

Splash screen & spinner loader animations

  • Designed and animated the app's splash screen sequence entirely inside Figma, using prototyping and smart animate rather than a separate motion tool
  • Built a custom spinner loader animation the same way, so loading states felt like part of the same product instead of a generic default spinner
Splash screen animation
Spinner loader animation
08 — Outcome

From fragmented screens to a more coherent product system

60+
reusable components built once and reused across every learner and coach flow.
5 → 0
unresolved booking-flow issues — cluttered screens, blocked coach access, split sports, no direct access, no skip option — all addressed in the redesign.
~50 hrs
of redundant design work avoided across the 3-month build by not rebuilding colour, type, and button patterns for every new screen. (Estimate)
01

A reusable foundation

60+ components created a shared foundation for subsequent product work.

02

Shorter path to coaches

The booking flow removed unnecessary gating and introduced multiple ways to reach coaches.

03

More contextual discovery

Search, filtering, and coach cards responded to different user intents.

04

More resilient onboarding

Required, conditional, and dependent states were designed into the flow instead of being left to the happy path.

The result was a product that was not only more visually consistent, but structurally easier to extend: clearer flows, reusable patterns, and states designed for real usage rather than only the happy path.

09 — Reflection

What I learned from this

A marketplace can't be designed one side at a time: a coach's information architecture directly affects what learners can discover, compare, and trust.

Edge cases are product structure, not polish: testing onboarding exposed that the underlying model didn't account for conditional and dependent data.

The right abstraction matters more than the right screen: the multi-sport coach problem wasn't solved by adding more information to the card. It was solved by making the card respond to user context.

What I would explore next

With more time, I would go deeper on research segmentation by sport, skill level, and goal before deciding how universal the experience should be across different sports and wellness categories.

Go Back to Home