Designing a business dashboard for Mobile MSME’s — a UX case study

MJ (Murari Jha)
UX Collective
Published in
6 min readFeb 27, 2019

--

“2019 is a year of mobile for MSMEs (micro, small and medium enterprises). The network is built on mobile and since we (Instamojo) have always been a desktop-first platform, we thought this was the year we will focus on our mobile application which will give easy access to our merchants,”

Sampad Swain, CEO, Instamojo

Over 6 lakh businesses use Instamojo to solve problems like payments, shipping, loans, etc.

The Context & Problem

The Instamojo Android app was last updated two years ago. Over these 2 years, more MSMEs started looking for Instamojo on their smartphones and our mobile traffic doubled.

The Android app was initially designed as a companion app — it was to be used along with the desktop. But now, mobile-only customers wanted to access all Instamojo products on a mobile application.

Instamojo’s Old App Dashboard

Instamojo is a distinct fin-tech platform that offers multiple products. To cater to our mobile customers, we would need to bring all the products and services to the app. Eg: Online Store, Shipping, Smart Links, Next Day Payout, Instant Payout, etc.

How do we add everything while keeping the experience simple?

1. Research: problem & priority

“Talk to your users. They’ll tell you what they want.” — by @paulg

In collaboration with the analytics team, we pulled out a list of businesses that were:

  • Using Instamojo on mobile web but not on the existing Android app
  • Only using the Instamojo mobile app
  • From a variety of categories like travel, education, etc.

We sent out a survey to these users and spoke to the people who responded.

“First solve my problem and then I’ll talk to you” — a customer at Instamojo

This is why I love talking to customers, They always surprise you with new insights.

From the interviews we learned:

  1. Small businesses preferred the mobile app because it was easier to use
  2. Different businesses and their team members used the mobile app differently. For eg: a CEO of an online shopping firm checks sales and payouts, while employees manage other operational aspects like shipping, invoices etc.
  3. Many critical features were missing on the mobile app, forcing them to move to the web version.

2. Storyboarding: scope of user problems

To understand the scope of the problem and prioritize what we need to include in the new app, we started creating a storyboard.

Businesses are busy. They don’t want to waste time learning how to use the app and its features. It was important for the user to find the critical things immediately.

Storyboarding

3. CRUD: product coverage

C.R.U.D for Designing

Create, Read, Update, and Delete (CRUD) are the four basic functions used by developers. The CRUD paradigm is common in constructing web applications because it provides a framework for developers to construct full usable models. Read more about CRUD.

We used CRUD in design to make sure we cover every corner of all the products on the app. We listed out the products and features on our platform & broke them down under CRUD:

An example CRUD checklist we use to track coverage

In CRUD there are two categories “Manageable” & “Repeatable
CUD(Create, Update, Delete) falls under Manageable and R(Read) is Repeatable.

These help us cover complex scenarios, for eg:

  1. Facebook: You can “read” posts (created by other people) without creating and managing a post yourself. An example of unrelated workflows, where manageable and repeatable actions are not related.
  2. Bitcoin Wallet: You cannot “read” balance in a wallet without creating an account on it. An example of related and sequential workflows, where manageable and repeatable actions are related and have to be performed in a particular sequence
Manageable & Repeatable parts of CRUD

CRUD helps us make sure we’ve taken care of every possible scenario.

CRUD naturally splits the user experience into two parts:

FUE (First User Experience)

When a user signs up on Instamojo they land on the dashboard. At this stage, it is important for the user to make sense of Instamojo and start using it.

At this point we highlight:

  1. Onboarding Tasks
  2. Actions (Fab Button)
First User Experience Skelton

RUE (Repeat User Experience)

Other products take precedence once a business becomes an active user on Instamojo. For eg: How much money did I receive today? When and for how much was the last payout?

For active users we prioritized the following things:

  1. Reports (Sales and Payouts)
  2. Manage (Links, Payments, Cases, Store, Refunds & more)
  3. Actions (Fab Button)
Repeat User Experience, Skelton

4. Critical Design Decisions

When you are designing a mobile business dashboard for users you need to pay attention to a lot of things. Which items should we keep? Should we follow the native style? Should we break any rule? etc.

Handling complexity: Removing the tab bar

Tab bar is the go-to choice for most mobile designers. Tab bar doesn’t scale beyond 3–4 items. Instamojo had over 10 items.

For eg: If you are working on a product which has a lot of actions to do, don’t just run with a bottom navigation or a hamburger menu in hand to fit it somewhere. First, check why you want the bottom navigation? Can you fit all your items in there if you have more than 7 or 8 action items or maybe more?

The hamburger menu was not an option for us. Hamburger menu is bad for discoverability. It gives an illusion of hiding complexity.

Hamburgers often solve designers’ problems and not the user’s. Especially when critical actions are hidden away.

The alternative was to keep everything upfront.

We made “Reports” and “Manage” into individual cards.

Items in the “manage” section, are near the thumb zone. This makes sure users get the comfort of a tab bar, without the limitations.

Manage section near thumb safe area

Sticking with the FAB button

Our first iteration was without the FAB button. We decided to keep all the actions like creating Payment Links, adding Product to Store, creating Online Store, Scheduling Pickups, Requesting a Payment, etc in a card layout. This was not solving the problem but was increasing the cognitive load for users.

Our first iteration (without the FAB button) with all the create actions up-front.

We decided to use the FAB button. FAB buttons can expand, morph, and react. But FAB buttons are also more accessible because it’s closer to the thumb. Ta da! Now all create actions are a tap away.

Clean & Minimal Interface

Our users are people running a business. The content of the dashboard is critical to them. The minimal & monochrome visual aesthetics puts the user’s focus on content—numbers & text. We also took care of accessibility while deciding the colour palette.

A glimpse of our New Android Dashboard

Outcome

Our Android app users are happy and have switched over to the app without any glitches or complaints. We are collecting more data on the user experience and shall keep updating the post as there’s more.

The Team

I am really thankful to @kingsidharth for helping me at every step of solving this problem for Instamojo’s users and editing this post.

Thanks for editing the post — Rapti Gupta

I have some other interesting articles for you here. For more works & chat, follow and connect with me on these channels: Twitter, Dribbble, LinkedIn, Instagram

I hope you learned something extra today :). Thanks again for your precious time. Cheers!

--

--

UX Designer at Google Pay(Consultant), ex @headout, @bookmyshow, solving problems for the payment industry and enjoying failures (at least for a moment).