Turning a logistics model into an offer people would accept
Envíos Extra was Mercado Libre's first crowdsourced delivery network: independent drivers, their own vehicles, launched in Mexico. As its content designer, I helped shape the product from the first idea to launch. In an app for someone who needed to find the important thing fast, the work was deciding what to prioritise, where to put it and how to mark it, from choosing a route to getting paid.
Scroll sideways →
Mercado Libre had always depended on third-party couriers. Envíos Extra turned everyday drivers into its own delivery network, from a first idea to a live product in Mexico in about 12 months. Nothing existed at the start: no product, no offer, no idea whether anyone would say yes.
I was the content designer, with two product designers, two product managers, Legal in Mexico and a large engineering team. The whole proposition runs in one sequence: come and deliver packages with us, first we need seven documents from you, then you drive, then you get paid.
Envíos Extra runs on routes, not packages
Worth understanding before the rest, because the whole content problem sits inside this loop. Purchase volume shapes each route, and drivers choose which ones to take, a day ahead.
Orders shape a route
Based on purchase volume, the system builds an optimized route.
Goes out as an offer
Drivers see it about a day ahead: the zone, the pay, the hours.
Driver accepts
Each driver chooses which routes fit their day. No obligation either way.
Loads up at the centre
The driver collects the packages and scans them in the app.
Delivers the route
Every stop completed through the same app, start to finish.
Gets paid, in-app
Earnings land in Mercado Pago. No separate system, no bank required.
Three things made it hard, and together they decided what the product could even promise.
A market that was not ours
Mexico, and a model Mercado Libre had never run. There were local colleagues, but we could not assume anything about how drivers worked, what they earned, or what would sound trustworthy to them.
Seven documents before a single peso
Licence, vehicle registration, liability insurance, and four tax documents. All were legally required before anyone could drive, and some take days to obtain.
Drivers already had options
Most were already working for other platforms. The offer had to be honest and still better than what they had, or there was no network.
Getting someone to say yes
This was a large team and most of it was not my decision to make. So here is both: what was happening in the project, and what I actually did in it.
Learning the market from the people in it
Mexico was not our home market and this model was new for the company. The research team ran qualitative sessions with drivers already working for other platforms.
I helped write the questions. We studied what Uber, Cabify and other existing apps offered drivers, because that was what our value proposition had to compete with: what each one did well, how drivers organised a day and how much they earned.
Turning regulation into something you can say out loud
Mexican law decided what a driver had to provide before working. Legal and Product shaped the offer around that, before there was a screen to design.
I sat with the legal team in Mexico, not to learn what the documents were called but what each one was for. It is hard to explain why you need something when you do not know yourself.
An offer that had to beat what they already had
The recruitment landing page was where a stranger decided whether this was worth their time, their vehicle, and a week of paperwork.
I structured the value proposition and wrote the page. It rests on three promises, each one from the research and each one a decision: the freedom to choose when to drive, up to $1,000 a day, and no bank account needed. The notes next to the page say why.
The original landing as it shipped, translated into English.
The freedom to choose when to drive
The first card and the first promise: drivers decide which days they work. It came out of the research, and leading with it was a choice.
Earnings as a ceiling, not a promise
Pay is per route and moves with demand, so the page says "up to" and the footnote says what is included. A confident single number is a lie people discover on day one.
No bank account, as a headline
Straight out of research: the trip to a bank was real friction. Paying into Mercado Pago kept the money inside a system drivers already used.
Seven documents, without losing the person
Sign-up had to collect everything the law required.
"Wait while we complete your registration.
We are reviewing your details before activating your account."
We ordered the requests by lead time, not by convenience. The documents you had to go and apply for came first, so the paperwork was already moving while you gathered the rest at home.
Everything a driver needed to know lived up front in the FAQ, so nobody hit a blocker halfway through. The waiting screen keeps that FAQ one tap away for the person most likely to have a question.
The route you confirmed and can no longer do
Drivers committed to routes in advance, often for the following day. Life happens between confirming and showing up, and a route nobody turns up for is a hole in the operation.
"This cancellation may affect your future requests…
to avoid that, cancel before 20:00."
The modal is honest about the consequence and then tells you exactly how to avoid it: cancel before 20:00. Same rule, same policy, written as a door instead of a wall.
Better to prevent the no-show than to cure it. A warning with a way out turns a no-show into a cancellation with notice, which is a slot the team can still fill, and it keeps a driver who had one bad week instead of losing them to a screen that made them feel like a problem.
The questions that arrive after launch
Once the network was live, drivers had questions, and the FAQs and support were where they landed.
I wrote the FAQs, some anticipated from other platforms, others from what people actually asked once it was live.
They lived in a blog-style CMS where real formatting needed HTML, so the team normally waited on a developer to build a table. I knew HTML, so I did it myself, and taught the rest of the content team to do it too.
Mercado Libre's logistics tools
Operations dashboards gave the team visibility into demand and performance as the network grew, and routes were managed and created in the company's own logistics tools.
The content work did not stop at the driver app: we also made the content changes in the internal logistics tools Mercado Libre used to manage and create routes.
A number, a distance and a commitment
It looks like a simple screen, but it is loaded with information and built for someone on the go. What comes first, where it sits and how it is marked were all decisions.
Drivers chose routes on the go and under time pressure, so plain language and forgiving error recovery mattered more than polish. The app reused what already existed in Mercado Libre's other delivery apps, which is part of why something this size shipped in about a year.
The day they chose
8 de mayo
Routes were booked by day, so the date on top is a visual confirmation that this is the day they picked, even if they saw it in the previous step.
A map next to the address
It lets a driver judge the pickup point at a glance, instead of decoding an address.
The money is the loudest thing
Ganancia · $ 642
Larger and bolder than anything else, because it is the question being asked. Everything else on the screen exists to qualify this number.
The distance you are not paid for
Benito Juárez (3,8 km)
Getting to the pickup point is unpaid time, so the distance sits next to the address. It makes the offer look slightly worse, and makes it honest.
A commitment
Confirmar recorrido
You are agreeing to be somewhere at eight in the morning, and the button should sound like it.
Looking at these screens again, we centred far too much text. Centred paragraphs are harder to read in any language that runs left to right. At the time it was the house style across the company and I did not question it. I would now.
Where I learned to think in products, by writing them
I was in a room where everybody had been at the company longer than I had, on a product none of us had built before.
I learned what good research looks like by shaping the questions, not by reading the findings afterwards. I still write them the same way: work out what decision the answer will change, then ask about that.
And I learned that a screen can look simple and still carry everything a person needs to decide. In a product like this, the words are not a layer on top of the design, they are the product: whether a stranger becomes a driver depends on what you ask for, in what order, and how you explain why. It is still how I work, and I have written about why content belongs at the start rather than at the end.
Learning enough HTML to do it myself, rather than wait for someone else to have time, is the same move I made years later when I built an app end to end.
Hola, I'm Lu. Senior Product Designer, 6+ years across different industries. I start with the real problem, make complexity understandable, and stay close to the outcome. More about me →
