Operational workflows across an interconnected platform
Designing role-based products for administrators, centre managers, educators, staff, and parents across waitlists, enrolment, child records, planning, and daily operations.
Product context
Parent
Parent is a childcare-management platform used by nurseries and nursery groups internationally, from a single setting to a group running thirty sites. It carries admissions, enrolment, child records, attendance, planning and parent communication — and it has to satisfy inspectors as well as staff: the product publishes reporting aligned to Dubai’s KHDA and Abu Dhabi’s ADEK alongside GDPR and PIPEDA. Regulation is not a compliance page bolted on the side; it sets what the interface is allowed to hide.
- My role
- Senior Product Designer
- Period
- 2024 — 2025
- Users
- Administrators · Centre managers · Educators · Staff · Parents
- What I did
- End-to-end product journeys across operational modules
- Operational dashboards and high-density tables
- Information architecture across connected records
- Responsive web and tablet patterns
- Prototyping, design-system consistency, developer and QA collaboration
Product ecosystem
Modules that must stand alone and stay connected
- Admissions & Waitlist
- Enrolment
- Child Profile
- Attendance & Illness
- Lesson Planning
- Parent Communication
Core complexity
One product, two very different customers
A single nursery and a thirty-site group buy the same software and use it nothing alike. The group needs to work across sites without losing the one it is standing in; the single setting must never pay in complexity for capability it will never use.
Some numbers are legal, not informational
Children against staff per room is not a metric someone might want to check. It is a regulated threshold, and a room that crosses it has to be fixed now. That distinction decides what may sit behind a drill-down and what may not.
Safeguarding is a field, not a policy
A protected address, a contact whose number must stay hidden from other parents, a person with no right to collect. These are properties of a record that the interface has to honour every time it renders, in every module.
The same day, from five points of view
An administrator, a centre manager, an educator, support staff and a parent all look at one child’s day and need different amounts of it. The record is shared; the reading is not.
Selected journeys
Multi-organisation scale
The obvious answer to "our customers range from one nursery to thirty" is two products, or one product with an enterprise tier. We built a filter instead. Organisation scale became a control inside the interface rather than a fork in the codebase, so a group operator works one queue across every site and a single setting never sees the machinery.
Where a parent’s request becomes staff work
A parent submitting an enquiry does not know they have started an approval workflow, and should not have to. On the staff side the same submission has to arrive as a ranked, assignable, auditable item. The decision was to make the conversation itself carry the responsibility — participants, roles and admin rights are visible inside the thread rather than in a settings screen nobody opens mid-task.
- 01
The parent-facing entry point opens an approval owned by staff. - 02
Search reaches across the records a conversation touches.
One screen, in depth
A day, readable at a glance
- 01
Summary before detail
Attendance actual against expected sits first, so the shape of the day reads before any single record does.
- 02
Status as a filter
Absent, checked in, on a trip — operational states double as the navigation into the detail behind them.
- 03
The ratio never hides
Children against staff per room is a regulated threshold, not a statistic. Anything a regulator can close a room over stays on the first screen — a drill-down is a decision that the number can wait.
- 04
Progressive disclosure
Rooms collapse to a single row each; the full register is one step away rather than always present.
Beyond the happy path
Beyond the happy path
Empty and no-results are different problems and deserve different answers: one is an invitation to begin, the other a signal that a filter is too narrow. A request still awaiting a decision has to look unfinished rather than merely quiet, because in an operational product silence reads as done.
- 01
A filter too narrow is a different problem from a list not yet started. - 02
Held items stay visible to staff so nothing stalls silently. - 03
An undecided request is a designed state, not an absence.
Design-system contribution
Room rows, status pills, progress indicators and the scope filter repeat across modules, so an educator who learns the dashboard already knows how the register behaves. The pills are the same component wherever a lifecycle appears — the waitlist and the day view are reading the same vocabulary.
Reflection
What I would do differently: scope-awareness was applied list by list rather than being enforced by the data layer, so "does this respect the current site?" became a question we had to ask in code review instead of one the system answered by construction. It held, but it held because people were careful — which is not the same as being safe.