Project overview
You are designing Lagos danfo directions commuters can trust: from, to, fare, and steps. Contributor flow when a route is missing is part of the product.
- Platform
- Mobile app · Android-first · portrait
- Screens
- 11 screens + 1 unhappy path (12 frames)
- Features
- 3 core features
- Bottom navigation
- Bottom navigation with 4 items: Routes · Map · Reports · Contribute
- Prototype
- 4 linked flows
Build order: Auth (screens 1–4) → nav tabs (5–8) → core flow (9–11) → unhappy path → link prototypes.
Problem & primary user
Lagos has one of the busiest and most confusing public transport systems in Africa. Danfos (yellow minibuses) and BRT buses have no official schedule, no app, and no route map. Millions of commuters navigate entirely by memory and word of mouth. New residents and visitors are completely lost.
Primary user
"Amara, a 23-year-old NYSC corper newly posted to Lagos who has no idea which danfo goes from Yaba to CMS, how much it costs, or where to stand to board it."
Geographic scope: State-level (Lagos)
Goals
User goal: Find the right bus route, know the fare, and locate the correct bus stop, all before leaving the house.
Business goal: Build the first community-powered public transport database for Lagos and expand to Abuja and Port Harcourt.
Success: In a quick test, someone finds a route, reads fare breakdown, and understands submit a missing route.
Market context
- Question
- Answer
- Who pays
- Amara will not pay. Ads, transport unions, or city mobility data later (assumption).
- Why not WhatsApp
- Commuters ask colleagues at the park. WhatsApp does not store step-by-step danfo legs and fare searchable from Yaba to CMS.
- Design focus
- Design contributor route submit (in brief) and step fare breakdown. Lagos-only honesty in copy.
Competitors to check:
- Ask at bus stop / word of mouth (default)
- NaijaRoute (crowdsourced danfo/BRT/keke routes; web SaaS)
- Google Maps (roads, not danfo legs and fares)
- Cowry Card / BRT guides (formal BRT only)
- Shuttlers (office shuttles, not danfo)
Validate before you design
Interview 3–5 people who match your primary user. Update this brief if interviews contradict it. Do not start hi-fi until you complete the confirmation below.
- Validated user (name, age, city)
- Problem in one sentence
- One interview quote
- Success metric for your test
- Primary colour and tone
- One competitor you checked
Interview prompts
- "Walk me through the last time this happened."
- "What did you use instead? WhatsApp, paper, or nothing?"
- "What would make you trust this on a cheap Android phone?"
- "What would stop you from using this every week?"
Features & scope
v1 · three features
- Search bus routes by start point and destination
- Show estimated fare, number of bus changes, and popular bus stop locations
- Community traffic report: users flag if a route is currently congested
Out of scope
- Ride-hailing or BRT ticketing
- Abuja / PH in v1 unless you state it in case study
- Real-time GPS bus tracking
Screens
Design every row in wireframe, high-fidelity UI, and prototype (where the flow applies).
| # | Layer | Screen | What to show |
|---|---|---|---|
| 1 | Auth | Splash Screen | Bold yellow and black, Lagos energy. App name clearly visible. |
| 2 | Auth | Onboarding (2 screens) | Screen 1: 'Lagos routes, figured out for you.' Screen 2: 'Routes are contributed by commuters like you. Help us grow.' Enter your area to get started. |
| 3 | Auth | Sign Up Screen | Name, phone number, home area in Lagos, and PIN. |
| 4 | Auth | Sign In Screen | Phone number and PIN. |
| 5 | App shell | Routes (tab) | Two fields: From and To. A large 'Find Route' button. Show 3 popular routes in your area below. |
| 6 | App shell | Map (tab) | List of route options. Each card shows: buses to take (e.g. Yaba → Ojuelegba → CMS], number of stops, estimated fare, and journey time. |
| 7 | App shell | Reports (tab) | Step-by-step directions: which bus to board, where to board it, where to drop, and the fare for each leg. Show a simple map if possible. |
| 8 | App shell | Contribute (tab) | Three buttons: Traffic is Bad · Traffic is Normal · Route is Blocked. After reporting, show 'Thanks. We've updated this route for your neighbours.' |
| 9 | Core flow | Route results | From/to routes with fare and stops. Show bottom nav on post-sign-in screens. |
| 10 | Core flow | Route detail | Step-by-step boarding instructions. Show bottom nav on post-sign-in screens. |
| 11 | Core flow | Traffic reported | Thanks for updating route status. Show bottom nav on post-sign-in screens. |
Layers: Auth = 1–4 · App shell = 5–8 · Core flow = 9–11
Prototype flows
Link these in Figma. Examiners should click through without your voice-over.
Flow 1 · App entry
Flow 2 · Core task (all three features)
Core flow screens: Route results · Route detail · Traffic reported
Flow 3 · Navigation
Link every nav tab so examiners can tap each bottom nav item. Tabs: Bottom navigation with 4 items: Routes · Map · Reports · Contribute
Flow 4 · Unhappy path
Trigger the unhappy path edge case and link to that screen.
Unhappy path
Design this as its own screen state (frame 12):
Route not found in the database. Show: 'We don't have this route yet. Help us add it!' Show a simple form to submit the route and reward the user with a 'Contributor' badge.
Link in Flow 4.
Design system
- Colour
- You choose. Keep it simple and readable.
- Type
- You choose. Keep body text easy to read on a phone.
- Tone
- Design for your user, not for a tech audience.
Reuse on every screen:
- Primary button (active and disabled states)
- Input field (empty, filled, and error states)
- Card or list item used across the app
- Navigation bar with correct labels and icons
- Empty state: what the screen looks like with no data
Submit & defense
Deliverables
| # | Deliverable | What good looks like |
|---|---|---|
| 1 | Wireframes | Every screen in this brief, plus the unhappy path. Layout and labels clear. |
| 2 | High-fidelity UI | Same frames polished. You choose colour and type. Bottom nav on every post-sign-in screen. |
| 3 | Prototype | Four linked flows (entry, core task, navigation, unhappy path). Examiners can use the app without your voice-over. |
| 4 | AI prototype | Figma Make: at least 2 screens. Share link. |
| 5 | Case study (1 page) | Problem · User · Who pays · Competitors · Solution · One design decision |
| 6 | Presentation (6–8 slides) | Name · Problem · User · Solution · Key screens · Flow demo · One decision |
Before you present
- Every screen designed in wireframe and hi-fi
- Unhappy path screen designed and linked in the prototype
- Four prototype flows linked end to end
- At least one empty state on a list tab
- Shared components reused: button, input, card or row, bottom nav
- Case study names who pays and one competitor you checked
- You can explain one design decision in critique (why, not what)
- Completed 5 user interviews or 1 usability test
- Checked at least one competitor listed under Market context