Live on the App Store. Used on real commutes.
Turning empty seats into a daily ritual.
Togopool is a two-sided mobility marketplace. One person holds an empty seat. Another holds a commute they’re tired of. My job was to close that gap — route by route, signal by signal — until trusting a stranger feels like the obvious choice, and booking the same ride tomorrow takes one tap.
Find a Pool
Express a commute, compare options, understand fit, and choose a ride.
Offer a Pool
Publish a trip with vehicle, seats, route and preferences others can evaluate.
Make trust legible
Surface the right signals at the decision point, instead of making users investigate.
Carpooling isn’t only a matching problem.
It asks people to coordinate a real journey with someone they may not know, under time and budget pressure.
How might we help commuters choose and coordinate a shared ride with enough clarity about route, people, timing and money to feel confident — and make repeating it easier?
Three people, three jobs to be done.
Ride taker
Evaluate options, trust the details, and understand the commitment before requesting a seat.
Ride giver
Publish a trip efficiently while keeping control of route, seats, timing and preferences.
Returning commuter
Make routine trips easier to manage, with clear control when plans change.
From observations to design questions.
| Theme | Question | Design implication |
|---|---|---|
| Route fit | Is this trip convenient for me? | Compare pickup, drop-off, route and timing before committing. |
| Trust at decision time | Who am I travelling with? | Show verification, profile and preferences in context. |
| Money clarity | What will I pay or earn? | Separate fare, earnings and promo balance; explain conditions near the action. |
| Repeat-use effort | Can I reuse my commute? | Recurring rides with understandable edits and cancellations. |
| Recovery | What if plans change? | Clear status and a visible next step. |
Principle: help people predict what happens next — without making the interface feel like a security checkpoint.
Design the whole commute.
Discover
Can this fit my commute?
Unclear service or eligibility.
→ Set expectations, one obvious first action.
Search / offer
Did I describe it right?
Form work; fragile route inputs.
→ Focused task, visible progress, easy correction.
Evaluate
Which option fits me?
Route, profile and price hard to compare.
→ Make trade-offs visible in results.
Commit
What happens next?
Ambiguous status.
→ Confirm state, commitment and next step.
Ride
Where and when do we meet?
Pickup changes, delays, deviations.
→ Timely status with recovery paths.
Repeat
Was it settled? Again?
Money confusion, repeated setup.
→ Clear settlement, user-controlled recurrence.
Two jobs.
One coherent system.
Six decisions. Each one earned its place.
Every change follows one chain: evidence → decision → trade-off → measure. Rationale is drawn from the original project notes and the shipped screens; measured results get added only when sourced.
Fix search before polishing anything else.
A beautiful flow is worthless if the destination can’t be found.
- Evidence
- Users searched by address, postal code and landmarks. The original API returned results too weak to finish the task.
- Decision
- Swap the search API late in the build, move search onto its own focused screen, and index recents and favourites.
- Trade-off
- One extra screen in exchange for results people can trust — offset by Home / Office / Other shortcuts.
- Measure
- Search-to-valid-match rate; zero-result rate.
- Linked route. Origin and destination stay visible as one object.
- Shortcuts. Home, Office, Other remove typing for habitual trips.
- Disambiguation. Name plus full address under every result.
Make the daily commute a one-time setup.
Riders who repeat a route shouldn’t rebook it every morning.
- Evidence
- A large share of users travelled the same routes daily — to work or college — and booking each day felt repetitive.
- Decision
- Add a Recurring toggle inside the existing sheet, then a per-day schedule with editable times.
- Trade-off
- More surface area for a minority flow — so the toggle is off by default and the core path stays untouched.
- Measure
- Repeat-commute rate; recurring-ride retention.
- Progressive disclosure. Weekday chips appear only when Recurring is on.
- Per-day time. Each day carries its own time and an edit affordance.
- One primary action. “Add Recurring Ride” closes the loop.
Let ride givers stay in control.
A seat count is meaningless until you know which vehicle it belongs to.
- Evidence
- Ride givers choose between a car and a bike, and capacity depends on the vehicle.
- Decision
- Choose the vehicle first; the seat selector expands in place on that card instead of living on a separate screen.
- Trade-off
- In-place expansion keeps context but lengthens the sheet — the selected card is tinted to hold focus.
- Measure
- Offer-completion rate; seat-count corrections.
- Two vehicles, equal weight. Car and bike are first-class.
- Contextual seats. Appear only for the chosen vehicle.
- Add vehicle. Always reachable, never in the way.
Show the route before the commitment.
Riders commit to a path, not just a pin.
- Evidence
- Riders need to see the route before booking to avoid detours and unexpected stops.
- Decision
- Surface the route on a map with pinned start and end, so fit is judged visually in seconds.
- Trade-off
- A map costs load and attention — so it carries one highlighted route, not a comparison table.
- Measure
- Match view → request conversion; time to decision.
- Pinned journey. Start and end sit in a floating card.
- Route as colour. Orange line vs grey alternative.
- Bottom sheet. Room for price and profile next.
Earn trust before asking for it.
Signals inform a choice. They never promise safety.
- Evidence
- Corporate verification and route-match score appear in the public product; trust has to be legible at the decision point.
- Decision
- Lead with value, reduce sign-in to one step, and show verification and match quality next to price.
- Trade-off
- More information on screen — held in check with a single clear status per signal.
- Measure
- Match → request rate; accurate reading of trust signals in testing.
- Value first. Cost and eco benefits open the story.
- Verification. Corporate email and documents, stated plainly.
- Match score. Fit, price and vehicle in one glance.
Teach at the moment of use.
Two sides of a marketplace need two kinds of guidance.
- Evidence
- Find and Offer are different jobs sharing one home screen, so users can mistake which side they’re on.
- Decision
- Use contextual coach marks per side, and keep privacy and profile controls one tap away.
- Trade-off
- Coach marks add a first-run step — skippable, and shown once.
- Measure
- First-search completion; privacy-setting discoverability.
- Role switch. Find / Offer lives at the top.
- Skippable guidance. Explains the action on the screen.
- Control. Phone visibility and vacation mode.
Test the decision, not just the screen.
| Task | Observe | Success signal |
|---|---|---|
| Find a suitable ride | Can the user compare options and explain the choice? | Right selection with clear rationale. |
| Offer a ride | Vehicle, seats, route and preferences configured? | Offer created with nothing critical missing. |
| Read trust signals | What does the user infer from verification? | Understood accurately, not as a guarantee. |
| Recover from a change | Do they understand a changed pickup? | Next action clear and controllable. |
Separate product progress from design impact.
No impact numbers are claimed here. Add outcomes only with source, timeframe and your contribution.
What this work demonstrates.
Systems thinking
Both sides of the marketplace, and the full commute — not one isolated screen.
Decision quality
Each UI choice tied to evidence, constraints, trade-offs and a measurable question.
Honest impact
Designed, shipped, measured and still-open — kept separate.