Reimagining the COVID-era rider experience
💡 Key takeaway #1
Accessibility looks very different while on-the-go
We needed to design interfaces and interactions with extreme care to their purpose and accessibility. This translated into two foundational experience principles:
Obvious basics, over complex engineering
Building behaviour, over unnecessary innovation
From there, 3 specific areas of focus were identified: hierarchy, interactions, and contrast.
1) Super-clear hierarchy
Split-second decision-making
The rider has less than 30 seconds to decide on whether or not to accept an order, so they need to be supported by sufficient information to ease the decision-making effort.
This is supported by straight-to-the-point screens to display the information they need, and what they need to do.
For example, we found that riders were just tapping on the CTA buttons without actually reading the label, until they reached something they had to do (for example, taking a photo of the food delivered)!
↓ Below: A glimpse of wireflows for the job delivery feature
↓ Below: A truncated sample of how the wireflows translated into the journey for the rider
Mode of deliverables
We started off with 2 sets of deliverables: User flows, and wireframes.
At the start of the project, we decided to condense it into wireflows instead, so that it was easier to refer in discussions with the business analysts, product owners, and engineers, without having to refer to multiple documents.
This worked out very well for us too, as it allowed us to spot scenarios that we might have missed, or logic that didn't work quite well.
Display of information
Our original hypothesis was that the money for each job offer would be the most important thing.
This was proven very, very wrong after talking to users — Distance was the number one thing to know, as taking more jobs nearby has a cascading effect to bumping up the quantity, and therefore a higher daily total earnings.
↓ Below: Before and after, with the inclusion of an additional detail (D), and reworking on the hierarchy of information (A, B and C), based on usability testing insights
From this insight, we were able to make a change to the hierarchy of the job card, and even included another key detail that was missing in the first iteration (sub-districts, which riders assured us would tell them an even fuller story).
There were concerns from the client team that providing that much information would unnecessary make the card taller, and we worked closely to keep the height of the card, and still have it be useful and relevant to the rider.
Luckily, having data from usability testing was able to back our design decision up, and they remained happy with it.
↓ Below: A view of the interaction model, and how the information architecture goes deeper in the Pocket feature
Finally, we wanted to highlight something as important as the rider's earnings, so that the most important information is always surfaced and available to them at a glance.
We also know from the operations team that some of the most common calls they get are about the details of their earnings and balance, and so we wanted to solve that problem by making the detail screen as informative as possible.
This meant showing up front how much they've earned for the day, the number of jobs they did, and the history of their transfers, in order to serve all the common use cases.
2) Super-familiar interactions
We made sure that self-support is easy to access from a consistent spot, and support content is contextual to what the rider needs at that moment in time.
Any non-relevant content was hidden until there is a need to surface it contextually.
↓ Below: A contextual support area for a rider on the job, with options to contact the support center for specific requests around the delivery
For example: If a rider is not on a job, they don't need the option to 'cancel' a job.
But if they're on the job? They need quick access to that option, along with guided steps on how to urgently cancel the order and release the job to another rider.
3) Super-high contrast
We also needed to consider something that we wouldn't, for other apps: Riders will be using this app under the glaring Bangkok sun, and balance between conserving their battery life and brightness that would make things visible to them.
↓ Below: Testing of another popular delivery app, conducted under the glaring Bangkok sun. Oof, just look at that glare
Considerations were made for the following:
Text
Font sizes needed to be big so that riders don't have to squint and try to figure out the most relevant information for them at a glance.
↓ Below: Typography established for the right size, height and relationship between them, while keeping to branding guidelines
Colour
A higher contrast was achieved by using a darker background, with card backgrounds being lighter against it. We also updated colour scales based on the brand guidelines, making muted colours more dynamic in their app.
More excitingly, the colour combinations of our proposed changes all pass the AA standards of the WCAG with flying colours 🎉
↓ Below: Updated colours in the design system
Micro moments of delight
With motion design, it was important that the animations served a practical purpose, especially as riders need the visual feedback to receive confirmation on their actions.
This meant any changes in the screens shouldn't just pop up, and when the rider has performed an action, there should be a strong cue to let them know the action is done.
↓ Below: Various examples of the motion design principles for usable cues
💡 Key takeaway #2
Overcoming barriers caused by distance and language through flexibility
We had a problem.
Situated in Singapore, Jakarta, Sydney, Bangalore, Dubai and Bangkok, the team only had two people fluent in Thai. We quickly realized that client sessions tend to start in English, out of abundant respect for the Thai-illiterate amongst us, but they quickly diverge into pocket conversations amongst the client team in Thai.
It was commonplace for our Thai colleagues to do quick translations over Teams, while we sat in these sessions wondering what some of these discussions were.
But the bigger problem was during the design bits.
During design sprints
What we wanted:
Step 1:
Story gets picked up by UX designers and content writer on the wireframes, while visual designers explore options
↓
Step 2:
Clients sign off on annotated wireflows and key visual screens
↓
Step 3:
Wireflows are used as the source of truth for functional requirements, structure, interactions and content translation + Visual screens as reference templates for developers
↓
Step 4:
Design QA is done: Functionally by UX designers, content and translation accuracy by content writer, and visual inspection by visual designers
What happened instead:
Step 1:
Story gets picked up by UX designers and content writer on the wireframes, while visual designers explore options
↓
Step 2:
Clients sign off on annotated wireflows and key visual screens
↓
Step 3:
Developers required every wireframe translated into a screen, which meant that visual designers had to do mockups for every wireframe, error scenario, and use case from the flows
↓
Step 4:
Visual screens are used as the source of truth for functional requirements, structure, interactions and content translation
↓
Step 5:
UX designers and content writer had to do dual updating on both wireflows and visual screens
↓
Step 6:
Visual screens are used as the source of truth for functional requirements, structure, interactions and content translation
↓
Step 7:
Design QA is done: Functionally first by UX designers, and visual inspection by visual designers
↓
Step 8:
Design QA is done: Content and translation accuracy is vetted by content writer
↓
Step 9:
Client team decides on content changes after sign-off, which requires a whole round of updates once again
🤯
This definitely messed up our ways of working, and was a lot of time spent on duplicative work, which became a source of frustration when the time we had was already so tight.
Solving for the problem: Hacking branches
While Figma itself wouldn't introduce branching as a feature a year after we'd started on this journey, we decided to adopt that concept in our ways of working.
This meant setting up the visual screens that the content strategist would be working on as components, so that design changes get "pushed" to her without disruption to her updates.
Usability testing
Usability testing was held with 10 riders across 3 days, after 4 sprints.
While we wanted in-sprint testing, there were logistical issues (with recruitment of existing riders and their availability, and also, the pandemic still raging on in Bangkok at that moment in time) and had to come up with contingency plans:
It was either going to be moderated face-to-face with our teammates in Bangkok (meaning that the team in Singapore was going to be remote, in either situations), or it was going to be moderated remotely.
We had to work through two completely different tech setups during planning, and it got down to the wire on which option it was going to be.
The hybrid set-up
↑ Above: The IRL setup
A: Screen-cast from Lookback
B: Questions for the moderator
C: The notetaking set-up in Figma (this was pre-FigJam!) in a makeshift post-it component
D: Participant video, to capture user reactions
E: Translation from Thai to English, in real-time
Key takeaway #3
Design management isn’t so much managing the design
Instead, it's also about…
Providing structure and guardrails
To ensure that the team can operate as efficiently as possible, and managing the quality that we can all be proud of, there are so many gears running in the background.
This came in the form of the ways of working, including communications within the team, how sign-offs are made, and how JIRA tickets are assigned and resolved to enable a smooth delivery.
Advocating for the team, and demonstrating value
The value that we bring as a collective whole, while keeping the team motivated on the impact — which, in this case, was many riders on the roads of Bangkok being able to be proud of the work that they do in these trying times.
Establishing and maintaining bridges
Relationships between the other teams like the product managers, and the engineers, and anticipating roadblocks with clients and internal stakeholders. How do we hold the line on what is acceptable for us, while keeping to a very tight timeline and pushing back unreasonable requests to protect the team?
My way, I found, was to over-communicate and rationalize decisions we make, and it's still something that I am constantly seeking the right balance for.
A struggle with radical candor
While it wasn't the first time I'd worked with teammates situated in other offices, we had our first hire at a lead level in our Bangkok office. Everything looked great on paper (and portfolio), but when it came to the quality of the actual design output, there was a lot left to be desired.
There were a few things at play here that made it an even more uncomfortable position, and culture was definitely one of them. There are definitely cultural differences in the way feedback is given and taken, and it took me a long while to tailor the right amount of radical candor (term yanked completely from the eye-opening book) so that my intent was delivered and received.
It is, as some points before this as well, also something I'm still learning along the way: I am the people manager/coach for some of our folks in Bangkok now, and it has taught me the value of encouraging open and genuine connections, even when it might take a longer while to get there.