cbeasley
Published in

cbeasley

Case Study: Paddle Player Mobile App

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.

The Problem

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.

The Solution

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.

Discovery

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.

User Research

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

  • 88.9% of them received match information from their captains.
  • 89.5% would like other, easier, options to get paddle match information and 65.2% of users would like that to be on a mobile device.
  • 73.7% of users thought it would greatly improve their match experience to have directions to paddle huts on the app.

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:

  • SCAMPER
  • Worst Possible Idea
  • Challenging Assumptions

Prototypes

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

Initial Wireframes

Testing

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:

  • Configuration and maintenance Tasks
  • Building of Statistic Pages — nonessential feature users requested
  • User permissions
Med- Fi Prototype
Med Fi Prototype

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.

Heuristic Evaluation Results

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:

  • Users found the system to be mildly confusing due to unclear user flows for the tasks.
  • Both users entered scores in the middle, giving the system ratings of 3 when asked about complexity. For most answers, users felt the system was easy to use and that other people would be able to use the system fairly quickly.
  • 100% gave a rating of “4” when asked whether they felt confident using the system.
Med-Fi Prototype

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.

Next Steps

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!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
C. Beasley

Content designer at eBay. I also write stories. Sometimes people read them. Buy me a Coffee! https://ko-fi.com/crbeasley