There are hundreds of public courts in Toronto, Canada, yet it can be hard to find tennis partners  with matching skills, availability, and practicing goals. Many people end up not playing as much tennis as they would like to because they can't find partners or available courts to play. Tennis Circle was designed to fill that gap and to bring the Toronto tennis community together.
The Challenge.
To design an MVP end-to-end mobile app that provides Toronto tennis players with assertive profile matchings and relevant information to improve their tennis experience.  Our goal is to unite the tennis community and make it easier to find players, courts, and join groups or tournaments.
Research Phase.

Market & Competitive Analysis


The project will be focused initially in Toronto and GTA (Greater Toronto Area). For the MVP, I started researching about the tennis market in the area.

  • Public courts rules and regulations;
  • Community and private clubs;
  • Groups and tennis leagues.


I also analyzed three local competitors and two apps for benchmarking purposes (Rally Tennis and Tennis Pal, available in the US only).

  • Top Spin app
  • Rankd app
  • ilovetennis.ca website

Key Findings

  • Most common ways of finding partners: joining a club, or Facebook/Meet up groups; tennis directory websites; or within your social network.
  • Toronto and GTA public courts are divided into two categories: public (run by the city), and Community Club courts (run by community clubs, with limited public hours).
  • Community clubs in Toronto have long waiting lists to join, and cost around $130 - $250 CAD per year. Private clubs can cost thousands of. dollars per year.
  • Most information about tennis tournaments, leagues, clinics, lessons, etc are often associated to tennis clubs or by word-of-mouth.
  • Both local apps are in an early stage phase; and the directory website looks outdated.
  • In common features for both apps include direct messaging; and courts/players rating system.
  • None of the apps offer the possibility to filter players, or find groups and tournaments.

1:1 User Interviews

Following the analysis, I interviewed three people that play tennis regularly in Toronto. They had different levels, ages, and profiles, but their concerns and needs when it comes to tennis were similar:

  • 3/3 interviewees mentioned level and location as the most important factors when searching for partners.
  • 3/3 interviewees said they are not willing to commute or travel far to play tennis.
  • 3/3 interviewees mentioned limited time, busy courts, and poor maintenance as the main issues when finding a location to play.
  • 2/3 interviewees struggle or had issues in the past finding players with same skills level.
  • 2/3 interviewees struggle or had issues in the past matching location with partners.
"A difficulty that I have ran into while searching for partners is that most people don't seem to know how to rate [level] themselves. I'm probably pickier in Toronto with the level of players simply because is so hard to get on a court."
Meet Emma.

I used the research findings to gather information about what a typical user tennis routine, goals, motivations, and frustrations would be, which helped me to create a persona to guide me throughout the project.

Framing the Problem.

Mapping Opportunities

  • With the research findings and the persona defined, I did an exercise using an experience map to identify potential opportunities to improve the user experience when searching tennis partners.
  • With this method I've learned that by increasing the precision on matching preferences and skills I would  be able to reduce users' frustration during the process of finding partners.

Root Cause

Although the experience map exercise helped me identify opportunities for improvement, I still needed to get to the root cause of the problem. So I used the 5 why's method to find it:

Tennis players struggle to find partners with similar levels and location preferences due to the subjectiveness of the self rating system and high demand for public courts.
Brainstorming Solutions.

To brainstorm solutions and features for the app I kept in mind the three main users' struggles (level, location, and availability). I used a mind map to put my ideas on paper and cover all possibilities. The idea here was to be as broad as possible to later narrow it down.

User Flows.
For the MVP, I designed three main user flows: new users onboarding; find tennis partners; and find tennis courts. To define these three main flows, I kept in mind the main task and related tasks I defined using the Jobs to be Done framework.

New Users Onboarding

This is where new users can set up their preferences for the first time after creating an account. For users that do not know their level, the app offers a multiple choice self-assessment tool based on the NTRP rating criteria. I decided to keep the NTRP rating because is the rating system used by Tennis Canada, and also community clubs and leagues.

Find Tennis Partners

This is the main flow of the app. Initially, the players tab was supposed to be the initial screen after opening the app. Filters are pre-filled according to the users preferences (set up on the onboarding flow) but can also be modified manually.

Find Courts

This is also an important flow for the MVP. It allows users to search for courts nearby and view details about the court, reviews, live waiting times, see which players are registered in that court, and add it as a home court.

Sketching Solutions.
After designing the main user flows, I started sketching a few screens. For the purpose of this project and for the MVP, I focused on main task of the app, to find players and schedule matches.

Find Players Screen


I sketched a few solutions for the find players screen. Initially, the idea was that this screen would be the initial screen after opening the app for users with an account.

A map view by default showing players nearby was the main idea, since user research has shown that location was essential to users.

Sketches Annotations

  • Sketch 1: Map view by default + Swipe up for list of players; filters + search bar
  • Sketch 2: Sections by category + scrolling right to view more options; map icon to view payers location.
  • Sketch 3: one single section with one column layout (scrolling down to view more); map icon to view players location.

Players Profile Screen

  • For the players profile screen, I wanted to show as much relevant information as possible without overwhelming users.
  • Most of the ideation was regarding the order and layout of information displayed, as show in the sketches below.

  • At his point of the process, player reviews were still a priority, and the main solution for validating players levels.
  • The checkmark in the profiles was also an idea for verifying players level, as research has shown that users struggle to find same level partners.
As I moved  into the wireframes, I was still exploring some options, as I wanted to share my ideas with some design colleagues. Their feedback helped made some layout decisions, and also made me changed my mind on a few solutions.
View all wireframes

Players Display & Dashboard

After wireframing and discussing the map view screen, I realized it could have an impact on user's privacy, so I decided to show the players matching in a list format. With that change in mind, I also decide to include a dashboard as initial screen, showing new notifications, specially those which need user action.

Filters & Calendar

I added filters to the players screen, because I wanted to give user's freedom to filter players according to their needs. I chose a combination of slider, toggle and tags for the filters screen, following some interactive design patterns for each of the selection actions. The same was applied to the schedule a match screen.

Find Players Screen

After showing these screens to design colleagues, their feedback helped me to decide to move forward with either the first or third layout from left to right. I made these decision mostly because of two reasons:

  • To reduce cognitive load, and layout number two seemed to be too packed with information and sections might be confusing for users.
  • To be able to display more than one profile at a time, to allow users to quickly scan the profiles before selecting one.

Players' Profile Screen

  • As this screen is a very loaded with information, I tried different layout options to be able to have an overview of what each one of it would look like in hi-fidelity.
  • At this point of the design progress, and after discussing with colleagues, I to replace  the players review for a badge recognition system, to encourage positiveness and for gamification purposes.
UI & Components.

For this project, I was also responsible for creating the branding and UI elements for the app. I chose to work with a royal purple and green as primary and secondary colours to transmit exclusivity and to differentiate from other tennis apps that use yellow or green colours as primary.  Also, the purple button with white text looks good both on light and dark modes.

Hi-Fidelity Screens.

After discussing the best layout options, I started designing hi-fidelity, applying components and colours to the wireframes.

View Figma file

Players Screen

As I moved to the hi-fidelity screens, I decided to go with the one column list layout for the find players screen. I made this decision because it allowed extra space to provide more information so the user can decide in a glance whether it is worth viewing the full player's profile.

Profile Screen

With the research results in mind, that pointed to a higher level of importance for level and location, I prioritize some elements:

  • Positioned the level and location at the top of the screen for more prominence;
  • Added an extra level classification in addition to the NTRP rating;
  • Prioritize the video section, as this can help users to have a better idea of the players level and style.
Testing the Prototype.

Method: unmonitored test using Maze, followed by a quick chat with a few testers. 11 valid answers.


  • Test the flow of searching and filtering players, with an emphasis on checking testers first click assertiveness, and how easily they would filter players.
  • Test the flow of scheduling a match, with an emphasis of gathering insights about the information provided in the player's profile.

Key Findings

  • More than 80% of testers completed the tasks with no major issues;
  • Only 54% of testers (6/11) clicked on the right icon to search for players on the first attempt. Common misclicks were related to other icons and buttons on the dashboar;
  • 100% of testers completed second task, 40% with only minor misclicks, like skipping fields.
  • Two testers were a bit confused about what the verification checkmark and the NTRP acronym meant.

Prioritizing Changes

With the testing findings in mind, I used a priority matrix to decide what to iterate on first. Making the find a player action clearer to users and clarifying the level verification and classification system were the priorities.


Dashboard & Nav Bar

The tests results showed that only 54% of testers clicked on the right "find players" icon on the nav bar on the first attempt. To solve this, I redesigned the nav bar icons and dashboard CTA's and buttons.

Verification Checkmark

Two testers didn't fully understand what the verification checkmark and NTRP acronym meant. It didn't prevent them from completing the task, but for clarification, I added a tool tip next to these elements.

Key Takeaways.


  • To design an end-to-end application can be tricky. This project helped me learn more about designing with an MVP in mind.
  • The importance of ideating throughout the entire design process. For this project, I applied more the double diamond framework of diverging vs converging ideas, which allowed to be more assertive.
  • How using components can make designing hi-fidelity screens faster and also help with keeping a visual consistency.

What I wish I have done

  • Started testing earlier in the design process.
  • Conducted A/B testing to validate concepts and patterns.

Next Steps

  • To test the prototype again after a few iterations.
  • To design the other flows and screens essential to the MVP.
More Projects.

Get in touch.