Redesign Notifications for delivery partners
(Rappi)
P R O D U C T T H I N K I N G /
V I S U A L D E S I G N /
U X R E S E A R C H /
I N F O R M A T I O N D E S I G N
Redesign of the notification system to unify order assignment flows, transforming scattered, inconsistent interactions into a cohesive experience. Improving clarity for delivery partners and driving operational efficiency (SoyRappi App)
CONTEXT:
SoyRappi is Rappi’s dedicated app for couriers. Through it, they receive, manage, and complete delivery orders. Rappi is one of the largest on-demand delivery platforms in Latin America, operating across 9 countries with millions of monthly orders.
SoyRappi has been an app that has grown and evolved as the business scaled, and the notification system for RappiTenderos (RTs, our couriers) was no exception. Over time, notifications were designed reactively for different order “verticals,” which led to inconsistencies in both information and interface. As a result, the overall experience became fragmented.
Currently, all RTs receive order assignment notifications. Depending on their configuration, they can accept or reject an order, or in self-acceptance mode, the order is automatically assigned and started. However, since there are several “verticals” or types of orders, the notifications vary: the interface is inconsistent, and the information displayed changes from one case to another, as each notification was created independently as needs arose.
On one hand, notifications often lack enough information for RTs to prepare in advance and understand the full context of the delivery. This can lead to confusion and inefficiencies, negatively impacting KPIs such as:
- The NPS (satisfaction of the RTs)
- Acceptance rate (rate of acceptance of orders)
- Completition rate (successful completion)
- Contacts to support (to ask information or cancel the order)
On the other hand, new RTs need a lot of support from the old ones, they ask questions in informal groups (facebook and whatsapp) and spend a lot of time trying to get enough clarity and sometimes being afraid of making a mistake because the interaction is not entirely intuitive having not the best user experience.
Team:
Katherine Moreno (Product Designer)
Sara Restrepo (Ux Researcher)
Jhan Machado (Pl squad Core Fullfilment)
This project had several stages, where we initially validated a V1 of the proposed design by doing research and with these findings a V2 was adjusted with which a pilot was carried out in all verticals.
Currently we show very little data, and there is no consistency across different notification types and verticals. Sometimes we tell them what type of order it is, sometimes the distance (but only from the restaurant to the customer) or the address of the establishment, but in general we show them almost no data and the RTs accept or take the order without being so clear that they should do or if they will need a lot or a little money to be able to fulfill the request.
Previous research:
Together with the PL about 2 months ago we carried out a quantitative and quick research to understand a little the current experience and the vision of the RTs before this type of screens. It was a survey with approximately 3,000 responses where we emphasized the information that seemed most relevant to them at the time of receiving an order request.
With this we gave ourselves an overview of the situation and from product we realized that more than an "improvement" we needed to make a redesign well thinking of all the verticals and having a clearer outlook we decided to start a more complete and qualitative investigation.
Objective:
Identify the current experience and needs of the RTs regarding order assignment notifications and from what was identified with the RTs, answer some questions and decisions about the new experience, such as:
Shall we show you the map? What do we include on the map?
Do we show them the distance or just the directions? How do we show them? Distance to user or store or both?
How do we show them the profit? Do we break down the profit with tips, incentives and so on?
Do we show them which payment method they are going to use?
How do we show them the customer's payment method?
What happens when a RT cancels the order? Important to know why he rejected?
Do we show them the number of products they have to pick?
Should we show more information about the store or restaurant (main verticals)?
METHODOLOGY (Research + Design):
How did we do?
Phase 1:
1) Review of existing research results:
-
Survey in typeform (2934 responses) where topics such as:
- Information and general data
- Sound and vibration
-
The product leader had a advanced benchmark, with which it was analyzed what the other Apps are doing, both direct and indirect competition
2) Identification of currect experience (AS Is)
Focus group (virtual) with 12 RappiTenderos (delivery men) from Colombia, identification of topics such as:
-
Type of notifications
-
Information and attributes
-
Interface
With these insights, we built a “wishlist” of improvements that would later guide design decisions.
Phase 2:
3) Design V1
4) Proposal validation
Phase 3:
5) Design V2
🥂 Wish list (Typeform and focus groups)
3) Design:
Based on the findings and with the "wish list" of the RTs, I proposed to design a V1 only with the main verticals to validate them and later with these new findings, to be able to extend the proposal with its improvements to the other verticals. Within these proposals, there were different types of information to be evaluated transversally (payment methods, distance, directions, instructions, etc.)
The notifications of 3 verticals were selected, which are the ones used in the majority of orders and are:
-
Restaurant: With and without self-acceptance
-
Supermarket: With and without Self-acceptance
-
Rappiturbo (fresh productcs with express delivery)
Taking into account the "wish list" of the RTS, I made a proposal contemplating the majority of information. On a visual level, I wanted to keep in mind the redesign I did of the home to create a consistent and modern proposal.
I also intentionally proposed a differentiation of colors to help identify the vertical (or type of order) and the use of tags to add the payment method. This in order not to increase the cognitive load and generate recall through the different elements.
4)Proposal Validation
Considering that the change was so large, several issues had to be mapped in this validation:
-
What information is really relevant? and help for RTs
-
Whether any data could increase cancellation metrics
-
If any information could cause more doubts and therefore increase the contact to Support
-
Whether any data could cause a lower acceptance rate
In addition to this, review each design decision such as: consistency with the home, the differentiation of colors (if it was intuitive and useful or on the contrary it added weight to the screen) etc.
What we defined was:
-
Moderated 1:1 usability testing
-
12 users (RTs between Mexico, Colombia and Argentina)
Findings:
Two types of RT were identified in the usability tests (which would imply consideration of different approaches to facilitate their understanding):
-
“The smart”: corresponds to the RTs that identified the changes and easily understood each of the designed elements
-
"The oldest": Corresponds to RTs who have difficulties adapting to views different from those they are used to
In general terms they observed everything but they pay attention to the map and the icons to know if it is a restaurant or another type of place.
-
In general, the design was perceived as an easy to understand design, with some elements to improve.
-
The use of colors for the differentiation of types of orders was evident and valuable.
-
Turbo notification needs to be adjusted as it caused confusion (see gallery)
-
Knowing the payment method seemed very good to them because they consider it essential to prepare in advance to deliver the service.
-
RTS first look at gain and distance (and correlate them).
More detailed results (in Spanish) ⬇️
Design V2
We made the necessary adjustments to the design and extended it to other types of notifications. After that, we developed a pilot in various countries (with a limited number of RTs and for a specific time) with the new notification designs to identify the possible impact on indicators such as:
-
Acceptance Rate
-
Support contact decresead about 15%
-
RT NPS grew 1 point
-
Completion rate increased 10%
-
Order Churn was reduced in 13%
-
Adiccionaly the first order completion time was reduced 8 minuts (for new RTs)
So, based on this pilot, we decided to extend the development to 100% RTs (≈300,000 couriers) and obtained similar results.
As part of the final iteration (V2), we consolidated the different order types (known internally as “verticals”) into a consistent notification system. Each vertical had its own particularities: for example, restaurant and market deliveries, instant “Turbo” orders from nearby stores, product “Sampling,” money delivery via “Rappicash” (going to an ATM if needed), and personal errands through “Rappifavor.” Previously, each case was handled differently, with fragmented interfaces. By unifying them under the same structure, we created a seamless and predictable experience for couriers across all scenarios.
Key learnings:
-
Collaborating closely with product and research leads to a more holistic approach: usability, utility, aesthetics, and measurable business impact.
-
Compared to when I focused only on UX, now I feel I can make more informed product decisions, with a clearer view of how design choices affect metrics and user experience.
-
Cross-functional teamwork also makes it easier to identify when something is negatively impacting results and adjust quickly.