The screens
- 111screens in 5 flows
- 59design tokens
Six of the 111 screens from the 2026 rebuild, from the intro to the trip in progress, all built on the 59 design tokens. The Figma file holds every screen. How I got here starts with the 2024 research.
1. Intro: the idea in one picture. 
2. Home: one main action, Where to. 
3. Choose a ride: no prices yet. 
4. Price and offer. 
5. Choose a driver. 
6. Trip ongoing: safety tools.
Screens are rendered from my HTML review pages. The Figma file is the master.
Part 1 · 2024
The research that shaped the app
This is the original Route, from my internship at People Ntech. The research here is real, and it is where the ideas for Part 2 came from.
How we did the research
With my team, I interviewed about 10 to 20 young adults, roughly aged 18 to 27, about the ride-sharing and food-delivery apps they use. They were people in my network: teammates, my mentor, other staff and campus peers. They were not strangers and not a recruited panel. We chose people born roughly 1995 to 2010 because, by our own reasoning rather than data, children and older people were not the main users of these apps in Bangladesh.
The team and I prepared the questions together: overall experience, which existing app they like most and why, what to improve, and which features they dislike and why. I asked them out loud, listened, and wrote up a draft. We combined the notes and built the persona as a team. I did not keep the interview notes.
What they told us
- Women in particular wanted to share their live location with a husband, father or trusted contact during a ride, and confirm they arrived safely.
- People wanted one app for bikes, cars and CNG. At the time, CNG needed a separate app.
- Interviewees said one popular app had no fare negotiation for bikes, only for cars.
The second and third points are what interviewees told us. I have not checked them against every other app (see Part 2 for what I did check).
The persona
Persona: coming soon. The persona from the 2024 team research will be added here.
What I decided in 2024
- One app for every vehicle type. Route covers bikes, cars and CNG.
- Fare negotiation on all of them. A rider can ask for a fair price or offer their own, and the driver can counter.
- An in-ride safety screen. SOS, "share ride details", "share live location with trusted contacts", the ongoing ride information and a live map.
After the internship I kept working on the file alone. In 2026 I decided to rebuild it properly, as a practice project.
Part 2 · 2026
The rebuild: from a client brief to a developer handover
I wanted to practise a full professional process, and to learn how fast I could work with AI as part of it. So I wrote a brief as if a client had sent it, and a friend played the client. There was no company, no fee and no real launch. The design decisions were mine.
At a glance
- 111screens in 5 flows
- 59design tokens
- 32icons
- 3written specs
- 9design reviews
The package is a Figma master file with a clickable prototype of the main paths, five HTML review pages that show the same screens built from the tokens, the specs, the tokens and the icons. The practice brief set ten days to a first draft and two rounds of revisions.
Reading the brief
The brief asked for a minimal, streamlined app that is "not a feature-heavy dashboard". It also listed 16 required screens, plus safety tools, promos, history, notifications and help. Those two asks pull in opposite directions.
I took the minimal side. The core ride (home, set-up, offer, results, pickup, trip, rating) stays light, with as few actions as possible. The supporting screens are all built, but kept as plain lists and forms. I wrote down what the other side loses: richer history, a detailed settings area, and any feature that adds a step to the ride. Safety is the one exception, because on the trip screen it matters more than minimal.
The brief also left three questions open, so I answered them in writing before drawing anything: is "accept the estimate" or "make an offer" the default path, in what order the rider sees vehicle, price and negotiation, and who pays for a promo. My answer to the first: the journey is effortless, and negotiation is Route's one specialty. Making an offer is always available, but accepting the estimate is the easy path.
Where I deviated from the brief, on purpose. No nearby vehicles on the map (an availability line instead). No fares before a vehicle type is chosen. No promo code entry (an auto-apply list instead). I recorded each as a deviation in the notes so a developer or client would not find them by surprise.
Research in the rebuild
The rebuild did not repeat the interviews. I used the 2024 findings and checked the competitors myself, by using their apps in Bangladesh. In Pathao, riders can bid on cars, premium cars and max cars, but not on bikes. In Uber, I found no negotiation on any vehicle. Route negotiates on every vehicle type, including bikes and CNG, and that is the difference I designed around.
This is first-hand and not independently verified. I have not checked inDrive.
Decisions, with the reasons
Negotiation has hard rules, so it stays fast
An offer can be as low as 70% of the estimate and as high as 300%. The limits only appear when the rider goes out of range, so the screen stays quiet otherwise. The rider gets three offers in total, counted from the first reply from a driver, and raising the offer before then is free. A driver's counter-offer binds for two minutes. I show that as a note, not a countdown, because a ticking clock would pressure the rider.
The negotiation rules came from the practice client, my friend. The full detail is in the search and booking spec.
An availability line instead of cars on the map
The price section opens with "15+ bikes available in your area", in steps of five. I put it first because few drivers means the rider should offer more, so it changes what they do. It also keeps the map calm.
Fares are not shown before the rider picks a vehicle type. The cost is extra taps to compare types. I guessed that riders might miss a side-by-side comparison, and I have not tested it.
One Choose button per driver row
My second design review measured the results list. Each driver row was 114 px tall, because Details and Choose were stacked as two buttons, so only two drivers were visible and comparing five took two screens of scrolling. Comparison is the whole point of this screen. I kept a single Choose button and made the row itself open the details. Rows dropped to about 66 to 72 px, so four or five drivers show at once.
Rejected: 12 px text, dropping the photo and ride count, putting details only in a modal, and a taller sheet.
The sheet is one component with a maximum height
My first design review found the vehicle sheet 589 px tall. It covered the map, clipped the destination pin and pushed Continue off a 640 px screen. The cause was the same on every sheet: no maximum height. I fixed it once as a component (a height cap, an inner scroll, the main button pinned), not screen by screen.
Rejected: shrinking text to 14 px, cutting the list to three vehicle rows, hiding the tab bar, and making the map smaller.
Safety is one tap, and the money rule is stated before the rider confirms
Emergency call is the only red button on the trip screen. One tap opens the phone dialer with 999 typed, with no confirmation box. Audio recording is saved only on the rider's own phone, so it is theirs to show the authorities, and Route keeps no copy. Trusted contacts are chosen only from the phone's contacts.
Ending a trip early shows the exact charge first. With half or more of the distance done, the rider pays the full fare. Under half, they pay for the distance plus 25% of the agreed fare.
One screen to sign up or log in
The app decides by the phone number: a known number logs in, a new one signs up. A new social account must add a phone number. Phone sign-up uses an SMS code with no password. After five wrong codes the rider is locked out for 30 minutes, then 60 for each further five.
Information architecture
In 2026, before I drew a screen, I mapped the rider's journey: 18 steps for the ride itself and 6 supporting ones. Every screen in the Figma file names the step it serves. The order of the steps and the navigation choices below are my decisions.
Get in
- Learn what is different
- Prove who they are
- Allow exact location
- Allow notifications
Set up the ride
- See where they are
- Say where to
- Confirm the destination
- Choose the pickup point
- Choose a vehicle type
Make the offer
- Decide the offer
- Wait for answers
- Weigh the answers
- Confirm the booking
The ride
- Wait for the driver
- Meet the driver
- Ride
Finish
- Arrive and pay
- Rate
Supporting journeys: past trips, account, promos, notifications, help, delete account.
How the app is organised
- A fixed bottom tab bar: Home, Activity, Menu. The search runs in the background, so a rider can leave for Activity or Menu at any moment and come back to the same state. A hamburger menu or a sidebar would hide that, so I ruled both out.
- The ride is one screen that changes state. Home is a sheet over the map. Searching, choosing a driver and the trip itself are states of that sheet, not a chain of pages.
- Confirmations are modals, map pickers are full screens. Booking, cancelling and ending early need an explicit choice, so they are small modals. Choosing a place needs the whole map, so it opens a full screen with a back button.
- Three levels of content per screen, at most. The primary item is what moves the rider to the next step. On the price screen the availability line comes first, because it tells the rider how much to offer.
Constraints I set: the tab bar can never be hidden, every drag has a visible button as well, and the sheet keeps its main action visible on a 320 by 640 screen.
Make the offer, step by step
Steps 10 to 13 are where Route differs from other ride apps, so I mapped them in detail. Raising the offer is free until the first driver replies. From the first reply, the rider has three offers in all.
Two ways in, one verified phone number
The handover package
A developer opening this package has:
- The Figma master: 111 screens in five flows (home and set-up 15, search and booking 16, pickup and trip 26, activity and menu 34, entry and permissions 20), and a clickable prototype of the main paths.
- Five HTML review pages, one per flow, built from the tokens, so real sizes and colours can be read. They are a reference, not the app.
- Three specs: what each screen does and its states, the offer rules and timers, and the Android and iOS differences.
- A design system: 59 tokens and 32 icons.
- A list of decisions already made, so nobody asks again, and a list of what is not decided.
The handover note also says who owns what is left: the map provider and notification sounds belong to the developers, and so do the web pages the app links to.
Honest limits
- No real users. The client was simulated and nothing was tested on a real phone or with a screen reader. Every usability point in my reviews is a risk, not a measurement.
- Contrast. White text on the brand green (#32BB78) is about 2.5 to 1, below the 4.5 to 1 guideline. I accepted it to keep the brand colour, and it could be hard to read in sunlight. Filled buttons are 43 px high, one under the 44 px guideline.
- Dense price screen. My last review judged the price and offer step to be too much for a first-time rider, and the best single fix is to trim it. I have not made that change.
- Not tested at every size. Only Flow 5 has a 320 px version in Figma. Small differences of 3 to 5 px remain between Figma and the HTML on a few screens.
- Revisions not started, and the Pathao and Uber findings are first-hand only.
How I used AI
I wanted to learn how much faster I could work if AI handled the writing-up and the building, while I made the decisions. This is how the work split.
What I did
- Wrote the practice brief and answered its open questions
- Made every design decision, and decided what to keep or reject from the reviews
- Edited the Figma frames by hand: layouts, sizes, wording, the sign-up screen
- Corrected the AI when it was wrong
What the AI did
- Wrote up my answers as the interrogated brief and the three specs
- Produced first drafts of the frames and built the HTML review pages
- Ran the design and usability reviews, and measured them in the browser
- Kept the build log
The log records the AI's mistakes, and I corrected them. It invented a "driver no-show" state that I removed. It built one group from outdated wireframes. It added circles to the back buttons after I had removed them on purpose. Checking and correcting this work was a large part of the job.