There is so much excitement and energy involved in creating a software product. We had so many ideas for our first app, in fact so many that we had to limit the scope for the first product and to create version plans to implement all the features and still be able to release them in time.
We went through many brainstorming sessions to come up with plans and designs, decide the technologies to be used, the set up of a tech team, and all the other things to finally create an app.
The most important step in all this, however, is the onboarding of our users onto the app, after all, the app was created to make the lives of our users simpler.
How Did We Make it Happen?
Users have been central at every step of the app creation process. The app was created to solve a business problem of attendance regularisation of drivers (henceforth called captains) and thereby, make payments easier. We designed the app to keep the user interface simple so that users can easily find the information relevant to them and perform the required tasks in the minimum number of steps.
When it came to the app release as well, we wanted to keep it simple for the users. The process involved a few crucial steps.
- The first step was to upload all the existing data to our database. All the core data essential to operations like the cities we operate in, vehicle models that we have, and so on was first uploaded.
- Then, the data of captains and vehicles in each city was collated and uploaded.
- Parallelly, a training program was created for the supervisors in each city, the supervisors were in turn responsible for the training of the captains reporting to them.
- We also created educational videos and shared them among the supervisors to share among captains to watch and learn how to use the app.
The First Pilot Release and Challenges Faced
The first phase of the release was a pilot with 5 users. From the perspective of the tech team, this was very exciting. They were the first users of our first tech product.
It was also the day we got our first live issue (: facepalm), one of the users was not able to login. The issue was that the phone number the user was using was for some reason blocked by our authenticator. The issue was easily resolved though, the user had an alternate number that we tried with, and it worked (thank goodness for dual-SIM android phones).
Apart from that minor glitch, our pilot was a success. The captains were using the app every day, and usage was going smoothly. After a week of testing all the use cases, we expanded the release to the entire city of Bengaluru first and then in the second week, to all the cities where we are operational.
Here, we encountered a few more login issues, which were quickly resolved (and later on, we implemented an alternate authenticator so that this issue wouldn’t occur again).
Resolving Issues Simultaneously With live App Usage
Our major issue was the time gap between the week when the initial data was uploaded and the week when the users were onboarded which resulted in changes in the data which we didn’t account for. That prevented the tech adoption for a few supervisors. We quickly got this differential data uploaded: some new data was uploaded, some existing data updated, and some data deleted (yikes!) This had to be done carefully now without impacting existing operations.
A second and more interesting problem we faced was that, when our users were under training, we exposed the QA version to them to make them more comfortable with the layout of the app, and then some users started using the QA app for actual operations (:shock). This data was obviously not reflecting our live reports. Once we realized this, we immediately disabled access to all users to the QA app and clarified the app versions to the users. We realized why it was important to release just one version to the users, and that needs to be the actual version. We should have clearly indicated the Beta and test versions and explained the different versions and their purpose to the supervisors.
When one is building a product from scratch and training the users, one would surely be faced with some issues. How each user uses the app would be different. And we wanted to be able to quickly resolve the issues faced by our users.
In keeping with our aim to make the life of our users easier, we created a WhatsApp group for the supervisors to quickly report the issues faced directly to the tech team, and my team members could solve them as soon as possible. We did not want a lengthy support process, or for our users to have to go through multiple people to have the issues resolved.
Alongside, we conducted additional training sessions when required and created more instructional videos that were shared with the users so that they had something to refer to in case of any doubts. These videos, like our app, were multilingual, which was very important since our users were from different backgrounds.
Predicting User Behavior is a Challenge
One thing that we realized with the release is that the user behavior was unpredictable. Our users were as excited as us to use our app, they explored the app and tried the various actions available to understand the behavior, sometimes with unintentional consequences. Our app was well-tested, but there were some edge cases that I knew were not handled. (I honestly didn’t think that our users would ever have to reach those cases)
We resolved the issues as and when they came up, either reported by our users or during our routine testing. We spent a lot of time after our release to test and address such issues before our users faced them, now that we knew not to assume user behavior. (lesson learned: do not fall into the trap of predictability)
Another interesting thing was that our app had some features that we thought were super critical and can be performed from multiple places in the app, but that ended up confusing our users. We re-looked into our app design, created an information structure, and updated our app so that actions can be performed only from certain screens, where they were most relevant and do not result in duplicate actions.
Putting all the efforts to make this product a success
Change is not easy, and in some cases, we were facing resistance in our tech adoption, sometimes because of the issues users faced, sometimes because of the lack of understanding, sometimes because adopting any new tech can seem more complicated than it actually is. We continue to fix the issues, but we also need to change the mindset of our supervisors and users.
We had regular meetings with the supervisors to explain the importance of the app, what we were trying to accomplish, and how it would help them. Sometimes we got senior members of our team who reassured our supervisors of our vision. Additionally, we also introduced an incentive program for our users to successfully use the app every day. We set up reports and automated emails to the supervisors so that they could track the adoption.
All our efforts bore results, and our tech adoption improved significantly. We are still not where we want to be (i.e., a 100% tech adoption), but we are improving significantly every week. We have cleaned up our processes, introduced new team members who would be responsible for data across all cities, and its maintenance in our system so that fewer people need to have to change the data.
I am confident that in the coming weeks, if not days, we will attain our first goal of 100% tech adoption. With that, of course, we will be able to do so many more things with tech as our backbone. We have identified a lot more processes that can be automated to make it more efficient and less error-prone, less time-consuming, and are actively working towards it.
Developing an app is a challenge and it takes time to show the expected results. You are going to face multiple issues during and after the release when the users actually start using the app.
We can develop strategies to resolve all the user issues to provide them with a seamless and smooth user experience. As it is said, hard work always pays off. We are evolving and so is our app to make development as smooth as possible.
Written By:
Ramya T R
Senior Software Engineer
MoEVing
