.png)
Role: UX/UI Designer
Responsibilities:
User Research | Problem Framing | User Flows | Wireframing | Branding & UI | Prototyping | Testing
Tools:
Figma | Miro | Whimsical | Pen & Paper | Maze
*This project was designed for educational purposes only.
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.
I also analyzed three local competitors and two apps for benchmarking purposes (Rally Tennis and Tennis Pal, available in the US only).
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:
"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."
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.
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.
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.
Once I put all ideas on paper, I needed to narrow it down to find the most feasible and main features of the MVP. Firstly, I organized the features by categories and then used a chart to cross the number of users that would use the feature versus the frequency, which helped me to prioritize them.
By prioritizing the most feasible and essential features for the MVP, I was able to define a features roadmap.
After mapping the core features of the app, I used part of the Jobs to be Done method to prioritize the main task and related tasks users would do when using the app. With that, I also designed a site map for the application.
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.
.png)
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.
.png)
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.
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.
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.
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.
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:
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.
I created components for the main elements of the app: buttons, form fields, nav bars, cards. This allowed me to keep visual consistency while designing hi-fidelity screens.
After discussing the best layout options, I started designing hi-fidelity, applying components and colours to the wireframes.
View Figma file
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.
With the research results in mind, that pointed to a higher level of importance for level and location, I prioritize some elements:
Method: unmonitored test using Maze, followed by a quick chat with a few testers. 11 valid answers.
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.
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.
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.
40% of testers ended up skipping fields when scheduling a match. In order to improve usability, I added error states when user skips required fields.
I substitute the verification checkmark from outlined to a filled icon, and added a title before introducing the game tags, as two users mistaken them as buttons.
.png)
.png)
.png)
