One Operational Core
Connect bookings, payments, membership, attendance and content.
All projects
Product & UX/UI case study
Sports Club Operations and Facility Booking Platform
Sportshub
One Platform for Sports Club Operations
- Introduction
- A configurable digital ecosystem connecting member bookings, payments, attendance and club operations across four integrated platforms.
- Platforms
- User App · Responsive Website · Staff App · CMS Portal
- Role
- Product Design · UX/UI Design · System Integration
01
Project snapshot
The product, people and scope—at a glance.
- Project
- Sportshub
- Product Type
- Sports Club Operations and Facility Booking Platform
- Platforms
- User Mobile App / Responsive User Website / Staff Mobile App / CMS Admin Portal
- Users
- Club Members / Visitors / Frontline Staff / Club Administrators
- My Role
- System IntegrationProduct DesignUX/UI DesignPrototyping
02
Overview
One connected platform, from booking to billing.
Sportshub is a configurable sports club management platform connecting the complete journey from service discovery and booking to payment, check-in and attendance tracking.
Members use the responsive website or mobile app to book facilities, events, programmes and coaching services. Frontline staff validate reservations through the Staff App, while administrators configure facilities, schedules, pricing, booking rules and content through the CMS.
The product model is structured so each clubhouse can configure its branding and operational rules while retaining the same shared system.
03
The challenge
Turn fragmented club operations into one clear experience.
Club operations often use separate workflows for bookings, events, lessons, payments, attendance and communication.
The challenge was to create one reusable system that supports different club rules and branding while keeping member, staff and administrator experiences clear and connected.
04
My role & process
Map the operation before designing the screens.
I translated business and operational requirements into a connected product structure across member, staff and administrator touchpoints.
01Requirements Analysis
02Operational Mapping
03System Architecture
04Cross-platform User Flows
05Wireframes
06UI Design
07Prototyping
08Developer Handoff
Evidence note: This case study presents requirements, system architecture, flows and interface artefacts. It does not include participant research, usability-test results or post-launch performance metrics.
05
Product strategy
One system, four touchpoints.
One shared product core supports four role-specific experiences while allowing each club to configure its own branding and operational rules.
Role-specific Experiences
Provide focused tools for members, staff and administrators.
Configurable by Design
Support each club’s branding, facilities, schedules, prices and policies.
06
Member booking journey
From discovery to validated attendance.
A connected journey from member discovery to frontline validation and operational reporting.
07
Key modules
The operational essentials, organised by task.
A concise module structure turns a broad product scope into understandable groups for design and delivery.
01
Facility Booking
Availability, time slots, quotas, pricing and blackout periods.
02
Programmes & Coaching
Enrolment, private lessons, waitlists and sick leave.
03
Events & Ticketing
Registration, tickets and QR attendance.
04
Payments & Promotions
Payments, vouchers, promo codes and refunds.
05
Membership & Communication
Accounts, news, notifications and enquiries.
06
Staff Operations
QR validation, check-in, attendance and guest passes.
08
Cross-platform workflow
1 shared core,
4 focused platforms
A high-level view of how configuration, member actions, frontline validation and operational records move through the shared Sportshub platform.
User Mobile App
User Website
Shared Sportshub Platform
CMS Admin Portal
Staff Mobile App
09
UI showcases
Four role-specific interface systems.
The selected screens show how the shared product model is expressed across member, web, administrator and staff touchpoints.
User Mobile App
Discovery, booking, reservations, membership and QR check-in.
User Website
Responsive booking, events, programmes, accounts and payments.
10
CMS system flow
A complete operational path from login to reporting.
Authentication leads administrators into six connected management areas, with each module's actions, decisions and completion states kept visible.
Rectangle: ScreenRounded rectangle: User actionDiamond: DecisionDark node: Key destinationArrow: User movement
CMS entry flow
Authentication & Dashboard Access
The authentication path retains credential validation, error recovery, optional two-factor authentication and verified dashboard access.
- Visitor, Login Page, Enter Credentials, Valid?, Login Error, 2FA Enabled?, Enter OTP Code, Verify OTP and Main Dashboard.
Core management modules
Users, Facilities & Events
Each module starts from the shared dashboard, then follows its documented actions, decisions and completion states.
- User Management: Add user, Edit, Delete, Assign role.
- Facility Management: Add, Edit, Schedule, Bookings.
- Event Management: Create, Edit, Cancel, Register.
Service and reporting modules
Classes, Private Coaching & Reports
Each module starts from the shared dashboard, then follows its documented actions, decisions and completion states.
- Classes: Create, Edit, Enrolment.
- Private Coach: Add coach, Edit, Sessions.
- Report: Generate, Export.
CMS Admin Portal
Facilities, schedules, rules, programmes, events, content and reporting.
Staff Mobile App
QR scanning, booking validation, check-in and attendance.
11
Illustration system
Illustrations and product states.
12
Design output & reflection
Design the shared system before the individual screens.
Design output
The final design defines a configurable multi-platform foundation connecting member self-service, administrator control and frontline operations within one product ecosystem.
Reflection
Designing across four connected platforms reinforced the importance of mapping shared data, roles and operational dependencies before designing individual screens.