An inside view on how BlackBuck conducts user research and testing to build better products

User Research and its importance

User research is essential to building a better product because it provides insights into the needs, preferences, and behaviours of the people who will finally be using the product. The goal of user research is to gather insights that can further enable the design and development of products & services; making it relevant, functional and meaningful to the users.

There are various user research methods, including qualitative and quantitative approaches. Qualitative methods, such as interviews, focus groups, observations, and usability testing aim to understand the subjective experiences and perspectives of users. Quantitative methods like surveys and analytics aim to gather numerical data to measure user behaviours and attitudes.

The insights gained from user research can inform various aspects of product development, including product strategy, design decisions, feature prioritization, and marketing messaging. By incorporating user feedback and insights into the development process, businesses can create products and services that better meet the needs of their target users, leading to higher user satisfaction and improved business outcomes.

Overall, user research is essential to building a better product that meets the needs of its users. By understanding user needs, creating a user-centred design, testing assumptions, improving usability, and reducing development costs, user research can help ensure a product’s success.

Qualitative Research

When conducting user research and usability testing, there are a variety of qualitative methods available that can provide valuable insights into the needs, behaviours, and attitudes of users ( as mentioned in the image below).

The next obvious question is — which method to use. Well, it’s important to experiment with different methods to determine which ones work best for your objectives.

Research challenges with truckers in India

As a trucking marketplace in India, BlackBuck aims to understand the needs and expectations of its target audience to provide a seamless user experience. However, the target audience may not be very educated, which poses a challenge for user research and usability testing. Many methods of traditional research don’t work with our users. Some crucial problems we face during our research -

• We cannot fix appointments with them for one-on-one interviews or telephone interviews.
• We cannot expect a dedicated amount of time even if we meet them.
• Telephone interviews are cold calls — whoever answers and is willing to talk.
• The interviews are (almost) always interrupted — they get a call, start talking to someone else or pick up another task.

Truckers in India have a unique lifestyle and work in an industry that operates differently from traditional 9–5 businesses. The trucking industry is open 24/7, and truck owners are constantly on calls, looking for loads or trucks, enquiring about the location of trucks or loads, and following up on payments. Due to these factors, their priorities and needs are different, making conducting user research and testing challenging.

Moreover, many truckers are not familiar with the concepts of user research, testing, and surveys or their importance in the development of a product that they use. As a result, getting feedback from them can be difficult.

Research Methods at BlackBuck

To overcome the above challenges, BlackBuck has adopted various research and testing methods, such as one-on-one interviews, phone call interviews, and sending screenshots of designs via WhatsApp to gather feedback and on-site user testing. These methods allow BlackBuck to obtain the necessary insights from truckers without making them feel like they have to put in any extra effort. By using innovative research methods, BlackBuck can understand the unique needs and priorities of its target audience and develop products that cater to their requirements.

1. One-on-one interviews

In these interviews, we talk to individual users to understand their experiences, pain points, and suggestions for improvement. One-on-one interviews are usually conducted on-site, i.e. a transport hub where many BlackBuck-using transporters can be found in close vicinity. This method allows BlackBuck to gain in-depth insights into the user’s perspective and tailor the product accordingly.

Limitation

Conducting one-on-one interviews can be time-consuming and resource-intensive, limiting the number of users who can participate.

One-on-one interviews with our users, who are predominantly truck owners and transporters, present unique challenges due to the nature of their work. As the trucking industry is not highly organized, fixed appointments are not always feasible. Our users may have unpredictable schedules and may not be mindful of allocated time. As a result, interviews can range from 15 minutes to an hour, depending on their availability and mood. It’s common to catch them amid their work, requiring flexibility and patience. Interruptions such as phone calls or other tasks may occur during the interview, leading to potential delays. Therefore, conducting interviews with our users requires adaptability and an understanding of the demands of the trucking industry.

Research Example — Interviewing users for overall feedback on the BlackBuck app

In Jodhpur, we conducted interviews with a group of users to gather their general opinions about the app’s usability. Our objective was to gather information on their preferences, grievances, and any challenges they faced while using the app.

Our goal was to understand how our app was being used by users and identify ways to improve their experience, which required us to engage in individual conversations with them.

As the interviews were conducted individually, we had sufficient time to understand their requirements and difficulties, gaining valuable insights into their experiences.

Research Impact

Having one-on-one interactions with the users provided an excellent foundation for revamping the app. These detailed interviews gave us valuable insight into how the users interacted with the app. We discovered the other apps they used in their daily routines and what aspects they appreciated about those apps. This knowledge helped us identify what modifications we could implement in our app.

2. Telephone Interviews

BlackBuck also conducts phone call interviews with its target audience. Phone call interviews are cost-effective and allow researchers to reach a large number of users quickly. In phone call interviews, researchers ask users questions about their experience with the product, their pain points, and suggestions for improvement. Phone call interviews also allow BlackBuck to gather feedback from users who are geographically dispersed.

Limitation

Our phone calls to users are not prearranged. We receive a list of users to interview and begin contacting them. However, the process can be unpredictable as users may decline to speak or hang up after only a few minutes, and may not answer all questions. Despite these challenges, we persist until we receive adequate feedback from a targeted number of participants. Typically, for every 20 feedbacks received, we need to call an average of 50–60 people. Therefore, conducting interviews via phone requires persistence and adaptability to navigate the variability of user engagement.

Research Example — Finding out if the Chats feature is as important for users as the Calls feature

Our aim was to provide truck owners with the ability to communicate with transporters on our platform through the Chats feature. After a month of its release, we wanted to see the significance of this feature to our users.

The objectives of this research were -

1. To find out why certain users used the chat feature before calling a transporter.
2. How important was the chat feature to users in comparison to the calls feature?

We decided to call the users for this research because we were looking to gather qualitative feedback from users in a relatively short amount of time.

Research Impact

The research data provided a clear indication that the users did not consider the chat feature as a must-have feature, but rather a nice-to-have feature. While some users expressed positive sentiment towards the chat feature, the overall data suggested that it wasn’t as important to them as the call feature. This information helped the product team to focus on developing or improving the features that were more essential to the users.

3. Sharing designs via Phone

Sending screenshots of designs to users and asking for feedback is another method used by BlackBuck. This method is particularly useful when the user is not available for a one-on-one or phone call interview. Sending screenshots of designs to users allows BlackBuck to gather feedback quickly and efficiently. It also allows users to provide feedback at their convenience, making it more likely that they will respond.

After the screenshots are shared, and once the user has responded to the message, we call the user for detailed feedback.

Limitation

While sending screenshots via WhatsApp to users for feedback can be a useful method, it does have its limitations. For example, some users may not respond quickly or require multiple follow-ups, making the feedback process slower and less efficient. Additionally, it can be difficult to convey complex navigation flows through screenshots alone, which can make it challenging to get comprehensive feedback on a design.

This method can only be used to gather feedback on a single-page design or to compare multiple options. When using this method, it’s important to be clear about the specific design or copy elements you’re seeking feedback on and to provide context for how the screenshot fits into the broader design. Additionally, it can be helpful to follow up with users to clarify any questions or concerns they may have and to ensure that you’re getting the most useful feedback possible.

Research Example — Assessing the degree of correlation between Boss and BlackBuck and the change of app icon colour for users through testing

Branding changes in the app icon that we wanted to test —

1. Change from Boss Transporter to BlackBuck Transport.
2. Change of colour from red to black.

Prior to making this transition, it was essential to determine whether our users could understand the new icons as we wanted to prevent them from experiencing any confusion while searching for our app on their mobile devices.

Since it was just an icon we wanted feedback on, we thought it would be best to share a screenshot with the users.

Research Impact

The research also provided us with another unique insight, revealing that the words “Boss” and “BlackBuck” were interchangeable for our users and that changing the app name or icon colour did not cause any hesitation in their decision to choose the app.

4. On-site User Testing

In some cases of Usability Testing, BlackBuck opts for going directly to the user. This is done through an interactive prototype made in Figma and then presented to the user to interact with.

For this method also, we visit transporters in their offices (usually in a transport hub where we can find multiple BlackBuck-using transporters in the same place). The researcher, with the help of a translator (if required), gives the user the context of the testing and then shows the prototype (of the feature to be tested) to the user to interact with.

During user interaction, observations are made on how the user is interacting and any friction points he is coming across while interacting. Post interaction, the researcher (at times) asks some questions with respect to the experience of the user.

Because the BlackBuck apps also support regional languages, the prototypes are also made in different languages depending on the area we choose for testing. Testing in Rajasthan would mean the prototype would be in English and Hindi. Whereas testing in Karnataka would require us to prepare the prototype in English and Kannada.

One big advantage of this method is that the user has minimal disturbance to his schedule as the researcher conducts testing in his environment and hence, his comfort zone. So, the observation and feedback are more genuine and accurate.

Limitation

1. While this method is highly effective in knowing the actual response in normal scenarios, going directly to the user’s place may not bring accurate results in some cases. If there is a busy occasion for the majority of transporters like festivities, or if there is a sudden loading/unloading spike in the transport hub (and it happens at least once or twice a month), then the majority of transporters won’t be available for user testing. Even the ones who agree are often in a hurry so they might not give a very genuine response about their experience.
2. Since users are not familiar with the concept of testing, many have to be explained what a prototype is, and why they are asked to interact with it just like they would with an actual product.

“For instance, a user was once shown a prototype with made-up data, and he thought it was real. He could not understand why something made-up was being shown to him.”

Research Example — Finding out if the users were able to use the ignition on and off feature

The lock and unlock feature is a crucial aspect of BlackBuck GPS and sets us apart from our competitors. This additional layer of security was promised to our users, making it vital that they know how to use it effectively.

Also watch: User testing of Ignition Lock/unlock

Research Impact

The usability testing helped us validate the UX of the feature. The users were able to lock and unlock the ignition and understood words like ignition and relay.

Conclusion

At BlackBuck, we have experimented with and adopted multiple methods for user research and usability testing to overcome the limitations of a target audience that may not be very educated and tech-savvy. Through trial and error, we have been able to develop our own unique way to conduct research and usability testing to gather valuable feedback from its users and improve its product accordingly.

By Rishabhkumar Uday

Introduction

In the last part of this blog series, we discussed the importance of robust telematics solutions, described how our theft protection (relay) functions in a vehicle and how it's controlled through the GPS app of BlackBuck. However, like all product design journey, the Relay feature in its first version had room for improvement in its design. In this part, we are going to describe in detail what were the hits & misses in our first version, how we approached them in our reiteration and how we eventually reached the new design of Theft Protection (Relay).

Problem Statement

This was the initial process to lock/unlock the ignition through the app:

In this case several problems were found in both UX and UI fronts.

UX Problems Found

#1. Setting wrong expectations for the User:-

Once the user proceeds with locking the ignition, the pop-up closes to reveal a new information component within the details page.

Since there is no prior intimation of the next step, the user expects the ignition to be locked/unlocked instantly, which is not always the case. There are a few edge cases where this process takes time. But this information is not shared with the user. And when the lock/unlock takes time, the user assumes that the page or app is malfunctioning — clearly not a good user experience.

#2. Poor handling of Exception:-

Speaking of exceptions, Lock ignition has primarily two of them:

As shown in the figure above, the unanswered questions arise because these states are not treated like exceptions. Rather, they are treated like an add-on step which sometimes confuses the user.

#3 Unexpected and unexplained changes in controls

In the lock/unlock process, once the sending of the ‘lock’ signal is complete, the option to cancel lock/unlock is removed without any prior explanation. This is done because after the signal is sent to the truck, the lock/unlock process becomes irreversible from the back-end.

UI Problems Found

Solution Process

Once the problems were specified, we worked on a viable solution through:-

1. Analytics Review and Stakeholder Discussions
2. Revised User Flow
3. Design Concepts
4. Final Design

Analytics Review & Stakeholder Discussions

We checked the overall distribution of time taken to complete a lock/unlock process. Based on the numbers, we were going to decide what approach to take for the solution model.

Numbers in approximate figures

Based on the distribution and the problems specified, several guidelines were laid out:-

• In the majority of cases, the lock/unlock happens within 1 min. Hence, it was decided that the new design would be focused more on that strata. Since the interaction would last for 1 min in most cases, the overall process of lock/unlock would be seen in a direct and upfront manner by default when initiated. The user would be given the option of leaving that upfront view whenever they feel so.
• In case the user exits the upfront view, a secondary notification component would be present (to inform him of the ongoing progress of lock/unlock in the backdrop) in the truck list and details page.
• The difference in nature of the ongoing lock/unlock process (initiated > in progress > successful) will be shown evidently in the new design.
• Messaging will be regularized throughout the UI.
• Controls, when needed to be disabled, will be disabled with proper reason given to the user.

Revised User Flow

Design Concepts

Initially, two iterations were made and their UI analysis was done to differentiate their pros and cons. We then took the pros and cons of both the iterations into consideration and then combined them to design the final iteration, maximizing the pros and eliminating the cons.

Final Design

Following all the iterations, we came out with the final solution which was later implemented into the application.

Here below are the Final Design Snippets

Main Screens

Revised Lock Process

Revised Unlock Process

You can also view Final Design Prototype on the link below

https://youtu.be/fedykD5Nky8

User Testing of Design

• Post design completion, to verify the usability of the new Relay (Ignition) lock/unlock pages, we went to a transport hub based in Yeshwantpur, Bangalore.
• There we tested out the new design with 5 randomly picked local truck owners. 3 of them had relay installed in their trucks while 2 were non-relay users of BlackBuck.

The gist derived from testing

• Relay users went through the lock/unlock flow easily and by themselves.
• They understood the color concept used for lock/unlock.

User testing of Ignition Lock/unlock

One user commented while going through the flow: “Red matlab lock, green matlab unlock. Yellow bole to thoda thoda lock ya thoda thoda unlock.”

Translation: Red means lock, green means unlock. If its yellow its either a little locked or a little unlocked

The non-relay users were intrigued by the screens shown. After going through the flow, they started enquiry with us for relay Installations.

A non-relay user commented: “Acha ye relay kitne ka aata hai?”(how much does this relay cost?)

We took these results as usability verified and finally handed over the design to the developers to be implemented.

Conclusion

The redesigning process taught us many things — how to identify the correct problem statement, dealing with each scenario is important, being helpful and transparent to users is the priority and user testing at an early stage will always give you the right feedback at the right time.

The project has so far resulted in a smooth adoption and understanding of relay lock/unlock features by the users. What earlier used to be somewhat hidden in between the other details of the truck, now appears upfront to the users when activated, giving users the clarity of what’s happening. Earlier, relay/lock unlock was treated as a complex thing (by the users) with unknown steps. Now, comprehensively it is getting treated like a simple tool that is easy to use and is involved in the day to day life of the user.

Thank you very much for taking your time out to read this. We hope you found it interesting. Cheers from BlackBuck!

According to Niti Ayog's report 40 lakh + trucks move around 70% of the domestic freight in India making trucking the main facilitator of the movement of goods and products in the country. Even though it plays a crucial role in the transportation sector, trucking is one of the least digitised industries and faces many challenges: delays, thefts, unloading at wrong locations etc. Ensuring that goods reach the growing consumer base on time, and in the proper condition requires constant technological advancements, especially, in the field of fleet tracking.

For a truck carrying a load worth lakhs, its safety becomes primary for both the truck owner and the transporter. That’s where the Telematics commonly known as GPS comes in. GPS for commercial vehicles are specially designed to help the fleet operators track their fleet’s location and increase business efficiencies through its various features.

At BlackBuck, our mission is to solve every need of a trucker and we realized for fleet operators, intelligence on their truck movement can be a huge of sigh of relief and also help them make informed decisions.

In this blog, we will take you through the benefits of having a robust telematics solutions and in particular, will throw light on our 'Relay' feature specifically designed to prevent and protect fleet operators from truck thefts.

The many facets of Telematics

BlackBuck's telematics solutions is tailor-made to help fleet operators to manage his fleet better. It enables the fleet operator aka a trucker to keep track of their trucks from loading to unloading points, ensures that safe driving practices are followed and truck thefts are prevented. Here are some of the benefits offered to our truckers -

• Tracking of live location of your truck
• Minimization of calls to the driver for location updates
• Tracking of fuel consumption based on the distance covered
• Number of stops and distance travelled during the trip
• Notifications of unusual stoppages and lengthy low network periods
• Detailed reports of driving behaviors — over speeding, harsh braking/acceleration/cornering etc.

Not just another GPS!

GPS devices in its existing avatar in the market has its limitations and they aren't really customised for Commercial Vehicles. BlackBuck understanding the need for customisation and wanting to bring value addition to a trucker's life, brought in a more holistic approach. We added intelligence layers that has its own set of secondary features making it a double threat to all kinds of ‘buri nazars’. One such essential feature is Theft Protection (Relay) Device Controls and Installation. Thefts of in-transit trucks carrying loads are a major reason why many truck owners are wary of sending their trucks on new routes. Even with the GPS device installed, the most they can do is track their trucks and call drivers for any unusual activities they notice.

But with the added Theft Protection (Relay) layer, a user can switch off the ignition of the truck from our app itself, making it a key and must-have feature in preventing truck theft.

What is a Theft Protection (Relay)?

It is a device that is fitted into a truck for its ignition to be locked or unlocked (through the app) by the user. The user, in this case, is a Truck Operator. Theft Protection (Relay) is only useful if the truck has a GPS. The user finds out the location of the truck through the GPS and decides when he wants to lock/unlock the ignition. BlackBuck's telematics solution offers a trucker both the GPS device and an added protection layer through Relay.

Why is it important?

Theft Protection (Relay) acts as a security feature in possible cases of vehicle/load thefts. When trucks are parked in remote locations or have not moved in a long time, the truck owners can lock the ignition from the app and secure the trucks.

How does Ignition Lock/Unlock work?

Once the user locks the ignition of a truck via the app, one cannot start the truck manually (key insert and turn to start). The only way the truck will start again is if the user on the other side unlocks the truck through the app.

Case Study

To demonstrate the critical role the Relay feature can play in preventing a theft, let us simulate a scenario for you:

Mohanlal is a small fleet operator in Kerala who owns three trucks. He also has three permanent drivers who have been working for him for over 7 years. Mohanlal has been in the business of trucking for the last 15 years and until 2 years ago was largely running his operations traditionally with barely any digital interventions. Cut to 2022, thanks to the digital push during the pandemic, he now has warmed up to smartphones. He extensively uses BlackBuck's telematics solutions. Today, all three of Lal's trucks are fitted with BlackBuck GPS and Relay, he has access to monthly reports of the driving patterns and monitors each of his truck's movement on his phone.

One day, one of Mohanlal’s loaded trucks was on its way to Hyderabad from Jaipur. On the second day of the trip, when the driver had parked the truck at a resting spot for the night, a thief conspired to steal it.

Fortunately, since Lal had the Relay device fitted with his GPS, he was able switch off the truck's ignition remotely through his phone whenever there was a prolonged period of stoppage. So, when his driver stopped at the resting stop, Lal by default activated the Relay feature. When the thief tried to start the vehicle multiple times he was unable to do so, leaving him baffled.  

Eventually someone noticed the thief on the truck and alerted the driver. The thief was caught and handed over to the police.

“Thank God I had the Theft Protection Device installed in the truck. Every time the driver parks the truck at night, I switch off the ignition from my app. This way, I know no one can steal my truck.” says Mohanlal

Trucks carrying goods are highly vulnerable to thefts. The incident described above is extremely common than one might think and the cost of losing a truck along with goods can put a trucker in debt for life and sometimes even out of business. To be able to control and protect the truck anywhere, anytime is a game-changer for a small fleet operator in India.

It is because of this that today, 1 in 5 trucks in India use BlackBuck's Telematics Solutions. The GPS device coupled with the Relay feature is helping lakhs of our truckers keep a close eye on their trucks and its safety. However, we have barely scratched the surface and we have been constantly improving our offerings and product design based on the engagement and user behaviour.

In our next and final installment in the telematics series, we will take you through at greater lengths about what went behind designing the Relay feature on the app, how does a user (fleet operator) interact / engage with this feature and how we have been improving user experience.

To be continued....

With approximately 75% of the goods being transported using trucks  and with over 7 million trucks on road, the logistics economy in India is dominated by road freight. The small fleet operators who own less than 5 trucks are the backbone, the crucial players in the logistics economy. However trucking is a complex landscape and comes with its own challenges and inefficiencies.

Most trucks on an average run 15 - 16 days of the 30 billable days. 100% utilization of assets is practically impossible in this segment primarily because finding a load is difficult. It takes 1 to 3 days to get a load and a lot of trucks end up running empty on roads with no return loads. In addition unpredictable waiting times during loading/unloading and volatility in pricing pose fundamental challenges. Technology can play an immense role in  addressing  these challenges and inefficiencies plaguing the ecosystem.

Data Science, Machine Learning and AI have evolved significantly in the last decade, witnessing widespread mainstream deployments across industries and delivering true ROI. In logistics in particular, Data Science has emerged as a force multiplier in organizing and transforming the trucking domain in India.

To understand the deep impact of the role of Data Science in trucking, let us look at two scenarios. A Trucker taking a Full Truck Load (FTL) typically travels an average of 600kms per trip moving goods between states over 2-4 days.  Scenario 1 - a trucker is moving coal from Kandla, Gujarat to Muzaffarnagar, UP covering 1200 kms over 4 days. Upon arrival at Muzaffarnagar, the truck takes anywhere between 3-12 hours for unloading the goods depending on queues at the destination warehouse. Post unloading, the trucker now starts calling his/her contacts to seek a good return load for the next trip. In a traditional and unorganized setting, it is normal for a trucker to wait 12-48 hours to confirm the next load and also end-up traveling at least 50-150 kms for the next load aka ‘dry run’. Which means after reaching Muzaffarnagar, a typical return loop starts from  Karnal, Haryana 80 km away from Muzaffarnagar.

Let’s contrast the above example with the ideal behavior on a technology platform powered by data and algorithms. With Data Science, we can build models to anticipate when a trucker will finish his delivery and need another load on his return route. The platform can upfront recommend relevant loads before the trucker even completes his unloading as opposed to the offline world where a trucker has to call and look for the next load after he finishes unloading.

Now in scenario 2, if the same truck traveling from Kandla to Muzaffarnagar is fitted with a GPS device it can send GPS data-pings every 10 secs triggering a comprehensive suite of Machine Learning algorithms. The Data science efforts begin with endowing meaning to the raw GPS trajectory that is being streamed from the devices onto the digital platform’s data lakes. As it observes the trajectory of GPS pings moving away from Kandla and approaching Muzaffarnagar, it can continuously predict the potential state of the truck. It can deploy deep learning based Spatial-temporal sequence models to understand if the truck is still  ‘in-transit’? or has it entered  the ‘unloading-complete’ state?  or has it moved into ‘is-available  for the next load’ state? Based on the model's confidence on whether the truck is going to be available soon, an efficient match-making engine can proactively recommend new loads as per the truck’s proximity and relevance.

These recommended loads are generated via relevance models which are trained over trucker’s historical click-stream data. Machine learning models pick up signals every time a trucker engages with the platform to search for loads. The model learns to decode these signals to build a profile of the truckers’ latent preference across various entities - geographical lanes, product-types, price-points, shippers, ratings etc.

This profile creation helps in optimal allocation and distribution of relevant loads to the right type of trucker. DS deploys optimization algorithms in frequent intervals  to optimally distribute and allocate the fresh loads among truckers based on availability, proximity and relevance constraints.

The end-goal is any trucker who is engaging on the platform is already aware of his next load even before he completes his unloading. These recommendations are optimized to create greater discovery of loads and at the same time significantly reduce the idle time of a truck and cut-down potential dry-run kms. It is aimed at improving revenues as well as reducing operational costs for a truck operator. A digital freight network that is well optimized can empower a truck operator to better utilize his assets; reduce idle time by 40% - 50%, and improve his earnings by 20% to 30%.

However, Data science and machine learning modules need to constantly evolve.  Algorithms and modules must be continuously re-calibrated and re-optimized based on both implicit and explicit feedback obtained via customers, in this case truckers who respond to the algorithm outputs. This ensures that  the match-making engine is consistently able to better match the right trucker with the right load at the right time improving the rate of deal-closures on a platform.

Blog design: Puranjai Pratap

This article was originally published in ET CIO

Recap

Part 1 of this blog talked about the growing need for localization of our product. We found out what our users needed and validated it through usability testing and user research. The end goal was for our users to be able to use our product on their own and with ease.

Getting down to the Brass tacks of Product Localization

In this second part, we aim to go deeper, give you a sense of what product localization really means and take you through the nuances and challenges while creating our product copy - easy, conversational and colloquial.

How did we solve the problem?

Solving this problem statement was a daunting task with over 30 thousand strings to be translated into four new languages for over 1000 app screens. And that was just the output displayed to the user. There were information input flows across the app that needed to support the same languages in the keyboards, character limits and suggestions for these inputs. All of this was broken down into multiple steps that eventually took us almost 8 months to solve.

Step 1: Establish the Product Voice

The first and foremost requirement was to figure out the Voice of our Product. Based on the user's needs, we wanted our tone to be conversational, colloquial and our language to be clear and precise.

1. Day-to-day conversational

We wanted to speak to them just like they would in day-to-day conversations with a friend, while also keeping it crisp and contextual.

2. Transparent

It is very important to give the users the right information (without alarming them) to gain their trust.

3. Helpful

We do not want the users to think they do not have enough information to make smart decisions for themselves. We want to help them understand why they are doing what they are doing!

Step 2: Setup a Process

• Language Audit of the app to identify and correct the gaps
• Hired a localization agency for translations
• Integration with a localization tool to streamline the process
• Usability testing for every update - Design & Copy

Step 3: Build Product Capabilities

With all the processes in place, we moved on to building the translation capabilities throughout the app. These involved 2 parts:

• Built translation capabilities for all the texts across the app (all information outputs)
• Built flows for vernacular keyboards and translated suggestions while searching (all information inputs)

Since we are an app with multiple categories, this was done one category at a time and took a total of 4-5 months.

Step 4: Collect User Feedback

Post the launch of the first set of translations, we also started conducting user immersion sessions in parallel to take feedback on the translation quality. This was done on a large scale with over 100 users. With increased interaction with our users, we learned not to take our understanding of things as absolute. Some of the learnings were:

• The language has to be at its simplest and in a way they understand.

• Since we live in a country with diversity in culture and language, the understanding of certain words and phrases in different parts of the country is not the same. It was important for the copy to be colloquial and contextual.  Example - Words like Bid and POD (Proof of delivery) are understood by most people from the South of India. But in the North, Boli (बोली) for Bid and Pohoch (पोहोच) for POD are more commonly used. For users with Hindi as their app language, we decided to use these words instead.
• The user feedback also brought forth another interesting observation. We realized that we need not do a pure translation of every word. In fact, some words and phrases are more commonly used in English (even by non-English speaking people)

Step 5: Introduce Language Selection Option

Finally, after all this, it was time to introduce the language selection option to the users across the user journey. We introduced the language selection screen in the signup flow for the new users and on the home screen for old users. The hierarchy of language options on the app was based on the city of the user with English always being the second option. For example, a user in Kanpur would see Hindi first, English second, followed by other languages.

What was the outcome?

Gathering such fine insights and customizing our product for non-digital natives helped us gain tremendous trust in the trucking community. We spent several months reiterating the smallest of the product features based on our user feedback, their preferences and behaviors. The outcomes that we have been seeing since has been very inspiring. Here’s the impact in numbers:

Conclusion

Working on a helpful and engaging product experience while maintaining consistency in language and tone is an ongoing process. With the processes that we have established, we hope to improve our conversation with our users at every stage.  The learnings, the un-learnings and grassroot level impact have been able to create so far has been very encouraging for BlackBuck; making us believe that we are moving in the right direction in our journey of building tech for Bharat and digitizing the trucking ecosystem at scale.

But this is just the tip of the iceberg. We are geared and excited to innovate, build and design several more compelling products that will drive the future of trucking...

Blog design by Puranjai Pratap

Read Part 1: https://eng.blackbuck.com/why-humanization-and-localization-of-product-is-critical-in-fueling-digital-inclusion/

Introduction

India is predominantly a vernacular country. Out of its 1.4 billion population, only 140 million people (~10%) speak English and less than 0.1% of the total population speak English as their first language in India.

Language today is arguably the biggest critical barrier to digital inclusion in India. While the country is experiencing a digital revolution, is digital truly inclusive in India? Despite the country being multi-lingual, English continues to be the dominating language of most digital products that are available today and some of the devices in the market also don’t support vernacular fonts creating an added layer of complexity in building apps for Bharat.

Legacy industries particularly such as transportation and Logistics are the types of industries where the literacy of English is well below the standard 10%. At the same time, these industries are undergoing digital transformation with mandates like Fastag, GPS coming into effect. If a trucker sitting in a remote village needs to adopt to digital, he needs a trustworthy digital partner, an app that is easy to use, technology that is empathetic to his limitations and most importantly is in his language of convenience.

Truckers in India are the last bastion to be included in the digital economy. He is a different user from a regular eCommerce consumer, localization and humanization of the user product experience is extremely paramount in gaining the trust of the trucking community. And this is what we have been doing at BlackBuck; continuously understanding the nuances of the trucking ecosystem to customize and better our product offerings. The journey hasn't been easy though! We made mistakes, we listened, we learnt and we went back to the drawing board, when we had to.

In this two-part blog series, we attempt to give you a peek into what goes behind designing tech products for the underserved small fleet operators of India and the several insights that emerge along the way...

A Typical BlackBuck User and His Needs
First, let’s understand the demography that is using our BlackBuck app. A typical user in this highly unorganized and undigitized industry has the following persona:

• Male, typically in is 30s/40s.
• Class 8 or 10 graduate.
• Not tech savvy but has a basic understanding of the core functionalities like ‘scroll, search etc., that are common across apps.
• English is not his first language. Only a handful in his community / peer group can read and write basic words in English.
• On an average receives or makes 50+ work calls a day. Has limited mental bandwidth to ‘explore’ apps.
• Trust in online platforms is very low and the onus lies on the tech platform to gain his trust.
  

Such a user needs a lot of convincing and handholding throughout the adoption journey. And if this needs to be done at scale it requires a combination of human touch and a superior product experience. On the one end, we laid the foundation for a large distribution network with people deployed across 14,000 pin codes of the country and on the other, an app that is highly customized for a trucker. A fleet operator, unlike your urban consumer, is not willing to invest in a product or a service for the sake of convenience. This customer is struggling day in & day out to make his ends meet, he will try only those products which can make his economics improve.

The challenge in product designing was always about whether we are solving the right problem for the truckers which helps in improving their business. Are we addressing the trust factor? Is our service reliable, that works 24*7? Can my customer reach out to my team even at 3.00 am in the morning? And finally, is my product in their language of convenience?

How did we first find out about the need?

The above discussion makes a solid case for the Humanization and Localization of the content. This was something that was also consistently observed by our Product team in all their User Immersion sessions. Even our ground sales team had given us input that a decent chunk of users was having a tough time using the app in English

We also found some users who had learnt the buttons and sections by color and location on the screen.

• This was still a hacky solution for categories which are transactional in nature (For example - Features like recharge that have fixed steps and can be memorized.)
• In an exploratory category like a Marketplace, this method was falling flat and thus adoption was suffering.

All this was further supported by a few data points like:

• Digitally acquired customers from vernacular ads had a higher drop-off rate after installation because while the ad was in their language, the app wasn’t.
• Outbound User Telecalling activities showed that the low adoption of the users was primarily because of the language barrier.

How did we validate the requirement?

While the inputs were coming from all directions, it was important for our product team to validate these requirements at scale and then lay down the path ahead.

The first part was verifying if this was the user's conscious need. Were they already phrasing their problem statement into a need for this feature? Or was this a latent need that would solve the issues of the user?

Based on extensive user research, the team was able to identify that this was a clear need for ~40-50% of the users. However, they were not able to put this exact solution requirement into words. Thus, we needed to revalidate the same with some sample designs!

The team then identified the top primary languages for ~95% of our user base. These came out to be Hindi, Tamil, Telugu, Kannada and a few were comfortable in English. We built sample screens for these users and did extensive user immersion with over 50 users across geographies in the North, South, East and West.  

When we piloted this in the market, we received positive feedback from the users. Truckers were elated to finally be able to use a product that solved THEIR problems in THEIR language, all the while being easy to use and understand. The users also liked the fact that the copy style was more conversational and personal and felt less like a machine that was communicating to them!

One prime example of the power of localization was seen during the following meeting with a fleet operator:

We visited a truck owner, whose daughter helped him out with the business. We attempted an experiment with this duo. We showed the trucker the BlackBuck app in English and he was quick to respond - “I can't read English. Please explain it to my daughter”. We then showed a vernacular translated sample screen to the daughter. As soon as the trucker saw the app screen in vernacular, he became interested in the app. He immediately took away the phone from his daughter and started using it himself. He then went on to ask questions about our service and product.

Rajendra Kumar who was previously dependent on the younger generation when it came to managing tech was now included in the digital realm thanks to localization.

Plan of Action…

After we had validated the needs of the users, the next step was to sketch a plan of action for the product copy to be unified in all languages and tones. It wasn't enough to just launch our products in vernacular languages, we needed to go deeper with our product localization. We wanted our product to speak to the users the way they talk on an everyday basis - simple, informal, conversational, contextual and a mix of English with their local language. Hinglish, Kanglish, Tanglish - you name it, we created multiple combinations of copy to make it highly relatable and convenient to use.

How did we do it? It was a lengthy process that yielded the results we were looking for. Stay tuned to find out...

Blog design by Puranjai Pratap

Part 2 coming soon!

For an organization, these changing realities of employees calls for a closer examination of the support structures in place for their team.

Here’s how the People Function stepped up to address employee concerns:

A.     Dedicated COVID Helpline

Rapid response team of volunteers from Admin & HR Teams to assist employees for any COVID-related emergencies – ranging from doctor-on-call support to assisting in procurement of oxymeters & oxygen concentrators for those affected to hospital bed booking

B.     Tele-Consultation Support

With reluctance kicking in to visit health centers, comprehensive health check-ups and care for other non-critical, lifestyle diseases has taken a back seat. This led to the launch of a company-sponsored tele-consultation support 24*7 for employees and their family

C.     Vaccination

With vaccination emerging as a key shield to strengthen the fight against pandemic, awareness campaigns were initiated in early April org-wide via the “This Is Our Shot” campaign.

In major cities, tie-ups with hospitals were explored to ensure access for not only our team members but also our customers including truck drivers.

Parallely, recognizing that people managers are key influencers who can be leveraged to encourage employees especially in junior levels to overcome hesitancy to vaccine and be sensitized on the need for protection, people managers are looped in to ensure a safe, vaccinated team.

D.     COVID Suraksha Campaign

We power 30% of the trucks running on our National Highways and playing a critical role in the logistics sector, the backbone of India Inc. Even as we continued to work during the pandemic, for our on-ground team members, it was critical that they go out and work on the field to get the economy moving.

A comprehensive assistance package was designed keeping these COVID warriors in mind – COVID Suraksha program.

                                “When Times Change, So Must We”

Mobile apps have become a new way of interfacing with products. Securing your mobile apps is as important as coding it the right way. The users share personal data with mobile apps and it is our duty to our customers to keep this information secure. There are many tools available to the hackers which make the apps vulnerable if the right security measures are not put in place and therefore application security can no longer be an afterthought but a foremost one. Without the right security measures the entire business is vulnerable to huge losses.

App security can be divided into two parts. Securing Communication with the backend and securing the data stored on the device. Below are a few security measures we have used in Boss App.

Securing Communication

SSL Pinning

Man in the middle attacks are common attacks that can compromise user's private data. In order to prevent MITM attacks certificate validation can be implemented. However this type of validation is basic and does not protect apps against many types of MITM attacks.

SSL Pinning is a full proof method to avoid MITM if configured correctly. In this approach the connection between the client (i.e. Mobile App, Web App) and the Server is validated even after SSL handshaking. The client app developers embed / pin a list of trusted certificates during development. These trusted certificates will be compared with Server certificates during runtime. If there is a mismatch between Server and Client Side certificates, then the connection will be disrupted and no further communication will happen between that client and the server. Once SSL pinning is enabled, it will be impossible to use proxy servers like Charles Proxy to intercept the traffic between the client app and server to see HTTP requests, responses and headers as the client app is itself verifying the root certificate and will not accept Charles Proxy certificate and will fail the connection.

SSL Pinning isn’t only effective for Network calls but it also safeguards the webviews present in the Client app. Once enabled, the same certificate validation logic will apply for all the web resources which will be loaded in the webviews. That way it’ll be difficult for an attacker to load any malicious website in the Client app’s webview by tampering it. Make sure that you review your SSL pinning configurations

SSL pinning is a must-have for modern applications that respect user data security and privacy and is an essential part of OWASP guides for several platforms. Mostly, because Public Key Infrastructure design is not perfect and has some weaknesses(public/private key rotations).

Disabling cleartext traffic

Cleartext traffic means when data is transferred over the internet using http instead of https.
This is dangerous as the network calls can be intercepted and the data being transferred can be extracted and misused. This puts the user’s private data at risk.

HTTPS uses Transport Layer Security (TLS) to encrypt and protect user data.

So when sending data like
“Hello world”

when intercepted might look something like
“NP+497DYy2VdhAD9tYi/yQ==”

Cleartext traffic is disabled by default. This should not be enabled unless there is a real use case.

Securing API keys

Many times mobile applications depend on third party SDK where we need to pass secret credentials or API keys to authenticate their account. In most cases, app developers hardcode these keys in either app Constant or gradle files. This way API keys can be compromised as anyone can decompile your apk and find these hardcoded keys in code.

For the same reason, hard-coding API keys/credentials into a mobile app is widely considered to be a security flaw.

In Android, there are different ways to handle this issue:

1. Store keys in Encrypted SharedPreference
2. Public/Private encryption of keys
3. Using NDK

Securing Data

Disable access for rooted devices

Rooting/Jailbreaking is a way of gaining superuser access on the device. This allows users to access any app’s private data and also edit things like user preferences and SQL databases.

To prevent misuse of the user’s data we detect if a device is rooted and disable access to the app in that case.

Shared preferences encryption

Shared preferences in Android is a quick and easy way to store small amounts of data like user preferences. It is a simple xml based storage mechanism and the files are stored in your app’s data folder, which means that no other process on the device can access them without superuser access.

But when someone has superuser access, these files can be accessed and data can be read or updated. For example some IDs which are auto-incremented on the backend can be used to perform api calls and modify another user’s data. Also it can be edited to allow users access to features that they should not have.

To protect user data and prevent any sort of misuse we have started encrypting shared preferences.

Database and Query Encryption

SQLite is widely used in most apps to store app related data. This data will be exposed if the device is rooted. For this reason it is advised to encrypt the data stored on the database. There are libraries available which can encrypt data stored on the database.

Another vulnerability with plain text databases is the risk of SQL injection attack where an attacker can execute or store malicious data in your database. With an encrypted database they won’t be able to perform SQL injection attacks.

Keeping raw SQL statements in your code is another potential security risk. If an attacker reverse engineers your app’s apk, they can potentially get the access of these plain text SQL queries. Thus it will allow them to modify their SQL Injection scripts to compromise your data. Instead of using RAW SQL statements, if we use PreparedStatements and helper functions provided by SQLiteDatabase for performing all types of CRUD operations, then it’ll be difficult for the attackers to understand your schema and query structures.

If you implement the above security measures in your application with the right configurations in place then your app will pass all basic security audits which means basic security for app network data and app storage data.

Business Processes are the fundamental building blocks of every business. In order to achieve objectives of the business, processes are implemented which are performed by actors, which can be systems or employees.

These processes help the teams perform the tasks in a systematic, predictable way which eventually contributes to consistency in performance.

But as they say, with consistent performance comes consistent efficiency.

As a first step to close on inefficiencies, management needs to be vigilant of the process gaps, which is best achieved today by Data. Accumulated data solves for visibility, and overtime, starts showing patterns or insights. This helps businesses realize and focus on, the systemic problems and implementing solutions for them.

At Blackbuck, before July 2020, our order fulfillment operations didn't have enough automated visibility to answer the following questions in real-time:

• How are my team members performing?
• What are the root causes of performance gaps or what can we do to improve our efficiency and performance?

To address both the issues, we built a process or workflow on-boarding platform or a workflow engine AKA Karma!

So without further ado, let's dive right in …

Terminology

A Business Process Model or Workflow explicitly defines steps/tasks and execution strategy of a business process.

A Tenant is any service which defines a business process model in the workflow engine.

Workflow Management Systems or Workflow Engines are software systems whose objective is to assist the actors in performing tasks and to collect and manage, data and associated configuration, based on tenant's requirements.

Workflow Patterns are design patterns specialized for Workflow Management Systems. One of the ways to classify them is by execution strategy, for e.g. serial, parallel, multiple paths, synchronized executions et c.

Design

Objectives of our workflow engine are to

• Implement business processes as a configuration
• Onboard employees and services which can perform the tasks defined in a workflow
• Allocate tasks between team members based on permissions in a load balanced, round-robin manner

Workflow Pattern

Imagine, you are in a bread processing factory. The factory might be highly automated with minimal manual labor or can have a lot of people working in it. Regardless, you'll see that the bread-making process will remain more or less same, namely, Doughing, Molding, Baking, Packaging and Shipping. Each of these steps can have multiple steps within, depending on different sizes and shapes of bread required.

Here, execution of each step is in a well-defined sequence which makes this a business process model or a workflow pattern.

To incorporate a majority of Blackbuck's order fulfilment processes, we implemented a particular flavor of workflow pattern defined as,

A graph where nodes are tasks and edges are execution conditions. Execution can happen

1. either parallelly and independently, or
2. in serial, where next task starts on completion of previous task only, or
3. in combination of both

There can be multiple start points and multiple end points of a workflow

A workflow doesn’t complete unless all executed tasks have been completed

Within this workflow pattern, we also introduced support for two kinds of tasks, namely,

• Form Submissions, utilized for Data Entry, Request Approvals within organization, and
• HTTP Calls, to execute logic or fetch data present with tenants

Business Process as a Config

In order to ease the development for tenants, a business process can be on-boarded as a configuration. If the configuration complies with internal constraints of workflow engine, tenants can run workflows without any development.

For configuration definition, we used relational schema to store the business process model and execution information, for instance

• Allocation Strategy
• Employee Hierarchy
• Permissions, for performing manual tasks
• SLA
• Scheduled Delays
• HTTP API information for HTTP call task
• Notifications

As a result, most of the configuration changes take effect at runtime without any extra effort.

To provide dynamic behavior on processes, we use

• Jayway’s JSON path syntax, since majority of applications and services communicate with each other in JSON format
• Spring Expression Language, to execute logic based on states available in different contexts of workflow execution
• Tenant's HTTP API Information, stored in DB, to give the tenants control over individual features of their workflows

For instance,

Within a workflow w, if a task t1, where we called an API to perform some action on a tenant, is being completed and we want to decide whether the next task after t1 should be t2 or t3, we can write conditions based on context associated to t2 and t3.

So say, t1 task is a verification of a document image with data entry. Once the data is entered, it is submitted to the tenant and tenant can internally decide to either APPROVE or REJECT the document. Based on each possible result from tenant, conditions of execution for t2 and t3 tasks can be as follows

For t2, where we want to trigger payment after approval

#responseEntity.getStatusCodeValue() == 200 && #expressionEvaluator.getContext().read("$.status") == 'APPROVED'

And for t3, where want to an employee to upload correct documents based on rejection criteria

#responseEntity.getStatusCodeValue() == 200 && #expressionEvaluator.getContext().read("$.status") == 'REJECTED'

Where responseEntity and expressionEvaluator are JAVA variables available in the context where this expression will be evaluated at runtime

State Transitions

Within the engine, we have defined states and transitions that a node or a task in the workflow graph can undergo. All tasks in all workflows go through this one finite-state machine.

Depth of Configuration

Workflow Configuration has various levels based on elements of workflow graph and context of business object

• L1 - the default behavior of the system with default configuration format.
  
  For e.g.
  SLA of a task is decided by a static configuration in DB. Based on this, system escalates the task if it's not completed within given SLA minutes
  
• L2 - specialized configuration which overrides the default behavior at a workflow level, task level or execution condition level.
  
  For e.g.
  SLA of a task might be dynamic depending on tenant's requirements. So provision is given within DB config where tenants can add HTTP API information which workflow engine will utilize to calculate SLA at runtime.
  
• L3 - Request body or Event message, which overrides all configuration and based on data provided to engine by tenant for an instance of the task.
  
  For e.g.
  Team members can dynamically decide SLA based on situation on ground and live contract negotiation for a particular order.

These levels of flexibility in configuration help tenants to control the workflow in any manner they want.

Workflows in Production

We have on-boarded 8 individual processes related to 4 different business use cases which are running in our production.

This includes:

• On-Ground Fulfillment Process
• Internal Document Verification Process for Fulfillment
• Driver Verification Process
• Information of Supply Charges to Partners

Future Enhancements

In upcoming sprints, we'll be extending the workflow pattern definition to include more flexibility on execution. Such as

• Infrastructure Orchestration for different workflows and tenants
• Making workflow on-boarding process seamless with a clean UI
• Experiments on different workflow versions

TL;DR

Business Processes are key components of any business. And they are driven by consistent performance over consistent efficiency.

We developed a workflow engine which maintains business processes as a config. Our tech stack consists of:

• MySQL and Mongo, which utilizes JsonPath and SpEL notation wherever required
• Spring Boot, as the development framework
• Redis, for distributed cache
• Kafka, for asynchronous messaging

Our workflow engine can store and execute multiple business processes simultaneously and independently, which might belong to different teams and tenants. Supported task types are Form Submissions and HTTP Calls.

This has increased our visibility and control of the work our teams do which has improved communication and SLA adherence, specially in operations.

Overall, it's low-code development platform for business process models

Image Source: MIT News

Blackbuck offers many value added services to fleet owners apart from end-to-end management of freight services for corporates & offering a low cost marketplace for shippers & truck owners. These include Fuels, Tolls (read FASTag), GPS etc. Most of these value added services require a solid payment infrastructure to facilitate seamless digital transaction

To ensure superior customer experience, our payment system consists of many microservices like inbound, outbound, fraud etc. Most important services among these are the Inbound Service (This is integrated with many payment gateways by which customers can pay for Blackbuck services) and the Outbound Service (This service is integrated with different payment gateways to either return money to source or to give incentives).

FRAUD TYPES

Considering these are digital payment transactions and that BlackBuck also offers special incentive schemes to promote usage of our services, there exists a strong likelihood for frauds to happen. Listed below are some of the common types of fraud we have seen:

Payment instrument fraud : Payment instruments refer to the different types of cards like credit card, debit card etc . The common cases observed here include a) Instances where a person uses other person's card or transacts using a) stolen card etc b) In some cases where the same customer is found to use more than 10 different credit/debit cards.

Misuse of incentive : We sometimes run Referral Schemes where fleet owners are rewarded for referring new users to the BlackBuck platform. For eg. If a new user signs up with an existing user’s referral code and performs X Rs worth transaction, Y Rs is given as referral benefit to the new user and the person who referred to him.

We have seen many cases of fraud reported in this system. (Customers started creating dummy users by colluding with a sim seller to get as many new sims as they want) and all these new users were given Y Rs along with the person who refers so X*Y Rs  was incurred as a  “loss” by BlackBuck and random dummy users were being introduced into the system who would drop off anyway in 1-2 months. This also provides an incorrect picture of the actual retention numbers of the product.

SOLVING FOR CASES OF FRAUD

Post an extensive research, we came up with a solution to identify the clusters of users based on IMEI numbers of devices. When a new user who is signing up from a device and that device IMEI belongs to an existing cluster, then the user and the referrer will not be given any referral benefit and this new user will become part of this cluster. In each cluster we created a graph connecting IMEI number, phone number and some other attributes.

In Blackbuck,  we have many services which provide incentives and if this solution is tightly coupled with a specific service, then it will create dependency on the owner service. Hence we decided to create a platform where we will feed the data into the system and any other service can add their rules in the rule engine and rule engine will be responsible to run rules on the data.

Next challenge was to pick the right data storage and as I mentioned earlier that we wanted to create a graph between different attributes which automatically ruled out the possibility of using mysql or any other relational database. Among available graph databases we had decided to use orientDB.

OrientDB is an open source Nosql DBMS written in Java which supports all modes like schema-full, schema-less and schema-mixed and provides extendible-hashing and b-tree based indexing and supports key/value, and documents. In orientDB relationships are managed as graphs which connect records.

System architecture and flow :

Whenever a user goes for any transaction, a request is first sent from the Accounting service to the fraud service which runs predefined rules and returns a double number between 1-5. 1 being low risk and 5 is the highest risk profile. After getting a response from the fraud service, the accounting service decides whether it should go ahead with the transaction or not. After the completion of a transaction, the accounting service sends transaction related data as events to the fraud service via broker.

Why Use A Broker Software : In Blackbuck,  we handle a high number of transactions - that is why sync calls were avoided as we did not want to bombard the fraud service with the data which will be used later. This led to choosing Kafka because consumers can consume data at their own pace without putting pressure on the service.