I designed the user flows, wireframes, and UI mockups with one scenario in mind: a tired parent at 19:00 in a dimly lit room in Johannesburg.
Before sketching a single screen, I need to deeply understand the context of use. This isn't a casual browsing app — it's a tool used at a very specific, stressful moment. The design must serve that moment.
| Factor | Reality | Design Implication |
|---|---|---|
| Time | 18:45 – 19:00, just before putting baby down | Auto dark mode. No bright whites. Warm, low-contrast palette. |
| Mental state | Tired, multitasking, possibly holding a fussy baby | Large touch targets. No tiny buttons. Maximum 3 taps to answer. |
| Physical context | Often one-handed, phone in one hand, baby in the other | All key actions reachable with one thumb. No horizontal scrolling. |
| Lighting | Dimmed room, bedtime routine lighting | Dark mode default in the evening. High enough contrast to read, low enough to not blind. |
| Urgency | Baby is ready NOW. No time for browsing or reading. | Answer first, explanation second. Hide the "why" behind an expandable tap. |
| Location | Primarily South Africa; also global English-speaking markets | Celsius primary (°C), with °F toggle. Weather API supports SA locations. Freemium model: Free (1 child) / Premium subscription for up to 10 child profiles. |
I designed the core flow so that the recommendation appears instantly when the app opens — no taps required. The baby’s age is already set up from onboarding, the weather auto-loads from the device’s location, and the recommendation auto-displays. The parent’s job is simple: open the app, see the answer, dress your child.
| Scenario | What Happens |
|---|---|
| Temperature is dangerously high (>27°C) | ⚠️ Safety warning appears with the recommendation. Colour-coded "Hot" badge with guidance. |
| Temperature is very low (<16°C) | ⚠️ "Cold" badge with safety note. Still shows recommendation with maximum layering. |
| Weather API fails | Graceful fallback to manual temperature slider. Manual input always works. |
| Location permission denied | Falls back to city search or manual temperature input. No nagging or repeat prompts. |
| Multiple children | Baby selector at top of Tonight tab. Tap to switch — recommendation updates instantly for the selected child's age band. |
| New user (first time) | 5-step onboarding: welcome, location, temp unit, child profile, wardrobe. Straight to Tonight tab with first recommendation. |
| Not signed in | App works fully offline with local storage. Sign-in (Apple/Google) enables cloud sync across devices. |
I designed the app with 4 main tabs: Tonight (get tonight's recommendation), Morning (log how baby slept), Wardrobe (manage clothing), and Settings (account, notifications, preferences). Below are wireframes for the Tonight and Morning screens. The app auto-switches to dark mode after 18:00, and includes features like push notifications, streak tracking, share, and cloud sync that were added during the QA review cycles.
The primary screen auto-loads the recommendation when the app opens — no taps needed. It shows the active baby’s profile, tonight’s weather forecast with hourly breakdown, and the complete outfit recommendation with safety badge, layers, and an evening tip. Parents can switch children at the top or use the manual temperature slider if their indoor temp differs from the forecast.
I designed the morning screen where parents log how baby slept. It collects sleep quality (1–5 stars), outfit feedback (Too Cold / Just Right / Too Warm), wake-up count, and optional notes. This data feeds the insights dashboard and pattern detection.
How did Kago sleep last night?
Every design choice I made has a reason tied to user research. Here are the 10 most important design decisions for Snug Tonight, each traced back to what I learned in Discovery (Stage 1).
I chose persistent tab navigation because mobile apps need it. These four tabs cover the complete lifecycle: (1) Tonight—get a recommendation, (2) Morning—log sleep & outfit feedback, (3) Wardrobe—manage clothing items, (4) Settings—preferences & account. I made Tonight the default/primary flow.
I designed it as 5 steps: Step 1: Welcome with sign-in (Apple/Google SSO or skip). Step 2: Location permission (skippable). Step 3: Temperature unit choice (°C/°F). Step 4: Baby stage + name + avatar. Step 5: Wardrobe setup. I ordered them to get parents to value as fast as possible — under 60 seconds from download to first recommendation.
Instead of asking "Was the outfit good?" (too simple), I designed the Morning tab to collect: (1) Sleep quality (1–5 stars), (2) Outfit appropriateness (Too Cold / Just Right / Too Warm), (3) Night wake-ups counter, (4) Optional notes. This rich data enables pattern detection like "my child tends to run warm" and improves future recommendations significantly.
I organized items in 5 categories: Bodysuits, Sleepsuits, Sleep Bags & Suits, Swaddles & Layers, Sleep Layers. Each item has a status: Available / In Laundry / Clean. "Missing for Tonight" alerts show if recommended items aren't available, with substitute suggestions. I added this because it bridges the gap between the recommendation engine and what I actually have in my wardrobe.
Even when a parent enters temperature manually, I show tonight's weather forecast as context — so they can see "it's 22°C now but drops to 16°C by 03:00" with a time range like "12AM – 6AM: 17° to 14°". This is the product's core insight. I keep it visible because hiding it would undermine the value I'm offering. The location label (e.g., "Sandton") is also shown.
I realized bedtime routines happen in dim lighting. A bright white screen at 18:45 is hostile. I designed auto-switching to a warm dark theme to respect the bedtime environment. Parents can override this manually if they prefer.
I designed the result screen to show the outfit immediately. The "Why this outfit?" is collapsed behind a tap. This respects my principle: "Be prescriptive, not educational." The 90% who just want the answer get it instantly. The 10% who want to learn can tap to explore.
I designed each recommendation to include an SVG illustration of the outfit (not emoji) showing the layers visually. Beneath, a numbered layer-by-layer breakdown (1: Nappy, 2: Bodysuit, 3: Sleep sack, etc.). I added this because it removes ambiguity and helps caregivers unfamiliar with terminology instantly understand what to put on the baby.
Green = ideal range, amber = caution (slightly too warm/cold), red = dangerous. I made these badges appear at the top of the result screen — before the outfit — because safety takes priority over comfort. I never hide warnings behind a tap.
I believe transparency builds trust. The parent should always know WHICH temperature the recommendation is based on. This is especially important when the current temp and overnight low differ significantly. It validates my core product promise: "I dress for 03:00, not 19:00."
I designed Snug Tonight to be usable by all parents, including those with visual impairments, motor difficulties, or cognitive load (which, frankly, describes most parents at bedtime). Here's how I address accessibility:
| Principle | Implementation | Standard |
|---|---|---|
| Colour contrast | All text meets 4.5:1 contrast ratio in both light and dark mode. Safety badges use colour + icon + text (never colour alone). | WCAG 2.1 AA |
| Touch targets | All interactive elements are minimum 44×44px. Age pills and CTA button exceed this. | WCAG 2.1 Target Size |
| Screen reader support | All elements have proper ARIA labels. Recommendation result reads as natural language: "For a 3-to-6 month old at 16 degrees Celsius, I recommend a 2.5 TOG sleep sack over a long-sleeve bodysuit." | WCAG 2.1 A |
| Reduced motion | Respects prefers-reduced-motion. No essential animations. Slider works without animation. | WCAG 2.1 AAA |
| One-handed use | All primary actions within thumb reach zone on standard phone sizes. No swipe-only interactions. | Usability best practice |
| Language simplicity | All text written at a Grade 6 reading level. No medical jargon without explanation. "TOG" is always explained on first use. | Plain language standard |
Design isn't just about how it looks — it's about whether it works. These metrics tell me if my design is achieving its goals:
| Metric | Target | How I Measure |
|---|---|---|
| Time to recommendation | <10 seconds | Analytics: timestamp from page load to result screen display |
| Tap count to result | ≤3 taps | User testing: observe task completion. Analytics: tap event count per session. |
| Task completion rate | ≥90% | % of sessions where user reaches the result screen (no abandonment) |
| Error rate on input | <3% | % of sessions where user corrects their input (re-selects age or adjusts temp multiple times) |
| Dark mode adoption | ≥70% of evening sessions | Analytics: mode at time of use. Validates my auto-switch decision. |
| Morning log submission rate | ≥40% | Analytics: % of users who submit morning feedback the day after a recommendation. Validates habit formation and data collection for insights. |
| Wardrobe tab usage | ≥50% | Analytics: % of users who add at least one item to their wardrobe. Shows engagement beyond core recommendation flow. |
| Usability test pass rate | ≥85% | 5-user usability test: can they get a recommendation, log morning feedback, and access wardrobe without guidance? |
| Artefact | What It Shows Stakeholders |
|---|---|
| Design Context Table | I understand the physical, emotional, and environmental context of my user |
| User Flow Diagram | I mapped happy paths and edge cases before any code was written |
| 4-Tab Navigation Architecture | I designed a complete app ecosystem: Tonight (recommendation), Morning (logging), Wardrobe (management), Settings (preferences) |
| Wireframes: Tonight + Morning Screens | I can communicate core flows visually — both light and dark modes |
| 10 Design Decisions + Rationale | Every choice traces to research and actual app features. I don't design by gut. |
| Accessibility Table | I think about all users, including those with impairments |
| Design Metrics | I measure design quality across multiple dimensions: speed, completion, engagement, and accessibility |