League Swype

Based out of Chicago, League Swype is a fantasy sports startup. League Swype’s founder, Darius, is on his way to create a fantasy sports hub based around payment collection and processing. Darius tasked us with making the process of signing up more user-friendly.

As a part of the team of three UX designers, I conducted research that revealed useful insights that served as a foundation for further ideation. With the help of the mid-fidelity prototypes, we tested our solutions and prepared them to be implemented by a development team.

Role:
  • UX designer
Length of the project:

4 weeks

Tools used:
  • Sketch App
  • inVision
UX tactics included:
  • Direct/Indirect Competitor Profiling
  • Unstructured/Structured Interviews
  • Affinity Mapping
  • Paper Prototyping
  • User Personas and Journey
  • Usability Testing
a mock up of an app dashboard a mock up of an app dashboard

Table of contents

Overview

Challenge

To be a viable product in the space, League Swype needed to be more engaging with users. It needed features that streamlined online fantasy sports beyond just inviting friends and doing money transfers. It also had a painful process for depositing money that needed to be addressed.

Outcome

Based on user research, we proposed three new features to enhance its usefulness and entertainment value of the app. For the painful money deposits, we designed a more transparent workflow so that users would know what to expect.

Define

Background

League Swype is a tech startup that aims to make online fantasy sports management and payment easy, fun, and engaging. When we jumped on the project, the product was in beta. This version included functionality to create a league, invite friends, deposit money, and receive payouts. At this point, the product was essentially a digital wallet with some basic user management.

current website recording

Screenshot of beta app

Constraints

“I know it’s painful [the money deposits]”, said Darius, the founder of League Swype. “I am hoping you can figure out a way around this”.

Recently, the payment processor League Swype’s beta was built around - Skrill - got acquired by PaySafe. This resulted in Skrill’s rules around accepting payments to change, in a way that made the process really painful and unclear for users. Users need to deposit money into their League Swype account so that they can pay dues to fantasy sports leagues that they are a member of.

financial structure

League Swype financial structure

To deposit money on a League Swype account, new users had to do the following:

  1. Create a League Swype account.
  2. Sign up for Skrill. This includes providing a full SSN, pictures of the front/back of a driver’s license, and a few more really invasive and manual steps. Signing up for Skrill for the first time also requires an approval process that takes an inconsistent amount of time.
  3. Deposit money into the Skrill account. This happens on Skrill’s website, not League Swype. Deposit fees range from one to six percent depending on the payment method.
  4. Transfer money from Skrill into the League Swype account. There is a four percent deposit fee applied in this process.

We needed to dig into whether or not using Skrill was a hard constraint. To answer this question, we looked into the following:

Within one week my team got to talk to two experts in AML (anti-money-laundering) and KYC (know-your-customer). We learned that although it is not legally considered gambling, the fantasy sports industry is under scrutiny and considered high risk by insurance companies. Without the insurance, it is difficult to get approved for a merchant account by most payment processors. We also looked into tokenization through Unikrn - a betting app for online gaming. Unikrn used tokens but also required a Skrill account, which led us to believe that tokenization would be another dead end.

Given time constraints and the level of available funding for League Swype, Darius and us made the call to move forward with the assumption that Skrill would be the payment processor backing the app.

Users

To make a great product, just working around the constraint of Skrill wouldn’t be enough. We needed to understand the primary users of the app, their motives, and what features would best serve them.

Through user interviews, we identified two main user types and their needs. During these interviews, we also extracted a lot of useful information that we incorporated into new feature ideas.

a man in a white t-shirt
The Owner

The owner is an individual player in a fantasy league. They own a fantasy team and want to be paid out accurately.

Pain points:

  • Irresponsible league commissioners
  • Having unclear wait period before getting paid out
a man in a white t-shirt
The Commissioner

The commissioner is responsible for creating and managing fantasy sports leagues. They set up the initial rules for a league, collect payments from league members, and handle payouts. They need to easily see who still owes money and nudge them to pay. Since commissioners essentially run the leagues, we felt that if we could attract the commissioners the owners would follow.

Pain points:

  • Having to keep track of league money so that it doesn’t get accidentally spent
  • Keeping track of who has paid their dues and who hasn’t
  • Having to text owners one by one to nag for unpaid dues
Other useful insights
  • Fantasy sports players love trash talking. It’s an enjoyable and fun part of the culture
  • Leagues typically follow common rules and don’t deviate from them much

Research

Our research included interviewing a total of eight users. Five of them were commissioners ages 21-41 with 6-20 years of experience of playing 1-12 leagues per season. Our research (coming up with interview questions, interviewing itself, and synthesizing the data) was a team effort. However, there was one piece of testing that I think is especially noteworthy.

At the very beginning of the research phase, we needed a better understanding of user priorities to validate the need for the main functionality of the app. The CEO originally validated his product idea by essentially asking "would you like this perfectly working tool?", which felt one-sided. Just because test subjects say they would like a fantastic tool doesn't mean that they would actually pay for it. We needed to understand what users saw as something worth paying for.

Racing games have a concept that no car you select can be perfect. One car might be faster but be harder to turn. One might be easy to turn but less durable. We wanted to mimic this core idea to see how users would prioritize potential value. We gave each interviewee twenty chips and asked them to allocate them between the three following categories:

1. Payout timeframe - How long do they need to wait to get their winnings?
2. League Pool Transparency - knowing who paid, how much is in the pool, etc.
3. Payout Fee - how much are you willing to pay for the above two?

Our results indicated that people cared enough about #1 and #2 to pay, and the transparency was the most important aspect of the three.

test result chart

Test results

Journey

After some thought, we decided that we could make the biggest impact in the first half of the user journey. Playoffs and payouts take a while to actually get to because of how long fantasy sports seasons are. We needed to focus on getting users signed up by creating a great first impression and high initial value.

user's journey map

Commissioner's journey. * simplified for presentation purposes


Ideate

Solutions

At this point, we had determined our two high-level goals. One was to smoothen the money deposit workflow. The other was to create features that hook users during the first half of their journey. We began ideating on potential solutions and validated them along the way through concept testing. We ended up throwing some ideas out and punting on others as potential future roadmap items. We came out with four implementations (one for depositing money, and three for product value) that we thought were feasible and would address the biggest concerns.

#1 The Skrill problem
screenshot of a page
image of a mand with a following quote: Oh, this does not sound shady at all! Fees charged by Skrill, oh, what kind of fees they're gonna charge?!

Current load funds screen

When we tested the current workflow with Skrill, we learned that users were confused by vague fee descriptions and the fact that there are fees on both League Swype and Skrill. We also identified a major usability issue. Users weren’t clear on how much money they had to spend to end up with the desired amount in their League Swype account. For example, to put $100 in a League Swype account, more than $100 needs to be deposited in Skrill due to transaction fees along the way.

Fee calculator

To address these issues, we developed a fee calculator that made it clear and explicit what fees would be applied, as well as how much money the user would ultimately end up within their League Swype account.

fee calculator

#2 The desirability problem

We wanted to make the app really useful for commissioners so that they’d be enticed to host their leagues on League Swype. We came out with three new features focused around the commissioner’s pain points.

Fun reminder feature

With this reminder feature, commissioners can select owners that haven’t paid their dues yet and send a group reminder. They can also choose the tone of the message they want, and the app will generate a fun message that they can then customize. Users mentioning their joy for trash talking during interviews influenced the light-heartedness of this feature.

reminder feature recording
payout set up recording

League rule templates

Since users mentioned that leagues typically follow common payout rules, we wanted to let the commissioner skip having to define those over and over again manually. Rule templates let a commissioner start a league with preset rules for payout structure.

League analytics

League analytics offer an advanced overview of everything that is happening in the league. Both commissioners and owners get to see information about other league members. This includes fun performance stats that could be gathered from a fantasy provider’s data.

image of analytics screen
image of stats screen
Link to the final prototype

Conclusion

After creating these mockups, we tested them again with users to gauge how impactful the changes would be if built. User feedback was really positive:

“I would be motivated to change the rules of my own league to conform to the features of this app”
“It's definitely easier than sending a text message out to everyone in the league separately”
“This is one of those features that I think could be a game changer for this app”

We handed off all of the necessary documentation for these features so that the development team could actually go and build them. We also left Darius with some notes on things that needed further investigation. We spent most of our energy focusing on the first half of the commissioner’s journey. If we had more time, we would have dove into:


Reflection

An interesting part of this project was that I had zero prior knowledge of fantasy sports. I thought this would hinder my ability to contribute to the project, but I found that not knowing was actually useful. It helped me to get users talking more. I think people have a tendency to believe that certain things are just commonly known so they can skip them. Yet, because of my lack of knowledge, I ended up pushing users for more information, which led to a better understanding of their thoughts and preferences.

For More

To cut the story short I have omitted a lot of details. If you have any questions or would like to see a particular artifact, please, do not hesitate to contact me at: iananoda.ux@gmail.com