Case 01 · Moving marketplace · 2 apps · 2025
Muvr is a US marketplace for moves, deliveries and junk removal. Every job has two ends: the person who needs to move, and the driver who does the moving. Each end has its own app. Both had their flows, but they didn't work, so I recreated every one of them from scratch, as the only designer on the project.
One move, two apps
Overview
A move looks like one event, but it's two very different experiences. For the person moving, it's a stressful day they want off their plate. For the driver, it's work: getting approved, taking the job, getting paid. So Muvr runs two apps, and each one had to be designed for its own person.
My role
I was the only designer on the project, freelance, and I owned the work end to end. The old flows existed, but they didn't work, so none of them was carried over as it was: I audited the app, mapped every journey again, recreated each flow and its interface, built the components and documented everything for handoff.
Muvr's CEO is also a specialist in moving and logistics, so he took part in the reviews as the expert on the trade: truck sizes, how many movers a job needs, what really slows a move down. I brought the proposals, and he tested them against how moves happen in real life.
Process
With eight kinds of move and ten driver requirements, starting from screens would have meant drawing everything many times over. So every journey started on a FigJam board: each step, what it asks and what the system does with the answer. The boards were where decisions got made, before any pixel.
The old flows, where each one broke, and the complaints users sent in.
Every journey on FigJam, step by step, for each move type.
Find what repeats across the journeys, and what has to change.
Screens, components and every state, one app at a time.
Walk the flows with the CEO, who knew the trade inside out.
Redrawn from my FigJam files.
Rules of the service
Nine steps, eight moves
| 01Pickup | 02Items | 03Drop-off | 04Level | 05Truck | 06Schedule | 07Review | 08Tracking | 09Proof | |
|---|---|---|---|---|---|---|---|---|---|
| Home move | |||||||||
| Apartment | |||||||||
| Dorm room | |||||||||
| Office | |||||||||
| Store | |||||||||
| Warehouse | |||||||||
| Storage unit | |||||||||
| Labor only |
Same steps, different questions.
Context
Revamp home and orders for usability. Keep accepting and finishing a job effortless. Learn from Uber and Lyft.
Features to keep, flows redrawn
Open questions
Photos at loading: every item in a move, or only the listed ones?
Pick a navigation app once, or every time?
On the way to pickup, include the route to the helper?
User app · for the person moving
The old booking asked for everything at once, and still missed what drives the price: a flight of stairs, a missing elevator, a gate code, a piano. I rebuilt it so people describe the move in their own terms, one small question at a time, and only when it applies to them.
Steps 1 to 3 designed for every move type.
Tell us about the move
Choose how
On the day
Labor only skips the drive: one job location, the type of work, then straight to service level. Seven steps instead of nine.
The question
Where should booking start? People open a move type to find out what it includes, not to fill in a form.
The decision
Right there. The first question sits above the service levels, so reading about a move is already step one.
The question
Eight kinds of move, eight different flows? That's eight times the screens, and eight ways to get lost.
The decision
One flow whose fields adapt: hall and room for a dorm, unit for an apartment, floor for an office, loading dock for a warehouse.
The question
What really changes the price? Access: stairs, elevators and opening hours, the things people forget to mention.
The decision
Ask about access up front, each question behind a switch that only opens when it applies.
The question
How big a truck, and how many movers? Few customers can tell, and a wrong guess means a second trip.
The decision
Let the system suggest both from the size of the place, with a floor: four movers above 1,500 sq ft. People can size up, never down.
Home and search
Move types
Booking · steps 1 and 3
Booking · step 2
Driver app · for the service provider
Before the first job, a driver has a lot to prove: identity, licence, vehicle, insurance, a background check, even how they lift and wrap furniture. The old app threw it all at once. I turned it into a guided path, with one clear next step and an answer for every submission.
The question
How should drivers sign in? They're often on the move, and passwords get forgotten.
The decision
With the phone. One number and a six-digit code, and if the number already has an account, the app asks “Is this you?” before creating another.
The question
Up to ten requirements before the first job. Where do you start?
The decision
A dashboard that always recommends one next step, and folds away what's done. Couriers get a shorter list.
The question
What happens after you submit a document, and how do you know?
The decision
Every review has a visible state: in review, accepted or declined. A decline always comes with a report and a retake.
Sign-in and sign-up
Roles
Onboarding dashboard
Requirements
A vehicle is a short form, safety gear is a checklist and skills are switches. Each requirement asks in the way that fits what it proves, with the same header, progress and buttons around it.
After you submit
The same moments repeat across the eight requirements that need a review, so drivers learn the pattern once. Waiting has a shape, good news gets a small celebration and a decline is never a dead end.
Help centre
From the Home & Orders board.
The last piece I mapped was the driver's home: accepting and completing jobs. Ride-hailing apps have already taught drivers how that should feel, so the order card borrows their rhythm and changes as the job gets closer.
Design system
Both apps are built from the same small set of parts, each one drawn with all of its states. A switch in the booking flow behaves like a switch in onboarding, and developers never have to guess what happens next.
Navigation
Where you are, and how to get back.
Inputs
Asking only what's needed, and showing it back.
Selection
Choices you can see all at once.
Feedback
Every action gets an answer.
Actions
One main action per screen.
Cards
Content people scan, compare and open.
The characters started as plain black line drawings. I adapted them to the brand: purple strokes, a soft lilac fill and a pale backdrop, and gave each one a job: reviewing, waiting, something's wrong, done.
Purple is Muvr's colour, and the revamp kept it, but gave it a job. The bright purple marks what moves you forward: the main button, a switch that's on, progress. A deeper purple marks what you've chosen.
Everything else steps back: white cards with soft corners, dark text and grey for hints, so the purple always means something.
One thing I'd change
The light grey used for hints and longer explanations reaches only 2.40:1 on white. Fine for a placeholder, not for text people must read, like why a document was declined. A darker grey, #6E6E76, keeps the same quiet tone and reaches 5.05:1.
And one more
Before paying for the background check, the app shows the driver's full Social Security number to confirm it. The last four digits are enough to confirm, and nobody looking over a shoulder gets the whole number.
Outcome
The feedback on the work was good. When I handed over, both apps had their core flows designed, with components and states, and the booking journey was mapped end to end for every move type.
The next phase called for a different kind of engagement, a full-time, day-to-day role inside the team. For that particular setup, the terms and the scope didn't match, so we agreed to close my part at that milestone, on good terms, with everything documented for the team to build on.
What I'd measure next
If I picked it up again
The booking would go in front of real customers, and onboarding in front of real drivers, before anything new gets drawn.
Muvr's name and brand belong to Muvr. Photos in the screens were swapped for neutral avatars in this case study.
Working on something similar? Tell me about the product, the feature or the messy flow.