Offer Details Revamp

One of the reasons why so many users fail to use promo in the Grab app is because they keep hitting error in every attempt. In this project, we will redesign the offer details page so that it is easier to comprehend hence helping users to mitigate the errors.

This project showcases how I simplify complex concepts into user-friendly interface. A lots of cross-functional collaborations were needed in making of this project.
Overview
Context: redesign existing offer terms and conditions page
Markets: all Grab markets (8 countries)
Duration: 1 month
Released: TBD
My Contributions
• Being the only designer to work on end-to-end design process from conceptualise to spec deliver
• Planned and moderated usability test
Observation
It seems obvious that no one likes to read the wordy long page of terms and conditions. We rather hit 'next' and go on with life until errors occur and then see ourselves facing 2 options
• Now read the terms and conditions and try again.
• Asking 'Do I really need this?'. The answer often is NO.

Same thing goes true, especially true, for the promo application experience in Grab app. We notice 60% of the application attempts are fail and all due to the user not meeting requirements.
During user interview and observation in user testing, we know that only a handful of users bother to skim through the lengthy text to acknowledge what are the requirements to be eligible for the offers. Also the same set of people complaint there are too many conditions to use offer and they often don't get to use it. In quarter 1 of 2021, we see a significant rise in CE tickets related to promo.
Dig deeper into the problems
Besides the obvious fact that it's a long wall of text not design to read, there is also the inconsistency issue. Due to internal technical complication, the same offer is displayed differently when accessed from different entry point. This cause more confusion to the user when they try to use an offer from several touch points.

To dig deeper into the root cause of why the detail screen is so wordy and badly formatted, we need to understand how it came about. Basically the promo creators, after set up all the complicated input fields from the creation tool, will manually write the description in HTML format. The description or Terms and Conditions is the content that translates all the setup into user-facing language. It is tedious, time consuming and prone to human-error.
Design the front-end solution
The front end solution is pretty straightforward, it is to simplify the information into comprehensible content. We base our design approach on some key principles:

Transparent
Key detail of the offer criteria/requirements should be communicated clearly and upfront.

Simple and Coherent 
Simplify the fields into digestible information list.

Versatile and Scalable
We want to templatising the layout but also allow it to works across all types of offers in Grab.
Standardising data
Instead of a wall of text that is inconsistent, we turn the information into a digestable list. This is actually a dangerous approach because there can be tons of conditions within a single offer but not all of them equally matter to the consumers. So I spent time evaluating all the conditions and review old research insights (card sorting activity for instance) to determine which condition should be displayed to user and which should not.

To make it a lean page, I used iconography. Pictures speak more than words, so do icons. I collaborated closely with a designer from Grab Design System team to come up with a list of icons that would be widely understood across the Grab platform. The icon, together with the content followed, gives the full context without much reading time.
Moreover, the order of the list will be standardised across all offers. What it means is your eyes will always know where to find the payment requirement line on the screen although you just see this offer for the first time.
Standardisation meets flexibility
And what is the most amazing thing about this design? It scales!
We make sure this same design will work across ALL types of offers (we have about 20 of it!) for ALL services in ALL languages. The idea is we shouldn't spend another 3 months to build something else for another new kind of offer.

The components are built to be plug in and out depends on the context.
Mapping the operation solution
Now, how do we get these nicely neatly list out on the display?

The operators shouldn't be responsible to write an advance HTML to serve that, no way!
The answer is we will automatically push the input from the creation tool to human language on front end.

This is one shot to kill 2 birds
• Generating a smart and clean interface
• Saving the Ops from writing weird HTML queries

Load of collaborations had happened. I created a worksheet to map the fields from creation tool into user-facing content. The worksheet is opened as a collaboration space for designer, content writer, engineers and promo operators.

What if there are more to say?
From talking to the operator, I know that there are some terms, mostly legal terms that they need to communicate to consumer to avoid regulation issues. There is no input field for these thing as we don't really validate it from the system point of view. Besides, sometimes the business team would want to communicate ad-hoc lines that can't be registered in the backend either.
That's why there is still a small chunk of text in the final design. By default it will be collapsed as the information in it is likely less critical to know. However, when needed, all the information is there and can be accessed easily.
Closing
A lot of the times we focus on fixing the surface visual but forget the solution can come from the internal operation. Although it looks like a straightforward solution, it takes a lot of behind the scene effort to come to this point. The approach requires the engineering team to rethink how they structure the tool and certainly a bit of refractor needed to be done, but for the better. By H1 2022, the project is on hold.

We don't hope to significantly bring down the 60% fail attempt by this only project but it surely a hygienic thing to do. We projected at least the offer conversation would increase by 1% and CE tickets down to 50pp now that users can easily understand the offer.