One feature to rule them all! - UX Case study of how one feature gave Pelotea its new revenue model
Trying to understand how exactly we design, develop products and solutions can be very brain-heavy. But I have tried my best to present this journey in a graspable format for people from all walks of life.
Before we proceed further and in case you would like to skim through the whole information, you can directly jump onto the Design Process and Synopsis part to quickly understand the whole project work (Scroll down). Keeping it short, apt, sweet & simple, just for you. Yeah, you can thank me later for this! ;-)
Introduction
Pelotea used to be a traditional Soccer Field Booking Platform, but later it transformed into a League Management Software. And this was a turning point for them as Players & Visitors suddenly became extremely crucial stakeholders and potential assets for the platform. Pelotea’s CEO Diego did not want to miss this opportunity of utilizing this user-base. And this is where I was called in to help!
I always look forward to that feeling of pure bliss when the clients are happy and satisfied because we were able to solve their problems efficiently & accurately. And problems not just limited to the technical aspect of products & users, but also extending to the emotional, and business side of it. We were able to solve both, technical & business side of Pelotea’s pain points and I was as delighted as Pelotea’s team was, believe me! Such a relief. Huh!
Conquering the Difficulties!
Hey, before we go to the overwhelmingly positive part of the story. Let’s discuss the difficulties we were facing during the whole problem-solving journey.
Pelotea was suffering from serious user-retention issues with its players and viewers. According to the data we collected, the analytics clearly show that even though player sign-ups for the leagues were increasing, the weekly active users remained stagnant. There was simply no growth at all!
Whereas, the problems we faced on the design & development side were that Pelotea being a league management software was more focused on league managers and did not have enough features to engage its Players. Pelotea being a multi-product platform involved various stakeholders. Hence, F finalizing those engaging features which would increase user-retention, was the Real Challenge for us.
Yes, we had Constraints too!
Constraints are always there and that, too diverse in nature. They are the real problems one faces with respect to getting a task done. It can be a scarcity or limited availability, not having great ideas, lack of clarity, or just anything similar.
With difficulties and challenges being discussed already, how can we miss out on the limitations and constraints that we had to face during the whole process? Constraints which we had while we took on the task were -
Maintaining Rapport: Apart from accommodating problem-solving needs, we also had to cater to League managers, Sponsors, Team managers, Players, Fans.
Lack of manpower: Being in a startup environment, we had a tiny(3 devs 2 designers) but a strong team that had its limited functionality and capacity.
Time Constraints: All the major leagues were off-season, so luckily, we had 30 days in hand and on the roadmap to solve this very challenging player-engagement issue.
Technical Constraints: There were some serious technical complications with the existing product that had to be taken into consideration while designing features. Huh?!
All we had to do was to find a perfect balance, need and flow of work that would overcome all the challenges, difficulties and constraints. It was a journey worth it!
Oh, and if you think that we forgot to talk about the user, then that is because we did not forget, but it is rather a huge and diverse topic left to be discussed for later.
Now read on, to know how exactly did our expert team tackle this challenge Head-On!
Process
So, How exactly did we help Pelotea out?
Step 1: Initiation & Goal Setting
Going with first things first. As the beginning step, I always start with identifying the business problem and clearly define and write the various success criteria down.
In this particular case, the problem was to increase players' involvement with the platform. We utilized our first week to set up KPIs for success criteria, we created new events to measure the cohorts on Mixpanel and set-up video analysis using HotJar. Then we were ready to go to the research phase.
Step 2: General Research
We started by interviewing the top 20 most logged-in players to understand their behaviour. Creating a hypothesis was the most natural step here. So our hypothesis stated - ‘Users were most interested to see and share their results online. This made them more engaged with the platform.’ We started analyzing Hotjar videos and matching events in MixPanel. The points checked and verified with analytics to prove our hypothesis:
Analytics clearly showed that Players did frequently go to the match results page, but eventually lost interest as results were not being updated on time.
Step 3: More In-Depth Research!
There were few unanswered questions as to why the result panel wasn’t updated? and several other similar queries. Hence, we started with another round of research by interviewing League Managers about the challenges they face at the backend.
We discovered that:
League Managers used a number of complex sheets to manage results which covered a whole lot of information including fees, fines, injuries, stats, etc.
(Look at the picture below to understand how traditional forms were being filled, initially).
We also discovered that different leagues had different types of sheets. Meaning more sheets, more data & more boring record-keeping. Even for the league managers, tackling redundancy was a pretty boring & tiresome job. With information flowing all over the place, there was a significant gap in information update & record-keeping.
Step 4: Finding out a Suitable Solution
We understood that this can be an opportunity to create a major impact in League manager’s data recording, increase the ease of performing tasks and improve Player Journeys.
Below were the Solutions we planned to tackle this very gap -
New standard result sheet - A Printable Common sheet for all leagues that could be printed directly from the game page, including all the information like Player Names, Jersey Number, Accumulated Yellow Cards, Injury Reports, Payment Information, etc.
New Settings Panel - to customize the details of the sheet.
New improved responsive result input feature - to enable quick update of results.
Step 5: Work & Execution!
We had only 30 days design and build, So we carefully planned out our timeline
Started with a non-linear process with constant feedback from league managers.
Designed the new standard sheet with constant feedback from league managers.
Designed a new settings panel to manage the details of the sheet.
Designed new Result Input screens on the basis of the above-explained features and feedback.
Step 6: Performing a Beta Test
The next mandatory step was to do a Beta test with the leagues. This was a major feature that had to be perfect before we launched it for all the users. We did the following to ensure we had all the features perfectly in the place -
We selected 2 sets of our closest power users for our beta program, the first-set received early access for a few games so that they could give us their valuable feedback after testing the features on the ground.
Then we released it to the second set of users, while constantly monitoring Hotjar video recordings to help them out.
Once we were all satisfied, it was released as a major update, with tutorials for all the users.
Our team strived hard to achieve this kind of work by burning the midnight oil. Nothing could have been better than this! Woohoo! There we go. But, we still had to give this project it’s finishing touch-ups. :)
Step 7: Iterations
Design is never done, so we keep iterating with the combination analytics and feedback.
Some share-worthy results -
Remember in the first step, I defined success criteria with measurable KPIs, Yes? now it was time to test how we did.
There was a 300% increment in recurring traffic with player user-group, which clearly proved user-retention.
The new data collection method with multiple data points in the new standard sheet on the results panel gave us better insights into the platform’s performance, and analytics prove this part!
As we incorporated new injury reports on our platform. Selling Insurance became a surprisingly new revenue stream for Pelotea! This was a true ‘Wow’ moment for all of us. A total Smug face expected. ;)
Learnings:
“ Sometimes, A single feature can change the course of a product towards prosperity.”
Synopsis
A design case study about Pelotea’s transformation from a Traditional Soccer Field Booking Platform into a League Management Software.
The major Pain points included: Diverse User Portfolio, Engaging Stagnant Users & Growth, Simplifying Data Collection, Maintaining Rapport with various stakeholders: internal & external, and limited time, number & capacity of professionals working on them.
The following process was followed to solve the user - retention problem for Pelotea: Initiation (Problem Identification & Goal Setting), Research (both on the User side & the Platform’s side), Analysis (of the findings of research like any gaps or performance glitches), Execution (within a fixed timeline), Beta Test (with a few dedicated players to get first-hand information), Final Iteration (Repetition of successful strategies on various data points to achieve desired results).
Thorough research and analysis of the data and its findings help a designer solve the exact business problem. This does not just solve existing problems, but also lifts the veil from various other undiscovered problems and opportunities for a business just like Pelotea’s.
