Multi User Feature in myBillBook app

myBillBook is an easy to use mobile billing & stock management app meant to make the life of businessmen easier by transitioning from pen & paper billing to digital billing/invoicing.

Background

Having found the Product Market Fit by solving the basic problem of invoicing & stock management for businesses, particularly in Tier 2 and Tier 3 cities of India, it was time for the team to start digging deeper into more complex user problems that a businessman encounters when he works with different staff members. A businessman works with different staff members who take ownership of different responsibilities like stock management, delivery, sales, etc.

What is the real problem?

One of the many issues that the data showed us was that the registered users were giving access to the app to different people who then used to log into the app by seeking the OTP from the registered mobile number. This led to multiple device logins on the same account.

Subsequent to the discovery of this issue, our support team informed us that a large number of customer support tickets were being received with most common problems revolving around:

1. User’s data getting deleted
2. Older data got edited
3. Extra discounts being charged on sales
4. New entries being added without their knowledge

This led to a panic situation amongst the major set of our user base. We thus decided to dive deeper into the issue and see if there was any correlation between these issues. To understand & validate the problem, we conducted both quantitative & qualitative research.

Research and its findings

Our initial finding from Quantitative research suggested that nearly 53% of the users who complained about the above mentioned problems belonged to the group that had logged in from multiple devices.

To understand the issues better and see what problems/motivation the users had, we conducted empathy interviews with more than 100 existing users.

We prepared a cohort of the users who had logged in from 2 or more devices from a single account in the last 30 days to conduct the interviews.

Following were the questions that we were looking to address through these interviews:

1. The reason for which the users were giving access. If there was a common motivation among the different users.
2. Who are the people, who have been given access
3. Do they want to give the access to any particular thing or the entire app
4. Which platform are these users using i.e. mobile or desktop or both
5. What is their digital literacy level
6. What type of mobiles & desktops do they use
7. Do they have internet access, how much data do they have (connectivity to internet)
8. What type of language do the people who have been given access understand

After talking to the above mentioned user cohort, we were able to gather following information:

1. The users wanted to give access to their staff members. We discovered that there were common motivations behind the user’s actions.
2. The people to whom the access was given were their staff members like stock managers, salesmen, delivery boys, Partners, consultants
3. These staffers were 10th - 12th graduate
4. They could understand basic English
5. They had roughly 1 - 2 GB internet data
6. There were approximately 3 - 4 such staff members in the shop/store
7. They had latest android devices & desktops
8. Such businessmen had both mobile phones & desktops

Ideating on the solutions

After conducting the research we concluded that there was a need for a Minimal Multi User feature in the myBillBook app.

We decided to support 5 most common roles in the minimal multi user feature to which the businessmen were giving access.

Trying different variations

Below are the lo-fi wireframes that I came up with:

Initial wireframe variations

Followed by the initial screens:

Old flow (a)

Old flow (b)

Collaborating with the tech team

To build this feature we checked for the engineering/tech bandwidth. While discussing with the engineering team we got to know:

1. That showing all the roles & responsibilities in the app & making them native would be difficult thus we reiterated by providing a link to the detailed roles & responsibilities which would take the users to a web view within the app.
2. Initially we had planned that if the restricted user tried to click on something that is not available to him/her, they would see a bottom sheet which would show them something like this:

Proposed bottom sheet

But due to limitations in the engineering bandwidth we reworked our plan and decided that hiding the complete feature from the restricted user would be easier.

Usability testing

After incorporating all the changes, I prepared the prototype and we reached out to a certain group of users & asked them to try out the feature. These were our finding from the user testing:

1. It is difficult for the users to find the feature
2. It is text heavy & users didn’t want to read much
3. Would be helpful if the language was simpler
4. Users are not able to remember their staffer’s contact details

Finalising the mocks

Based on the tech discussion & user testing we made the following changes:

1. Since the users were having discoverability issues, we made the feature more front facing
2. Simplified the language
3. Added role based illustrations so that it becomes more visual & less textual
4. Added the contact book in the name field to auto recognise & suggest the details of the staffer as the user types

Updated wireframes

Final screens(a) Better visibility & communication

Final screens(b) Simplified & minimal design

Roles & permissions (web view)

Hand-off

The job is not done here. To avoid this 👇🏼

Never let this happen

We hand-off the well defined designs to the engineers & work with them during the development to ensure that there are minimum errors & differences between the initial design & the final product.

Post development, I contributed in testing the build & QA.
Once everything was tested thoroughly, we then went on to release the final app on prod.

Post Launch Metrics

After the launch of a feature, I am actively involved in tracking the performance through data. We analysed the numbers after the launch of the Multi User Feature and following are a few of the significant positive impacts on our KPIs :

We saw an increase in the conversion rate of first login -> plan purchase by 141%

Week 4 Retention of users who used this feature was 84.9%, which was significantly higher than our power users

The average number of staff members added by the users every month is 4000

Added users are creating 30 vouchers every week on average in the app

Conclusion

What started as an effort to understand user behaviour behind the abrupt rise in the number of customer support tickets & multiple device logins in an account, became a sprint which led us to develop a really vital feature namely “MULTI USER/MULTI STAFF” which not only solved the user problem but also helped the company with a significant uptick in revenue.

Thank you for reading & I hope you found this insightful. 🙏🏼
If you have any questions, feel free to reach out to me on LinkedIn and don’t forget to check out my recent work on Behance.

You can buy me a coffee here.