Making the tennis game more enjoyable for tennis players and clubs

Watch a 37 mins talk about this project I gave in 2013


In 2012, GotCourts was an online booking system for tennis players that had thousands of players and hundreds of clubs in their system. They approached our design agency (Studio at Warp Speed) to help them rethink and envision possible futures for their product and services.

My role

As a design lead, I was heavily involved in all phases of the project, from research to implementation.


My team and I transformed the old system into a comprehensive platform for tennis players and clubs that consisted of web and mobile applications for tennis players, kiosk devices for in-court booking, and a web application for club management. GotCourts got the first investment based on the blueprint for the new platform. Our work helped the company to grow from a small startup to the largest racket sports platform in Europe.


To respect our client's privacy, the focus of this case study is on the process and methods we used during the project, rather than showing concrete findings and details.

The process started with stakeholder interviews to understand their roles, concerns, visions, how they define success and what would be their involvement in the project. Based on these interviews we framed the qualitative study. Over the course of two months, we conducted 25 contextual interviews with tennis players, in their homes, offices, and tennis courts. My teammates talked to more than 20 tennis club owners and managers. As an amateur tennis player myself, I participated in an amateur tournament where I spent most of the time observing and ruining the game for others because I overestimated my tennis skills.

Photo from an ameteur tournamet in which I participated as a player.

Interviews were the base for our research. We were interested in past and present behavior and asked participants to walk us through concrete, recent experiences they had. Sample questions we asked: "How did you book your session last week? With whom did you play?" or "When was the last time you played with someone way above or below your rank? Tell me more about that situation". The biggest problem we had was with recruiting. We didn't do a phone screening so we had to deal with participants that are not the best fit, and sometimes even discard interviews.

The research findings were extensive, so I will mention only a couple of key findings here. We've heard many tennis players complaining about scheduling during winter season, due to the lack of facilities. A common problem for players was finding the right partner, with just the right experience, skills and personality.

Analysis and synthesis

After the research, we had piles of notes, audio, and video recordings. Together with GC team, we went through the recorded material and extracted interesting facts, each fact on one sticky note. By the end of this process, we had one column of facts for each participant. In multiple affinity diagramming sessions, we were looking for patterns in behavior, by rearranging and regrouping the facts.

Eventually, patterns emerged and the mess started to make sense. These patterns formed five persona skeletons — five groups of facts that describe distinct behaviors. We translated these crude skeletons into five personas. Here, the primary persona is shown. In a similar process we came up with six “club personas” — distinct archetypes of clubs with specific sizes, policies, and procedures.

Bringing life into personas with scenarios and journeys

Personas were a lighthouse for the rest of the process, but standing on their own, they are quite static. In order to put a life into them, we created a set of scenarios for each. Scenarios were based on research data and constructed plausible stories that described a particular experience with the service. The scenarios enabled a sort of voyeurism necessary for empathizing with people behind personas. “A day in a life”, “Booking a court” or “Joining a tournament” to name a few.

One of the scenarios for the primary persona.

A set of user journeys has been created to visualize experiences that personas have with multiple touchpoints with the service. We focused on what personas do and feel, what tennis club does, and what service provider (GotCourts) does at each step in the journey. Below is an example of user journey map for the primary persona.

User journey for the primary persona, Emma, showing the "happy path" of finding a court, booking and playing.

Generating ideas

Through multiple group ideation sessions with the client, we explored myriad of ideas. At this stage, we aimed for quantity rather than quality — the more ideas, the better.

The goal was to explore the problem space by relaxing constraints and exploring not only plausible but also (im)possible scenarios. We shifted perspectives in order to go beyond obvious solutions, even to bizarre ideas.

Naturally, most of the ideas were discarded. The outcome of ideation was a solid number of good ideas and a shared understanding of what the product and the service could be. I wish we could've been more prolific, but since it took us a lot of time to conduct the research and synthesize it, we needed to move fast at this point.

Prototyping and testing

While still being immersed in sketching, we were choosing the strongest ideas, created quick paper prototypes and tested them. Turned out that the fidelity was too crude for the audience, so we moved to, interactive prototypes with Balsamiq and InVisionApp and we got far better results.

We collaborated tightly with engineers during this phase. As more and more prototypes got validated, we documented and annotated all the details, like interactions and edge cases. Engineers used this documentation as a detailed specification. Below is a part of a detailed specification for booking a court.


The final result was a comprehensive platform that included web and mobile applications for tennis players, kiosk devices for in-court booking, and a web application for club management.

Platform for players

Smart court search. Finding an available game became no-brainer even if a player couldn’t find a time slot or a partner. The system returns adjacent timeslots, nearby clubs and announcements from friends (see next pages). We made sure that it is almost impossible for a tennis player to leave the search empty-handed.

Easy booking. After finding a club, booking a court boils down to two clicks. Picking a time slot and confirming the reservation. The rest is done by the system.

Final designs for booking a court in web and mobile apps.

Waiting list. One of the delighters for both clubs and players. It enabled players to get notified if desired timeslots are freed and helped clubs minimize gaps in a schedule.

Player network. Finding partners and opponents was one of the major problems for users. We designed a player network where players get matched by location, interests, and self-assessed skills, handled by a complex algorithm.

Mockups that show how waiting lists work.

In-club experience

Kiosk app allowed tennis players to see a schedule and book courts while in tennis clubs. The device enables senior players who don’t have or are not comfortable enough with mobile phones or internet.

Info panels that were located at prominent spots in tennis clubs and allowed players to see who is playing and when is their slot, all while enjoying drinks and chat.

Kiosk app, showon on iPad device.

Tennis club management

Part of the platform dedicated to tennis clubs was incredibly complex. As I mentioned before, rules and policies in tennis clubs are diverse and complicated. One of the options was to offer them a solution that would simplify the rules accross clubs and unify the ways in which clubs operated. While that idea delighted tennis players, clubs were reluctant. So we decided to work with this complexity.

Club management system.

We designed a system for tennis clubs that focused on three key aspects. Analytics that allowed clubs to have better visibility, player management and managing complex rules and policies. The biggest problem we faced was that clubs operate in vasty different ways, and we needed to design an interface tht accomodates the differences. At the end we created quite a complex, but powerful interface.