Project overview
You are designing child activities + parent dashboard for one learning need. Large touch targets and gentle copy when an activity is hard are required.
- Platform
- Mobile app · Android-first · portrait
- Screens
- 11 screens + 1 unhappy path (12 frames)
- Features
- 3 core features
- Bottom navigation
- Bottom navigation (Parent View): Dashboard · Activities · Tips · Settings
- 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
Children with dyslexia, autism, or hearing impairments in Nigeria are routinely labelled as 'slow' and left behind in overcrowded classrooms. Special needs education barely exists in public schools. Parents have no accessible resources to support their children's learning at home.
Primary user
"Mrs. Bello, a 39-year-old mother in Kano whose 9-year-old son has been diagnosed with dyslexia, struggles to read standard textbooks, and whose teachers have given up on him."
Geographic scope: National-level
Goals
User goal: Find learning activities designed for her son's specific learning needs that he can do on a tablet with minimal help.
Business goal: Become the leading special needs education platform in Nigeria and West Africa.
Success: In a quick test, a parent switches child vs parent view, starts one activity, and sees progress without shame messaging.
Market context
- Question
- Answer
- Who pays
- Mrs. Bello may pay if cheaper than centre. Schools, NGOs, or therapy centres B2B (assumption).
- Why not WhatsApp
- Parents get random PDFs from teachers. WhatsApp cannot run dyslexia-sized touch targets + parent dashboard in one product.
- Design focus
- Child mode vs parent mode, no “you failed” copy (in brief). One learning need per profile.
Competitors to check:
- Vinsighte (Visis app) (dyslexia-friendly reading; Nigeria)
- ALIA (inclusive learning; dyslexia mode)
- Mavis Talking Books / C-Pen (hardware + books; schools)
- Private therapy centres (expensive, far)
- Generic kids learning apps (not dyslexia-specific activities)
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
- Learning activities designed for different needs: dyslexia-friendly reading, autism-friendly tasks, hearing-impaired visual learning
- Large fonts, audio playback, and icon-based navigation throughout the app
- Parent dashboard to track activity completion and see how the child is progressing
Out of scope
- Clinical diagnosis in the app
- Video therapy sessions
- All special needs in one profile
Screens
Design every row in wireframe, high-fidelity UI, and prototype (where the flow applies).
| # | Layer | Screen | What to show |
|---|---|---|---|
| 1 | Auth | Splash Screen | Colourful, friendly, and welcoming. Use large rounded shapes. No clinical feel. |
| 2 | Auth | Onboarding (2 screens) | Screen 1: 'Every child learns differently. We build for that.' Screen 2: Set up a child profile: name, age, and learning need (Dyslexia / Autism / Hearing Impairment / Other). |
| 3 | Auth | Sign Up Screen | Parent name, phone number, and PIN. Child name and profile set during onboarding. |
| 4 | Auth | Sign In Screen | Phone number and PIN. Option to switch between Parent View and Child View. |
| 5 | App shell | Dashboard (tab) | Large colourful activity cards. Simple icons, minimal text. Child can tap an activity to start. Make this screen fun and inviting. |
| 6 | App shell | Activities (tab) | Full-screen activity, e.g. a word-matching game for dyslexia. Large text, audio support, and simple tap interactions. Progress shown as a friendly character moving forward. |
| 7 | App shell | Tips (tab) | List of activities completed this week, time spent, and a simple performance note (e.g. 'Improving with letter recognition'). No clinical grades. |
| 8 | App shell | Settings (tab) | 3 to 4 short tips per week on how to support the child at home. Practical and simple. Written for parents with no specialist background. |
| 9 | Core flow | Activity · In progress | Child-friendly full-screen activity. Show bottom nav on post-sign-in screens. |
| 10 | Core flow | Activity · Complete | Friendly completion without failure tone. Show bottom nav on post-sign-in screens. |
| 11 | Core flow | Parent · Week summary | Activities done and time spent this week. 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: Activity · In progress · Activity · Complete · Parent · Week summary
Flow 3 · Navigation
Link every nav tab so examiners can tap each bottom nav item. Tabs: Bottom navigation (Parent View): Dashboard · Activities · Tips · Settings
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):
A child cannot complete an activity because it is too difficult. Do not label it as 'too hard'. Auto-suggest a shorter or simpler version with: 'Let's try a smaller step first.' No failure messaging.
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