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.
As a design lead, I was heavily involved in all phases of the project, from defining the strategy to implementation.
My team and I helped GotCourts find new opportunities. That resulted in transformation of 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. We worked closely with them to create a vision for the product. The outcome was an experience strategy document that, basically, contained answers to three questions: where are we now, where do we want to go, and how do we get there.
The next step was to plan the qualitative research. 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.
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.
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.
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.
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.
Ideas for finding available courts using map. Here, adjacent results were suggested as a potential solution to the problem of court unavailability in peek times. This idea will find it's way into the final design.
The strongest idea for booking process that we prototyped, tested and refined lately. This sketch literally evolved into a feature.
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.
High fidelity prototype we used for testing. This one shows the last iteration for the booking screen.
The screenshot from one of the testing sessions. Here, we were testing the "happy path", represented in the user journey above.
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.
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 functionality, available in web and mobile apps for tennis players.
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.
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.
In-club scheduler was a new kisok product whose goal was to enable people to book a court while in the club (and make the platform more attractive to tennis clubs).
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 was a another product targeted towards getting more tennis clubs under GotCourts umbrella.
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.