Project overview
You are designing trust for hiring one artisan in one city. Verified badge, booking, and scam warnings beat a national marketplace with every trade.
- 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: Find · Bookings · Favourites · Profile
- 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
Finding a reliable plumber, electrician, carpenter, or tiler in Nigerian cities is unreliable and stressful. You ask neighbours, call numbers scrawled on walls, get stood up, or get overcharged by unverified strangers. Skilled artisans also struggle to find steady work beyond their small personal network.
Primary user
"Mr. Okafor, a 47-year-old property manager in Lekki who needs a trustworthy plumber urgently when pipes burst and has been scammed twice by artisans who collected payment and disappeared."
Geographic scope: State-level (Ogun (Abeokuta, Ota, Ilaro))
Goals
User goal: Find a verified, rated artisan in his area and book them within 30 minutes.
Business goal: Build a marketplace where artisans pay a monthly subscription to be listed and verified, earning income from placement and job commissions.
Success: In a quick test, someone searches, opens a profile, and completes booking including the unverified warning state.
Market context
- Question
- Answer
- Who pays
- Mr. Okafor pays per job (commission). Artisans may pay listing fee only if jobs are real (assumption).
- Why not WhatsApp
- People already ask “who knows a plumber?” on estate WhatsApp. Pain is verified identity, booking record, and showing up.
- Design focus
- Design verified badge, booking confirmation, and scam warning for unverified (in brief). Trust UI beats feature count.
Competitors to check:
- Word of mouth, estate WhatsApp (default)
- Usefixr (Fixr) (contractor-led maintenance; plumbing, electrical; Lagos-focused)
- Instagram / Facebook artisans (unverified listings)
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 artisans by trade type and neighbourhood
- View artisan profiles with ratings, reviews, and photos of past work
- Book an artisan directly through the app and confirm the job
Out of scope
- Payments inside the app in v1
- Every trade nationwide
- Background checks you cannot show in UI (label as assumption)
Screens
Design every row in wireframe, high-fidelity UI, and prototype (where the flow applies).
| # | Layer | Screen | What to show |
|---|---|---|---|
| 1 | Auth | Splash Screen | App name and a clean illustration of tools or a skilled worker. |
| 2 | Auth | Onboarding (1 screen) | Two large buttons: 'I Need an Artisan' and 'I Am an Artisan'. This sets up the right experience from the start. |
| 3 | Auth | Sign Up Screen | Name, phone number, state, and LGA. Ask: 'Are you a customer or an artisan?' PIN for login. |
| 4 | Auth | Sign In Screen | Phone number and PIN. |
| 5 | App shell | Find (tab) | Search bar at the top. Category icons below: Plumber, Electrician, Painter, Carpenter, Welder, Tiler, Cleaner. Recent artisans if returning user. |
| 6 | App shell | Bookings (tab) | Search results showing artisan cards: photo, name, trade, star rating, number of reviews, and distance from user. |
| 7 | App shell | Favourites (tab) | Full profile: photo, name, trade, verified badge (if applicable], rating, reviews, years of experience, photos of past work, and a 'Book Now' button. |
| 8 | App shell | Profile (tab) | Date and time picker, brief description of the job, and address. 'Confirm Booking' button. Show artisan name and photo as confirmation. |
| 9 | Core flow | Artisan list | Search results with rating and distance. Show bottom nav on post-sign-in screens. |
| 10 | Core flow | Artisan profile | Reviews, photos, Book now button. Show bottom nav on post-sign-in screens. |
| 11 | Core flow | Booking confirmed | Date, job note, artisan name confirmed. 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: Artisan list · Artisan profile · Booking confirmed
Flow 3 · Navigation
Link every nav tab so examiners can tap each bottom nav item. Tabs: Bottom navigation with 4 items: Find · Bookings · Favourites · Profile
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):
No verified artisans found in the user's area. Show unverified options with a visible warning badge: 'Not yet verified. Proceed with caution and always confirm identity in person.'
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