top of page

Baddy Buddy - Book courts at ease

The Baddy Buddy app provides a digital mobile solution to help book badminton courts at ease. Goal is to keep the booking coordination simplified and to focus on the joy of playing sports!

baddy buddy portfolio_b.png
​

Role:

​

My role was to research understand user needs, their pain points through user interviews and deliver a mobile app Design that will provide users with an easy user interface to book courts for a badminton organization.

​

Users and Audience:

 

The target audience are young adults and all other age groups who play badminton at a specific establishment. The players will be provided the info to access the mobile app that helps them check courts availability, choose their convenient time, and pay and make a reservation. They will also be able to share the booking confirmation with their fellow players!

​

The Discovery:

​

Using research and interview questions to understand user mental models with a few sample users, listening to their issues and pain points and practicing asking interview questions that do not add bias to the user’s responses.

​

User painpoints included:

1. Inability to easily book and find out through email communications.

2. Multi step approach through a manual process to reserve.

3. No fast app available to do it quickly.

The Problem

The badminton courts digital solution to book will have to show real time availability via a managed database that has to be setup with the management which is currently a very manual process. 

Mobile App

Enabling Badminton

Happy Sports!

Journey Map

journeymap baddy.png

Competitive Analysis

I looked at a few fitness and class booking apps to get inspiration from. I took inspiration from the AKT app that allows availability lookup and time reservation similar to what is required on the app I am designing .

Explore

Exploring user needs

The Process: Design by Iteration

It was important to concise the problem and map out what is most important to deliver towards this design solution. This was done through user interviews, working on Journey and empathy maps, doing user research analysis, and figuring out what I can provide as a simple but functional deign.

 

Once scope was confirmed, I worked on defining user stories, sketching out user flows and defining the information architecture and general structure of the designs. 

 

Next step was to work on wireframes in low fidelity to get a general idea of how I’d like to have my designs done. After which I moved on to create the high fidelity wireframes & prototypes. 

It was important to receive feedback on the wireframe and prototypes and document it, so I could understand the gaps and work on enhancing them. This iterative designing helped achieve something that looked more clean and aligned to the design goals.

User Requirements

  • Why: Business requirements Ability to provide an easy way to manage court bookings and a way for users to see avaialbility.

  • Who: User requirements outline who wants the why.

    • Badminton members would like an easy way to book through an app.

    • Management would like an easy way offer court bookings to their regular members

  • What: Functional requirements

    • User should be able to see available court and times..

    • Booking availability should be close to real time.

    • User should be able to pay to confirm booking

Storyboarding

baddy buddy storyboarding.jpg

User Stories

  • Scenario#1: See available court and times.

    • As a user ​I should be able to look at available courts and time available

  • Scenario#2: Pay to confirm booking

    • As a user I should be able to pay and confirm my booking.​

  • Scenaio#3: Share booking with friends​

    • As a user I should be able to share the booking details with my friends via email ID sharing.​

User Flows

Prototyping

Test & Improve

Improvement Areas:

  • Users wanted the ability to share - this led to including email ID sharing in confirmation page.

  • Users did not particularly love the initial header that was small and not fun. Updated the header size and image.

  • Users would like to pay later - Great functionality but not for MVP.

  • Users wanted a way to come back/sign up - Great functionality but not for MVP.

​

Positive Feedback:

  • Users liked the simplicity of the app.

  • Users liked the ability to pay and get immediate confirmatiom.

  • Users liked court availablity indication by color and layout.

  • Users wanted the ability to share - this led to email share on confirmation page.

  • User testing helped clean up the design, understand important flows and keep it simplified, and to understand how this can be scaled.

Wrap up

     Through an iterative process of design and user testing and feedback, we were able to achieve a design story for the Court booking system that focuses on simple, clean and functional flows. Next steps will focus on development, feasibility checks, flushing out development details and providing with you a good app to kick start with. Collaborating with full stack developers who can help create the database and  UI.  Collaborating with Admin team of courts to figure out schedules and restraints.  Marketing the link to the app with a set of beta users who could be regulars at the club to use the system in initial hours before releasing to a larger public.  Providing exception and detailed designs for developers for any edge case scenario that maybe required to represent on the UI

Long term goals will focus on scalability of the function and upleveling the design.

bottom of page