A real money casual gaming app, MGPL — a UX case study
At Totality Corp, our core mission has always been to build products which help people to add fun into their lives. When I first joined Totality almost 2.5 years ago I was assigned for this particular project MGPL- Mobile Gaming Premier League where you can select the game of your choice and compete with real people and if you win the game you win the reward. We already had private beta 1 & 2 releases and had some users using the product now we’re planning to release the public beta.
I’ll be discussing how we solved challenges and designed MGPL from public beta to production serving 2M+ players. Keep reading.
Understanding the product
Product idea was very simple, product has a minimal game store where you can select a game of your choice and compete with any real opponent of your similar skill level. We matched players of similar skill based on elo rating system. You can either play with coins or play with real money.
MGPL basically had —
- Multiple games
- Different tournament types
- Play with coin or real money
- Skill based match-making
Below was the happy flow of core function in MGPL private beta 1 —
In further private beta releases this flow has been improved to reduce steps and make it a one step process. We further improved the experience in public beta of MGPL. Will get back to it, stay tuned.
Understanding the users
In my experience I’ve found that watching what our users do is much more helpful than actually talking with them.
We had just started and had around 10K users but it was more than enough to understand them. Our users were mostly in bracket of 18–24 and 25–34 age group, two different type of users had different needs and motivations. We wanted to focus our efforts so decided to first focus on 18–24 as it was our most engaged age group. Target persona was decided and our further developments were focused for this particular set of users.
We had analytics in place so understanding their behavior was easy. Analytics was targetted around one metric i.e. number of game plays. In our experience we’ve found that watching what our users do is much more helpful than actually talking with them. This doesn’t mean that talking didn’t help us, in fact it gave us a really good idea about their environment and established an emotional connect. This was going to help us in the long run. I made different buckets of users to talk to them —
- Highly engaged active players playing with real money
- Highly engaged active players who never played with real money
- Players who played first set of games and left
- Highly engaged players who left the platform
We had the set of indicators for high engagement using which we created buckets and talked with them one by one.
Why did I create these specific user buckets?
We all are big fan of Simon Sinek, so yeah asking why has been a ritual. If you haven’t joined him yet. Here’s a video for you .
Okay let’s get back to the point, why did I created these buckets? Answer is clear these were directly related to some of our biggest challenges. Understanding these users was going to provide a direction for us. We analyzed the analytics as well as the information I collected by talking to them to understand their
- Needs
- Motivations
- Pain points &
- Gains
After analyzing all the collected data, we found important user patterns which were going to change the shape of our product in future. We also found problems that users were facing with the current product.
Problems
After analyzing both quantitative and qualitative data we received, we had a huge list of issues, problems and feature requests which we had to work on before we release the public version.
This is the fun part where we use our ninja design techniques to find out patterns within the problems and come up with the potential solutions. After analyzing both quantitative and qualitative data we received, we had a huge list of issues, problems and feature requests which we had to work on before we release the public version. We cannot do everything at once right, we started focusing on the main issues and converged a bit more. We grouped our problems in 4 main categories—
- Brand awareness and Trust issues
- Transactions related issues
- Communication and Support issues
- Usability, Visual Design and UX issues
Brand awareness and Trust issues
We didn’t have a strong social media presence or brand identity, users were hesitant to put money on a new platform. We were doing things right and we felt that we need to have a strong brand presence as well to create a perception and a good impression in their mind. People were having doubts whether they’re getting genuine players or bots, they used to withdraw their winnings as soon as they get it. This was all indicator that we were having a significant trust issue.
Transaction related issues
Our product has a very high amount of transactions happening every second, some third party services were also involved in the payment infrastructure and if anything went down, people had to face some kind of transaction issues. We had our own wallet named MGPL wallet where people can collect their winnings to withdraw or add more money to play new games. So every interaction with the core function of product required some kind of money transactions and people had a lot of issues there as well.
Communication and Support issues
In an ideal world we should not be having any kind of issues, but in reality there are far more complexity involved than we see on the surface of any product. Although we try to minimize the moving parts within the system there are some issues that might still show up. We found that we were missing a clear and transparent communication with the users for the issues they’re facing and lack of necessary support to help them solve those issues. We were happy that we took it as a challenge to solve it within the limited resource and time constraints.
Usability, Visual Design and UX issues
We kept running the public beta and receiving feedback. We watched user sessions, observed how are they using the app and their repeated behavior in the app. Differences in user journey of a first time user vs a returning user. We also felt that there’s an experience gap when you are in app and when you hit play and open the game, it’s not seamless. Moving in and out from an app into a game and back to app. This happening multiple times in one session has rough and inconsistent experience.
I will be going through all of these main group of problems and how did we tackle them one by one. They’re interrelated, solving one issue was going to help solve another issue e.g. if we make our communications better it will help us increase the trust with the brand.
Solutions
We followed a very simple and natural process for problem solving. We have a lot of design frameworks and processes but thinking from the first principles never disappoints us.
We converged from having a huge list of issues, problems and feature requests to a very focused set of problems. Now it’s time to explore for the solutions that might work. We started asking questions like —
How might we build Trust for the Brand?
When we first faced this challenge I started researching about what is Trust and what is a Brand. Well, what’s the better way to understand any topic than to understand its definition first. I found some very interesting explanations, I am not going to go into depth of all of them but one particular explanation by Morton Deutsch, an American social psychologist is worth mentioning here —
“Trust” involves the notion of motivational relevance as well as the notion of predictability. If one has an expectation that something will occur and this event is of motivational relevance, then the concept of trust is often applicable. However the most common usages of the phrase “to trust” have the additional meaning that when the trust is not fulfilled, the trusting individual will suffer an unpleasant consequence. That is, the trusting individual perceives that he will be worse off if he trusts and his trust is not fulfilled than if he does not trust.
For our case that unpleasant consequence is losing the money. We realized that trust involved some risk but if that risk doesn’t end up producing an unpleasant result, trust gets stronger.
When you trust someone or something you take the risk for the expectation of some gain and there is a risk of loss. If you end up getting gain instead of loss, you build trust with them.
This has clear implications —
- We need to build some sort of risk aversion mechanism in our product for the new users so that they can try out playing with the real money and we ensure that they will get gain out of it. If we’re successful to build trust with them they’ll be less hesitant to put money in the platform.
- Our transaction and payment systems need to be reliable and should work as expected all the time.
- Consistent and transparent communications for any issue.
I will be coming back to how we implemented above solutions but let’s first understand another piece of puzzle, “Brand”.
Brand
When I started learning about the brand I came across tons of information. One that stood out from the crowd was a beautiful definition by Marty Neumeier, author of popular books like Zag and The Brand Gap.
“A brand is a person’s gut feeling about a product, service or company.” Influenced by visual aesthetics, sound of messaging and the overall positioning of the brand in the market
After learning and researching enough about Trust and Brand I was confident and has enough information and resources to now start working on the solution and design implementation part. Let’s look at the solution for building trust and brand —
Risk Aversion Mechanism
We designed a solution where we launched a level progress for the new user and as they play more and clear levels we keep bringing new levels for them. When they clear level they get some variable money reward. This unlocked the door for new players to play with real money and also for players who were highly engaged but didn’t try playing with real money before because of the risk involved and the lack of trust in the system. We also enabled this for our existing users, this came out to be very successful.
Level progress were small tasks e.g. 1st level was practice to be better —
“Play 10 matches with coins and win reward” we designed rewards to be variable and just enough for some matches. So that users can play some matches, experience the fun and build the trust with the product. We placed the component at the top of the home screen intentionally so that user can see it every time they open the app working as a trigger to take the action.
When users complete the progress they get a scratch card having a variable reward, users can then use this reward money to play some real money games without the risk of losing the money because this time they didn’t have to put their money, they got it as a reward. It was sufficient for some matches and we were now sure that the risk aversion has been done. If some user still didn’t put money after playing matches with reward money and experiencing it they’re sadly not the user for our product.
We saw a significant bump in our retention and engagement after implementing this design in the product. Below are some screens from MGPL showcasing level progress design—
“Building trust with a brand is a multifacet problem. Solving other problems like Transactions related issues, Communication issues, Usability, Visual Design and UX issues was all going to help build trust stronger with the brand.”
Now let’s look at what we did to build a brand and community around it —
Building Brand and Community
We started engaging with our users actively on social media platforms like Instagram and Facebook. We noticed that we were getting high engagement in Instagram so we focused first on Instagram in growing our community. I took it as a challenge to grow the community on Instagram. When I first started we’d around 4K followers on Instagram.
I ran small contest on Instagram and feature it on our app as well e.g. one of the contest was to score more than 2000 in Ball Blaster, a game in MGPL and post screenshot using #MGPLBlaster. We gave some coupons and featured winners in our Instagram story as rewards.
Players started participating and engaging with each other and with the brand. I also promoted our Instagram community through in app banners. We have designed communication channels to convey any kind of communication with our players. I have discussed about them in Communication issues part further.
Our Instagram community grew from 4K to 40K within some month. Our Facebook page grew as well. As we grew our user base, players and YouTubers started posting videos about MGPL on YouTube.
Transactions related issues
Our tech team worked hard to perfect the experience our users were getting while doing any transaction with the platform. It was definitely not an easy problem to solve but we knew it’s a big part of the experience so we had to focus on it and solve it.
We designed communication around different transaction states that we’d in the backend side so that we can communicate appropriate information for the current transaction state by being transparent with our users. In all transactions section we added relevant information for any issues happening with the transactions.
Any transaction goes with multiple states in the server before it sends a success response. If a transaction is stuck at any of the step we can tell our users what is the issue and a maximum time under which it should be resolved. So that users know what’s happening and have all the information, it helped us avoid support calls and messages.
Below is an example of how we managed 2 main functions of MGPL wallet
- Add money to wallet
- Withdraw money from wallet
Above cases were implemented in design for all transactions and was also available through support. Checkout below component, it shows one of the cases from above i.e. failed state while adding money —
Solving communication issues started taking shape after we implemented the communication in transactions and it helped us reduce the support queries significantly, improve the user experience and build the trust.
We further implemented clear, transparent and relevant communication where it was needed. I am going to show some of those changes we did and features we built.
Let’s dive deep into the solutions for communication and support issues —
Communication and Support
In MGPL most of our games were asynchronous which means that it wasn’t required for 2 players to be live at the same time playing the game. One can finish their match and submit score and we will match them later based on their skill level. This created some of the most significant issues related with matchmaking —
- When any player starts a new match, we search for the opponent for some seconds and it didn’t matter whether the opponent was found or not, match was started after the search time ends. This means it is possible that you’re playing and after you finish your match you’ll not get the result as we’re still finding your opponent or if opponent is found it is possible that he’s still playing and we are waiting for him to finish the game and submit the score.
- Matchmaking had cases like — Waiting for opponent, Waiting for opponent to submit the score or Waiting for result. Proper communication was required if players didn’t get opponent or their opponent never submits her/his score.
- There was a need to provide an option of support for any of the matches so that if players had some unexpected issues they can contact us.
- Similar support option was required for all transactions as well. Game playing, Matchmaking and Transactions were the core part of the experience and these need to have better communication and support.
- We needed more communication channels to promote our offers, announce some important information or run some promotional ads.
- We wanted a communication channel which could ensure that users have been communicated for some important announcements e.g. if payment systems are down or a new offer has been launched for limited time.
Let’s look at the solutions one by one —
Match Cases Communication
We first started with putting past matches in 3 main contextual groups —
- Pending Turns for challenges and tournaments
- Completed Matches
- Matches in progress
Tapping on any match card opens match details where a player can see what’s happening with the current match in detail.
In match details page we added contextual communication for different match cases. Match details page consisted below information —
- Current match state
- Option to investigate the issue or understand about the current match status further by tapping on it
- A quick comparison between player and opponent score using different score bar height
- Match ID with a handy copy cta which was helpful in communicating with support in case of any issue
- A dedicated help option to open support for the particular match
Help & Support
We integrated a dedicated help and support section having 3 main sections —
- Live support thread
- Last transaction quick preview, if any issue has been identified
- List of common problems with explanations
- How to use, Privacy policy, FAQs section
Most of the time, players were facing a known issues for that we provided a list of common problems which explained most of the issues for players. If a player faced any unexpected issue we provided a chat support as well.
We resolved players queries on top priority and these design changes helped to minimize them too.
So far we’ve discussed building Brand and Trust, Match status cases communication, Transaction cases communication and Support options for any issues players faced in any of the thing. Most of the main problems have already been solved, we went ahead to design new features which we were going to use in future for different type of communications.
New Communication Channels
We implemented some new communication channels which were going to help us announce important information on the fly. There were 2 main design components which we used —
- In-app Banners
- Announcement bar
In-app Banners
We designed In-app Banners intentionally to have a compact size and able to communicate any type of information, promotions or announcement. We placed it on the top in Results section of bottom navigation. We wanted to provide it a location where users navigate frequently so that they can see the updated set of information. We had 2 high traffic sections — Results & Play.
We didn’t want to obstruct the playing experience so we placed banners in the results section. Below is a screenshot from production app —
It is important for us to think design components in terms of scalability and systems. I have experienced it makes your life easy for live-ops when you design in app components scalable and based on a design system. You can focus on high impact design decisions instead of designing every time from scratch. I will be explaining the MGPL Design System in some future post. Now let’s look at another channel —
Announcement Bar
We wanted to make sure that the communication is delivered to all the users and they see it but at the same time we wanted it to be unobtrusive. We intentionally placed it just above the bottom navigation. Most of the time when there is no announcement that place has no UI element but as soon as we put an announcement it shows right up there making a change and users could notice it easily.
Announcement bar was placed just above the bottom navigation, it has different types depending upon the context. 2 most frequently used types were —
- Text based announcement
- Image based announcement
Both of the types have support for a CTA redirecting to the web or deep linked to a function within app. Announcement bar served perfectly as highest priority communication channel to deliver important announcement or to promote an action we wanted users to take.
We wanted to make sure that the communication is delivered to all the users and they see it but at the same time we wanted it to be unobtrusive. We intentionally placed it just above the bottom navigation. Most of the time when there is no announcement that place has no UI element but as soon as we put an announcement it shows right up there making a change and users could notice it easily.
This was a modular component having ability to show text or image at the bar, it has extended view when tapping on it which contains a CTA to relevant action. Expanded view was also dynamic and can have a full image with a CTA on top of it or can render simple HTML. We were able to have control on the formatting part even though the text was all dynamic.
Both In-app Banners and Announcement Bar helped us communicate all types of dynamic information. It was highly required given the very dynamic nature of the product. We also used these channels to promote actions which we found was important for users.
Let’s now discuss about another important problem —
Usability, Visual Design and UX issues
We improved user experience by fixing and improving things one by one, remember the core function user flow I discussed in the beginning we started with fixing that first —
We wanted to minimize the steps and reduce friction from playing a game as much as we could. Performing the core action — playing a game, with just a single tap is the ideal flow for us. Playing a game was the most frequent and most used function of the app as well.
We replaced steps like selecting match type and selecting denomination with default preset of match type and denomination relevant for the user. If user has played with a custom match type and denomination, we showed them their last played preset next time, they just need to hit Play and start the fun.
Playing a game has become a breeze, our users used to play same match type multiple times before switching to a different game, match type or denomination. A single Play CTA, your last played match always ready when you launch the app came to be very handy. We put a quick Game Selector to the left of the Play which was intentional serving 2 important functions —
- Indicating which game you’re going to Play when you hit play
- Quick switching between your favorite games
Match selection and Game playing was effortless and it worked really well.
Now, another area where we found an opportunity to improve UX was the end experience after playing some games on the platform. You can’t obviously win 100% of your matches because of the skill matching in place. We observed impacts of losses and wins on user’s behavior. When we started researching about it, we found a great study by David Kahneman & Amos Tversky —
Loss aversion is an important concept associated with prospect theory and is encapsulated in the expression “losses loom larger than gains” (Kahneman & Tversky, 1979). It is thought that the pain of losing is psychologically about twice as powerful as the pleasure of gaining.
So how might we make users celebrate wins and forget losses?
We started to remove the word lost or loss from the communication in all instances where a player couldn’t win the match. We also started to communicate more prominently their wins, idea here was to create a strong visual memory of winning to shift user’s focus from losses to winnings.
We would also not show the match denomination where players came 2nd so as to avoid communicating the amount of loss. Basically we created friction for users to understand losses and made gains highly visible and prominent. Check below example for how we communicated their wins —
When users launched their app after sometime and if they win the matches we showed their cumulative wins since last session on the app launch. Creating a wow moment for the players, when we first tested this with users we could easily see the happiness on their faces whenever this popup was displayed as it means victory. It was high contrast and intentionally designed to have a high visual recall so that player remember their wins.
This was truly a fulfilling experience. We learned that when you find opportunities to celebrate user’s success, making it grand can create a wow experience for the users.
Moving onto the next change which we made —
Player Stats
Our players had a hard time figuring out their own performance and their opponent’s performance over time. We thought to provide some metric which will allow players to understand how are they performing in different games. We also made it public so any player can see these stats of any other player. This came in handy to compare yourself with your opponent.
There were 3 main metrics on the stats card — Best Score, Win Ratio, 1 vs 1 Victories for each game. Players can explore stats for all the games, compare it with their opponents and figure out their strengths and weaknesses.
We also used a consistent visual design language throughout the redesign process, we named it MGPL Design System. You can check all of its components on behance project.
Visual Design Language
We wanted a very consistent design language for the MGPL Brand. It needed to have aesthetics similar to a gaming app, should’ve a distinct visual identity and look premium as it involved real money gaming.
We started with designing the most basic components and finalising them and overtime we developed the whole design library and system. I will not go into the details of it here, it probably needs another article. Below you can checkout some components from the MGPL Design System —
When we implemented this design system the result was a very consistent designs throughout the product.
And I think now we’ve reached to the end of the story. I loved designing MGPL as it was truly a unique product to design, has multiple aspects to its experience and challenges were exciting. Now if I see back and analyze the things that I have worked on, list will never end.
Thank you for reading to the end, I hope you enjoyed your time on this story.
The Design Team behind MGPL
I would love to thank the founder Anshul Rustaggi, co-founder Paritosh Gupta, my design lead and mentor Utkarsh Khatri and Game Design Artist Dimple Dhanwani for helping me out with so many things in the process, it would not be possible without you guys and I’ve learned so much. It was a tremendous learning experience for me working on the project. We worked together day and night to make MGPL a great experience.
Let’s Connect
Connect with me on Instagram and we can discuss cool stuff there —
Are you on Twitter Design? Hmm I am there too [ sometimes ] —
Checkout Dribbble for interactions and UI shots —
