Designing the core delivery flow

Context

Loggi started out as an app where you'd rent a driver's time and order them to pick up and deliver whatever and whenever. The classic use case was: you're at the airport and right at the last minute, you realize you've left the passport at home. No worries⎯call a Loggi driver, they'd pick the keys up with you, go to your place, and bring it back.

This product was internally called Corp, short for corporative deliveries. The main clients at that point were mostly accounting firms that needed lots of documentation to fly back and forth through the city daily. Over the years, Loggi expanded its logistics portfolio, reaching both the food and e-commerce industries. All of it with the same Corp infrastructure, so you can imagine how much glue it took to make it all stand on its feet.

For a long time, the company operated in a "we're just testing things out" vibe, which did enable a lot of fast iteration. However, 2019 was sort of a turning point, and I joined exactly then.

It was the most stable year the company had so far, mostly in light of the realization that the e-commerce vertical was probably the way to go. Loggi went all-in into materializing a complex logistics infrastructure, with multiple distribution centers, transportation partners, and an extensive network of through continental Brazil.

Rightfully so, that prompted a major re-org which ended up making me move from the team I was initially assigned to (the "Receivers" team, responsible for taking care of the end-customer experience). My focus would be recentered around reshaping the driver experience.

Tap to zoom the image

Loggi's legacy Driver App.

Some of the UIs from the legacy core delivery flow in the native Driver app. These were mostly made with React Native, which later became just a native shell to the new PWA app, using Material UI for the front end. Each UI was developed during a certain era of the company and carried tons of old business logic.

Problem

Reshaping the driver experience was mostly triggered by a new product, called Loggi Leve, which was aimed at tackling the capillarity problem within logistics. It basically was a last-mile franchise model, if you will. Leve means "light" in Portuguese and it resonated with the idea that Loggi would have a light-weight model by partnering up with contractor providers applicable in areas that were usually hard to capture.

In order for that to really happen, we needed to revisit tons of paradigms created on the Driver app within that old Corp product. We called the new version of the app "Flecha" (arrow, in English), and it was way lighter from the get-go. It's not every day you sort of have the green flag to rewrite parts of an app entirely, but it was a lot of work to make it as stable as the legacy version. Therefore, one of the main problems to solve was: how to make this new app useful for every type of driver possible.

Research & development

To get there, we first had to deep dive into the abysm of technicalities and operational requirements. As hinted previously, there were lots of legacy code involved, which just increased the risk to refactor anything too core. We had to find ways to make it work without causing any type of downtime on the day-to-day operations.

Tap to zoom the image

Iteration Figma screen shot

We iterated a lot as we discovered new things. It's interesting to see how the first UIs on the top of the image there still resemble the ones that ended in production but with some pivotal changes. Designers out there, keep your sketching page intact, it's history!


We started out with a big scope: drivers onboarding, pick-up, and delivery flows. Naturally, with lots of discussions, we trimmed it down and decided to focus the first release just on the delivery UX. The old model, Corp, was too specifically tailored for that use case. Lots of loose wires needed to pass through in order to make it work for new requirements, such as food and e-commerce delivery. We really wanted to take advantage of the opportunity to design a more scalable app, so we were really pushing for the most generic version possible.

There were so many impacted teams that it's hard to list. We had constant check-ins with the operations, CX, and commercial teams to both learn from them about the current state of things and iterate together on how things would change. Least but not last, we used to frequent trips to the distribution centers to talk to drivers and present the changes we were cooking up for them. Lots of back and forth, simplifying the prototypes, focusing on the essentials, trimming down the tech, refining the copywriting, etc.

Results

This whole story took about ~4 months, one of them being entirely focused on a very slow and carefully done rollout. Again, we couldn't for nothing in the world cause a millisecond of downtime. Really sensible stuff.

As we made progress with the rollout, lots of feedback started to pile up. That was absolutely great, especially given how much we had prepared to take advantage of a progressive rollout process, allowing us to incorporate lots of requests before we reached 100%. That's not to say it wasn't challenging, though. Right at that time the pandemic started, so you can imagine how many things we had to juggle at the same time, from understanding how to work and operate remotely (especially with real-world operations such as Loggi's) and what the future would look like.

The app looked entirely different, compared to where we started, and it was super encouraging to see how much we had achieved in a short span of time. Loggi even paid the team a dinner for celebrating the whole thing!

Tap to zoom the image

Flecha UI

The first UI was the driver's cockpit, basically, where s/he could see all deliveries to do. The second one is inside a specific delivery point. And last, the UI where drivers collected the name and doc number of the receiver.


We had a number of processes simplified, which definitely made it easier for everyone. We tackled long standing problems that bugged everyone out but no one had just the time to work on them. Of the things we optimized: how drivers reported problems during delivery (which helped a lot with data analytics), how drivers updated the status of a delivery, removing geofencing and making the product reliable and workable even without connection, and how drivers got help when in emergencies, which was something brand new I'm proud to have contributed for.

Tap to zoom the image

Flecha UI

You'll notice that these UIs don't look very complex, which was exactly the point. And some of them are quite filled with text, which was also the point. We wanted to make it simple but complete. And we also didn't want to get crazy on unnecessary stuff in an operational context like this. So what you see is mostly black text in white background, a few illustrations here and there but mostly that's it.

Tap to zoom the image

Flecha UI


A blog post like this is never enough for cramming months of work. I won't bore you with all the back and forth it took for pulling the first version of Flecha off but I'm glad to share that we managed to do it so nicely that we ended building somewhat of a reputation for how to roll things out smoothly and carefully.

It solidified ourselves, the team, as the owners of the driver's codebase, which was also humbling⎯not so great at times, as it created lots of dependencies⎯given that anyone interested to learn how things were under the hood would come to us, forcing us to also learn how to dodge these bullets in order to focus. Regardless, it was mainly a good thing and I'll be always looking forward to see how the team keeps evolving the product.

Thoughts about this article?

I'm all ears for feedback! Typos? Did something specific get your attention? Anything else? I'd love to hear! Drop me a note somewhere.