Project overview
You are designing a symptom checklist that ends in a clear next step. You are not replacing a doctor. Strong disclaimers and Low / Medium / High results matter more than adding more symptoms.
- Platform
- Mobile app · Android-first · portrait
- Screens
- 10 screens + 1 unhappy path (11 frames)
- Features
- 3 core features
- Bottom navigation
- Bottom navigation with 3 items: Check · History · Profile
- Prototype
- 4 linked flows
Build order: Auth (screens 1–4) → nav tabs (5–7) → core flow (8–10) → unhappy path → link prototypes.
Problem & primary user
Millions of Nigerians self-medicate for malaria without confirming their symptoms actually match. People take anti-malarials for typhoid, buy the wrong drug, or delay real treatment. There is no simple, accessible tool that helps someone check their symptoms before heading to a pharmacy.
Primary user
"Emeka, a 28-year-old teacher in Enugu who gets fever regularly, never knows if it is malaria or something else, and self-medicates without any guidance."
Geographic scope: National-level
Goals
User goal: Quickly check if his symptoms match malaria and understand what to do next.
Business goal: Reduce dangerous self-medication and connect users to verified clinics or telemedicine services.
Success: In a quick test, someone finishes a check, understands their risk level, and knows whether to stay home or go to a clinic.
Market context
- Question
- Answer
- Who pays
- Emeka will not pay for symptom checks. Payers are more likely pharmacies, HMOs, or public health programs funding triage tools (assumption).
- Why not WhatsApp
- People already Google symptoms or ask in family WhatsApp groups. That gives scary, conflicting answers. A structured checklist with a clear next step is safer than chat.
- Design focus
- You are designing education and triage, not diagnosis. Strong disclaimers, Low/Medium/High with plain English, and “go to clinic” beats feature depth.
Competitors to check:
- Chemist advice + self-medication (default)
- Medi-chat, MedCare NG (AI symptom check + care routing in Nigeria)
- Febra Diagnostica (febrile illness tool; more for health workers than consumers)
- Google / random health blogs (not guided, not Nigeria-first)
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
- Symptom checker: user selects symptoms from a simple list (fever, chills, headache, vomiting, body pain)
- Risk result: Low, Medium, or High risk with a plain-English explanation
- Next step: clear advice: rest at home, visit a clinic, or go to a hospital now
Out of scope
- Diagnosis or prescriptions
- Lab booking or telemedicine chat
- Insurance or pharmacy checkout
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 logo, name, and tagline on a clean background. |
| 2 | Auth | Onboarding (1 screen) | Explain what the app does and that it is not a replacement for a doctor. Include a 'Start Check' button. |
| 3 | Auth | Sign Up Screen | Name, age, and phone number. No password needed. Use a 4-digit PIN. |
| 4 | Auth | Sign In Screen | Phone number and PIN to return to previous checks. |
| 5 | App shell | Check (tab) | Start Check button and last check date. Show bottom nav with Check active. |
| 6 | App shell | History (tab) | List of past symptom checks with date and risk level. Empty state if none. |
| 7 | App shell | Profile (tab) | Name, age, phone, and disclaimer link. Show bottom nav with Profile active. |
| 8 | Core flow | Symptom checker | Symptom cards selected. Check Now enabled. Show bottom nav on post-sign-in screens. |
| 9 | Core flow | Risk result | Low / Medium / High with plain explanation. Feature 2. Show bottom nav on post-sign-in screens. |
| 10 | Core flow | Next steps | Advice and nearest clinic CTA. Feature 3 guidance. Show bottom nav on post-sign-in screens. |
Layers: Auth = 1–4 · App shell = 5–7 · Core flow = 8–10
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: Symptom checker · Risk result · Next steps
Flow 3 · Navigation
Link every nav tab so examiners can tap each bottom nav item. Tabs: Bottom navigation with 3 items: Check · History · 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 11):
User selects no symptoms and taps 'Check Now'. Show a message: 'Please select at least one symptom to continue.'
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