# Children and memories — intuitiveness review

11 September 2026 · Round 06 · Expert review of the browser prototype, not a parent usability study.

The B3 phone direction is ready to become a working app increment. The main correction is hierarchy: NAAST should introduce the children and a moment worth keeping, while making the next handover and unanswered request immediately reachable. M3 remains Dani’s preferred collection; retain all four alternatives for the cofounder’s review, then implement one.

## Evidence and method

Reviewed the existing Home, child profile, all four memory layouts, capture/detail, calendar and navigation at phone sizes. Walked the tasks below with fictional fixtures and inspected the rendered screens. The earlier [BeNice screenshot review](12-mobile-family-design-review.md) remains the visual reference: grouped rows, rounded actions and clear sheets. Screenshots cannot establish how easy either product is to use.

The research supports familiar language, consistent actions, visible outcomes and preventing errors. Those principles inform the changes below; they do not prove commercial success. [Nielsen Norman Group: usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/).

Visible child choices and a recent memory reduce the need to remember where something lives. A chapter cover must also match the selected child if that visual cue is to be trustworthy. [NNG: recognition rather than recall](https://www.nngroup.com/articles/recognition-and-recall/).

Form labels remain visible while typing. Placeholder examples supplement labels; they do not replace them. [NNG: placeholders in form fields](https://www.nngroup.com/articles/form-design-placeholders/).

We aim for primary phone controls at least 44–50 CSS pixels high in the preview, with accessible native equivalents to verify on devices. WCAG 2.2’s AA target-size criterion is 24 CSS pixels with exceptions; our design target is deliberately larger, and is not a claim of WCAG certification. [W3C: target size minimum](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html).

## Findings and revisions

| Finding | Consequence | Round 06 change |
| --- | --- | --- |
| Home led with a request and coordination content | First impression underplayed the children and their history | Child names/profiles, Add a memory, compact handover/request shortcuts and a recent memory lead Home |
| Memory capture demanded a title | An ordinary photo or remembered sentence needed unnecessary work | Title is optional; require a story or one attachment, plus child selection and date |
| A filtered M3 book could retain another child’s cover image | The selected child and visible history disagreed | Covers and counts come from the filtered records; empty chapters disappear |
| Each memory layout used its own screen heading | Review concepts leaked into app navigation | All four screens say Memories; distinct compositions remain below the shared header |
| Decorative shelf labels obscured familiar actions | Parents had to interpret the vocabulary | Your memory books, Recent memories and Add memory use direct language |
| Child profiles did not directly open their memories | Practical information and childhood history felt disconnected | Each profile opens Memories with that child already selected; capture preserves the selection |

The Home balance is a hypothesis worth testing: capture should be easy during an ordinary day, and finding Friday’s handover should remain fast during a busy one. The demo’s static request count and recent-memory card are examples. Production must derive them from authorized data, including a useful empty Home for a solo parent with no memories yet.

## Remaining design work before the corresponding feature ships

- **Sharing comprehension:** the current capture demo shows a connected family and shared audience only. Production needs private/solo/shared states, named recipients, and a disclosure preview when inviting the other parent. Never silently share an existing private archive.
- **Real capture:** test the native picker, permission denial, HEIC, interrupted uploads, processing, retry and cancellation. Keep written drafts recoverable. Saving locally and sharing successfully need distinct feedback. Small clips remain planned; this demo does not process video.
- **Growing history:** M3’s illustrated fixtures are a presentation study. Production needs deterministic month/milestone groups, useful text-only covers, cursor pagination and clear empty filters. No generated storytelling or custom album editor is required.
- **Native behaviour:** verify keyboard avoidance, VoiceOver/TalkBack names and reading order, large text, contrast, safe areas, back gestures and tap accuracy on physical phones. Browser screenshots and automated checks cannot establish these.
- **Coordination clarity:** test agreed versus proposed times, holiday overrides, an unanswered question versus a formal request, and packing linked to the correct child/occurrence. Home must not hide a time-sensitive item under a long feed.
- **Terminology:** test whether parents understand More → Agreements as the home of Requests. Keep this open for observed feedback; do not add another navigation destination just to expose every module.

## Small parent test before expanding the build

Recruit 6–8 parents for short individual sessions, including solo initiators and invited parents, with different levels of cooperation and phone confidence. Use fictional family data and obtain consent for any recording. Do not collect their children’s real photos for a prototype exercise. Ask them to act before asking which design looks nicest.

| Task, without naming the control | Observe |
| --- | --- |
| “Finn said something funny. Keep it for later.” | First tap, successful text-only save without a title, correct child |
| “Keep this photo of Mila, without writing a caption.” | Whether a title seems compulsory; correct child and save outcome |
| “Who will see the thing you just saved?” | Correct audience explanation, not just successful button tapping |
| “Find Finn’s earlier milestone.” | Child filter, chapter understanding and return navigation |
| “When and where is the next handover? Is 18:00 already agreed?” | Correct committed time, proposal distinction and path to the request |
| “Find Mila’s practical information, then her memories.” | Profile discoverability and continuity of child context |

Record unaided completion, wrong turns, first action, time on task, requests for help and misunderstood audience/commitment. Treat repeated confusion as a correction to make, not a parent’s failure. Run a second small round after fixes. Test the leading M3 first; if comparing all four layouts, rotate their order and reuse equivalent tasks to reduce learning bias.

There are no participant results yet. No numerical “intuitiveness score” or improvement percentage is claimed here.

## Commercial learning and implementation consequence

The proposition to test is: **one place to care for their day and keep their childhood, across both homes.** Memories alone are not a unique competitive claim; BeNice already presents a diary. Our hypothesis is that the combined experience is useful and meaningful enough to return to voluntarily.

Build and test child → capture → revisit early, then the shared care-change loop. During the later pilot, measure families creating and revisiting memories over successive weeks, with separate solo/connected cohorts. Interview parents about why they return and what they would pay for. A small observational pilot cannot prove that memories cause retention. Avoid streaks, guilt, parent comparisons or making a child’s history difficult to export as retention tactics.

Next: review the bounded [first-slice contracts](15-first-slice-contracts.md), create the native foundation, then run backend and native-interface implementation against the same examples. Full launch scope and media guardrails remain in [document 10](10-final-mvp-scope.md).