Robinhood: Designing the delivery rider experience in Thailand

Timeframe: 2020 - 2021
Role: UX & Research Lead in a design team of 8

Timeframe: 2015 - 2017
Type: Transformation across digital touchpoints
Role: UX designer in a team of 7 (2015 - 2017); Interim UX lead (2017)

Type: App (iOS & Android), Operations Portal
Status: Launched & live


⏱ project overview

No thanks to the global pandemic, food delivery saw an accelerated and meteoric rise in 2021. Yet, the delivery riders don't always get the best experience, despite being essential and indispensable players in the ecosystem.

The client's ask to my project team was extremely ambitious: design the MVP for riders, from the ground up, with a corresponding operations portal (for operations staff to manage jobs, riders, and requests from end-customers) — all in six sprints in under two months. Because of the tight timeline, we were also only able to run a 3-day usability test at the end of the MVP delivery phase, instead of a preferred consistent in-sprint testing.

This successful MVP push and launch of a first client engagement allowed us to build a strong and stable foundation. On the back of its success, it bolstered Siam Commercial Bank's confidence in our ability to deliver quality — enough to enter into a joint venture with Publicis Sapient to create one of the largest fintech entities in Southeast Asia.

“For the last six months, we are not just partners or vendors. We are a real family that kept building our product.”

— Lead project owner on the client's team

💫 Impact


riders sign-ups

2B baht

earned by riders

40 million

orders fulfiled on the app

Key learning #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 means obvious basics over elegance, and building behaviour over fiddling over unnecessary innovation.

1: Super-clear hierarchy

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)! 


A glimpse of wireflows of the job delivery feature


A truncated sample of the journey for the rider

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.

Secondly, Distance > Money: Our original hypothesis was that the money for each job offer would be the most important thing, but 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.


Pictured: Before and after, with the inclusion of an additional detail, and reworking of the hierarchy

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 (starting and ending 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.


A view of the interaction model and manifestation of the information architecture in the Pocket feature

Finally, we wanted to highlight something as important as the rider's earnings, so that the most important information (i.e. how much they've earned for the day, the number of jobs they did, and the history of their transfers) 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.

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, with any non-relevant content hidden until there is a need to surface it contextually.


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. 


Ooof, 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 what the most relevant information for them is


Colour: A higher contrast was achieved by using a darker background, with card backgrounds being lighter against it. The colour combinations of our proposed changes from the brand guidelines all pass the AA standards of the WCAG with flying colours 🎉


Finally, micro-interactions don’t really matter when riders just want to get to the point, so we had to insert moments of delight when it wouldn't interfere with their core use cases. This meant for a feature like Incentives, it's about being able to represent their progress and achievements using delightful icons while still providing a straightforward interaction model.


Pictured: The exploration between wireframes, where display logic was worked out, and the final iteration of the visual design

Key learning #2

Overcoming barriers caused by distance and language

We had a problem.

Situated in Singapore, 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 5:
Visual screens are used as the source of truth for functional requirements, structure, interactions and content translation

Step 6:
Design QA is done: Functionally first by UX designers, and visual inspection by visual designers

Step 7:
Design QA is done: Content and translation accuracy is vetted by content writer

Step 8:
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.

Eventually, we made the DesignOps decision for our content writer to write the content on visual screens instead, minimizing the duplicative work of updating both deliverables. We also had to revisit our definitions of done and ready, given the additional requirement of the visual mockups for every screen, and ramped up our design system so that the UX designers could make specific changes on visual screens instead of having bottle necks in the process.

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).

With the pandemic, we 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 rest of the team in Singapore were going to be remote, in either situations), or it was going to be moderated remotely. This meant two completely different tech setups, and it got down to the wire on which option it was going to be.


Because of the language differences, we also needed translations to be done so that the design team, product team, and developers could understand the sessions. 


A: Screen-cast from Lookback

B: Questions for the moderator, either additional ones from the team or from the client

C: Participant video, so that we were capturing reactions as we found out that the front camera view provided by Lookback wasn't sufficient, as riders kept the phone on the flat surface instead

D: Translation from Thai to English, in real-time by an additional support from our operations manager in Bangkok who very kindly volunteered for all three days

E: The actual note-taking set-up, where the official note-taker put her notes down in Figma (this was pre-FigJam!) in a makeshift post-its component

While we ease into a hybrid working model after the first phase of the pandemic, I'm sure there are still many ways we could have optimized this setup: Perhaps, if we had a channel specifically for real-time audio translations, or if there was a need to go even scrappier and forgo the live translations altogether. A problem for all of us to solve together for the next time!

Key learning #3

Design management isn’t so much managing the design

🕋 It’s about providing structure and guardrails so that the team can operate as efficiently as possible, and managing the quality that we can all be proud of. 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.

👥 It's about advocating for the team, and demonstrating our 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.

⚖️ It’s about establishing and maintaining bridges 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 finding 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.