Skip to content Skip to footer

We know how to boost Gaming usability in no time

Quote At Migale, 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 —

Happy flow of 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?

Understanding users: user-buckets and direct impact on product

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.


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.

Notes of User’s feedback and comments & solutions that we implemented

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
Problems Affinity map

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.


A natural process of problem solving

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.

— Morton Deutsch.

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.



Leave a comment