Error messages were designed to scale to include future verticals.
Scalability
Designing scalable messaging across verticals in Grab
Trust Messaging Redesign · Grab · 2022UI Design
UX Design
Content Writing
Internship
About
As part of a 3 month internship in Grab's Trust, Identity and Safety (TIS) team, I needed to improve the consumer experience touchpoint for their Fraud Detection system – Error Messages. This work was done in 2 weeks.
What I did
Contextual Inquiry
User Flows
Content Design
UI Design
Team
Choo Yuan Jie · UX Designer
Loks T · Product Manager
Results
Increase chances of customer getting help from Grab Support.
Support
Re-designed UI components.
Design
Background
Grab's Fraud Detection API provides protection against fraud by analysing user actions.
Once these rules are met, the API returns a suggested treatment (e.g. block, allow). Each treatment alters the user flow and I was responsible for designing for the block and ban treatment for a few checks.
These checks are situated across the whole of Grab's service verticals (GrabFood, GrabMart, GrabMerchant…) and the current error messages interfaces were generic.
Summary
1
Understanding Fraud Checks
Learnt more about the fraud checks, formed design criterias & success measurement. Looked at each vertical's user flows and found how each designer tried to approach errors.
2
Primary Research
Tested current messaging on 3 people for feedback. Synthesised feedback to craft error message.
3
Solutioning
Iterated error message for deterrence and diplomacy.
4
Scaling across Verticals
Broke the content down into modular parts that can fit into different scenarios. Place content back into each vertical's interface.
Understanding Fraud Checks 1 — Content Structure
Fraud checks are never fully accurate and returns false positives.
When these checks return false positives, innocent people might end up seeing these error messages. Those people might be valuable Grab consumers. As such, we should also design for a recovery path (diplomacy) and a deterrence path.
The success measurement for this redesign can also be how many false positive (innocent) people are able to self-recover from these error messages.
Understanding Fraud Checks 2 — User Interface
Fraud checks are implemented throughout different flows, so they have to be adapted to each one.
When analysing the different user flows from each vertical, a few trends were that error messages existed either in a full screen, a pop up or a bottom sheet.
Consideration 1 — Exit Points
In an error state, we should ensure that there's not too many exit points, especially if they lead to different places.
Consideration 2 — Alternative Path
If a user hasn't expanded all their ways of getting a reward, we should not stop them to do so (because they can still go through checks).
In order to keep the UI consistent, we decided to follow a strict logic with a few reasons.
Primary Research — User Interviews
Were they ordering an item, booking a ride or finding a subscription?
I spoke to 3 grab users and asked them to re-enact their experiences in those scenarios to gather some sentiments. I observed that people reacted differently based on which scenario they encountered the error message.
Observation 1 — Time Sensitivity
The user's goal are time sensitive and people might just want to continue to reach their goal (ordering a food for lunch, booking a ride).
The test was conducted in a unstructured manner, and users were only tasked to remember their past experience with the error messages and then describe how they would react.
Observation 2 — Intentionality
If a user were intentionally trying to find a reward, they wouldn't mind retrying to get another reward and getting help.
Solutioning
Crafting a message that demonstrates deterrence, diplomacy and sensitivity.
A few rounds of iterations was tested with colleagues, before finalising on “Enable Continue 2”.
Scaling
Adapting each error message into their verticals while taking into consideration engineering constraints.
Following the logic defined previously, I adapted and contextualised the messages across the different verticals. While some solutions were too big of a change to implement, I designed a few scaled down solutions to facilitate smaller change steps.
Interface Logic
Rule 1
If the prior screen is in a bottom sheet, the error message will be shown in a bottom sheet.
Rule 2
If the prior screen is a full-screen, the error message will be shown as a pop up.
Rule 3
If there are other exit options (or other ways to use an offer), the error message shouldn't have a CTA.
Reflection
Lessons from this short project.
Lesson
Intuition, when there is no where else to gather evidence.
Sometimes, it is important to leverage on our own experience as evidence to move a design forward fast. Tapping onto colleagues' feedback, and prior knowledge is key in a fast moving environment. Design decisions are calculated guesses. This project's outcome didn't leverage on primary research and validation, which sped the completion of the project up.
Lesson
Remember the voice for edge cases.
When designing content and messages, we should always remember the current intention of a user. In our case, an innocent user might be suddenly hit with an error message out of surprise. In this scenario, we should be sensitive with our messages.