If you live in Chicagoland or New York, you may have heard of this crazy game called Platform Tennis. Basically, it’s a small tennis court enveloped by chicken wire and it’s a mix between tennis and racketball that you can play outdoors in the winter.

Every year from September to March, thousands of players from a hundred clubs travel all over Chicagoland to play platform tennis matches. Every week roughly 2,000 people travel across the city to play matches.

The logistics of these matches are challenging. Players need match schedules, directions to the paddle huts, weather forecasts, match times, whether there are delays, and cancellations. They need to know what food is being served. This information is not found in one place. It’s now organized by a mash of text messages, email, voicemail, and face-to-face interactions.

Clearly, paddle players needed an app to sort this information. They needed an easier way to perform these tasks than what the existing website offered. There needed to be an easy, mobile solution that considered the context.

Enter me. I designed the Paddle Player App to make the experience of playing on a platform tennis team easier, more social, and ultimately more enjoyable for players and team captains.

As the UX researcher and designer, I started the user research process. First I needed to clarify the design problem and scope. I defined and recruited the target audience, surveyed the competitive landscape, and jotted down the system goals.

The existing communication model for players was a mess– they had to slog through long email threads, SMS, phone calls, and a website without UX design.

I started with an interview protocol that aimed to answer two overarching questions:

How do league paddle players currently get match information?

What problems do they face when trying to get information?

I conducted seven semi-structured interviews for the generative research. Open-ended questions left room for discovery of the problems.

After I identified the existing offerings, I conducted background research and talked to players in the field to further narrow down a specific user population and their problems. This information went into the Project Brief.

In the project brief, I further defined the target audience and the problem. I conducted a preliminary overview of the competitive landscape and determined the system’s goals.

07 Interviews 25 Surveys 01 Field Study

It was time for some research! I conducted seven semi-structured interviews and created a user survey to dig deeper into why players behaved the way they did and what they wanted for their paddle matches.

I interviewed 7 people and incorporated observations along with direct questions (in this case observing how they completed tasks currently, using whatever tools or methods they happen to use).

I used an affinity diagram to analyze these research findings. Certain themes, trends, and needs emerged.

“The hardest part about the process is entering scores.”

-Rich, Team Captain

This research yielded the following findings:

Our users were team captains and people who played at least one match a week on a league team.

Scheduling and messages were the main issues to be solved for both groups.

There were league apps available, but none that loaded the paddle league information and none that were platform tennis specific.

A statement of system goals- specifically, users wanted easy, clear communication about match information in one place.

Survey & Interview Results

I identified the key user groups and key user tasks and built personas and essential scenarios for the key workflows.

Scenario #1

Chuck is in his car and needs to communicate the relevant match info (time, location, lineup, news) to his 10 players. He has a few extra minutes to do this before he drives home. He needs the most current information to get to all his players, ASAP.

Armed with an improved understanding of the users, their needs, and the requirements for the design, I tried to come up with compelling solutions to the problems I identified.

During this process I’ve learned that exploring multiple alternative ideas is critical to coming up with the best idea, i.e., that quantity is more important than “quality,” especially in the early going.

This ideation process included several techniques:

In preparation for the first user test, I chose to produce wireframes with Figma. In light of COVID, I thought it better to have wireframes I could test online and not have to risk the face-to-face interaction of a paper prototype.

The wireframes covered two categories: key screens and key navigation flows. The two key navigation flows were sending a message to teammates and creating a lineup.

Each stage of these flows was represented by a wireframe, and the connections between sequential wireframes were made clear.

01 — Send a message to and from teammates and captains.

02 — Find relevant, timely match information

03 — Find team and players statistics

Again, because of the constraints of COVID, I used Useberry.com to design and conduct unmoderated online usability tests. These tests included high-level goals and two essential tasks and a SUS post-test questionnaire.

Based on the micro-usability test, we needed to make fixes to the design. For this, we continued the next iteration with focused, small-scale sketching and ideation to explore different ways to address the problems of creating lineups and sending messages to teammates.

While the low-fi prototype focused on 3 key tasks, at this point I expanded the scope of the med-fi prototype to include support for another 2–3 tasks. These included:

Next, I performed a heuristic evaluation on the med-fi prototype to smooth out the rough edges of the design to make sure language was consistent, and task flows and layouts on different screens where appropriate. I made a prioritized list of changes to act upon for the next iteration of the prototype.

One more round of fixes and one more usability test- including video interviews, logging sheet reviews, statistical analyses, analysis of critical incidents, analysis of user flows, and heat maps yielded more findings and recommendations:

I looked at the task completion data and the heat maps from Userleap to round out the key findings. This data led to another iteration and finishing the hi-fidelity prototype.

After I finished the next iteration, it was time to hand Paddle Player off for development. It was also time for paddle players to get organized and have fun!