Wellbeing Mark
How I designed a school wellbeing self-evaluation and validation system for Abu Dhabi's education regulator, turning a nested compliance framework into a guided digital workflow shared by schools and ADEK validators.
ADEK, the Abu Dhabi Department of Education and Knowledge, regulates every school in the emirate. Its Compliance System ran inspection visits but had no way for schools to document or evidence their wellbeing practices, so ADEK introduced the Wellbeing Mark, a framework built on five SPIRE dimensions.
I designed the product that makes the Wellbeing Mark real: a guided self-evaluation form schools build and fill from the framework, and a multi-role validation workflow ADEK teams use to plan visits, assign checklists, and rate schools, all inside the existing Compliance System.
A regulator with no way to see wellbeing
The Compliance System was built around inspection visits. It had no dedicated functionality for the thing ADEK now wanted to measure: how well each school actually embeds wellbeing for its students and educators. Evidence lived in documents and inboxes, not in the system that governs schools.
The Wellbeing Mark framework answered the policy question, but a framework is a spreadsheet until someone can use it. Schools needed to self-report against it with evidence, and ADEK needed to validate those claims consistently across hundreds of schools. That is a product problem, and it landed on my desk.
A nested framework, two audiences, one government system
SPIRE is not a flat checklist. It nests: five dimensions, each with elements, each with practice statements that carry their own minimum requirements, frequency, and exposure criteria. A school can only earn the mark if its evidence clears those minimums. Ask people to navigate that raw and they will get it wrong.
The system also has to serve two very different audiences from one codebase: schools self-reporting, and ADEK validators judging. And it lives inside an established government compliance platform, with role-based access, PASS identity integration, and Arabic and right-to-left as first-class requirements.
- Guide schools through a nested framework without letting them submit invalid evidence
- Serve schools and ADEK validators from one system with strict role-based views
- Fit the existing Compliance System's patterns, identity, and RTL requirements
- Support a collaborative, iterative validation visit, not a single form submission
What success had to look like
Guided, not just collected
Schools build their own evaluation from SPIRE, with the framework's rules enforced as they go, not after they submit.
Evidence that counts
Every claimed practice carries a description, frequency, exposure, and real activities, so a validator has something concrete to check.
A visit, digitised
ADEK can plan a visit, assign parts of the checklist to validators, and move through pre-visit, visit, and post-visit states in the system.
Right role, right view
School principals, coordinators, admins, leads, and validators each see and edit only what their role allows.
Turning policy into a data model
I started with the framework itself and the people who own it. Working from the business requirements and sessions with ADEK's wellbeing experts, I mapped SPIRE into a structure a system could hold: dimensions contain elements, elements contain practice statements, and each statement carries reference data, minimum requirements, frequency, exposure, and limiting factors.
I also mapped the human process behind a validation visit: who assigns work, who sees what, how validators collaborate, and how a report gets reviewed and approved. That process, not the screens, drove the information architecture.
The framework must guide the form
Because a school can fail on a minimum it never saw, the reference data and rules had to sit inside the form, blocking submission when the minimums are not met.
One system, two jobs
Schools self-report and ADEK validates. The same records power both, so role, not screen, decides what each person can see and change.
A visit is a conversation
Validation is collaborative and iterative, with request-for-change loops. The system needed assignment, comments, and a full comment history, latest on top.
How I approached it
Model SPIRE and design the self-evaluation
I translated the framework into dimensions, elements, and practice statements with their criteria, then designed the two-step school flow, Build SEF then Fill SEF, that walks a coordinator from picking dimensions down to evidencing individual practices.
Design the ADEK side
I designed visit planning and checklist assignment, where an admin schedules a visit and assigns elements to a lead validator and validators.
Design the visit workflow
I designed the pre-visit, during-visit, and post-visit states, with validation methods, verbal feedback, request-for-change loops, and report generation.
Key decisions, and why
A self-evaluation that teaches the framework
The school flow moves top-down through SPIRE: choose a dimension, see its elements, open a practice statement. On each statement the coordinator sees the guidelines, minimum requirements, minimum frequency, minimum exposure, and the limiting factors that would disqualify them, before they claim anything.
The form enforces the framework's rules as constraints: at least two practice statements per element, and no submission when a claim falls short of the minimum frequency or exposure. The framework does the teaching, so the evidence arrives valid.
Evidence with substance
For every practice a school claims, it records a name, a description, the frequency it runs at, and the grades or cycles it reaches, then attaches the actual activities behind it. A validator opens a submission and sees concrete, checkable practice, not a tick in a box.
This is what makes validation possible later: the self-evaluation is structured evidence, captured once, that the whole downstream visit workflow reads from.
Planning and assigning a visit
On the ADEK side, an admin plans a Wellbeing Mark visit, sets dates, and assigns a wellbeing admin and a lead validator. The checklist is then split across validators by element: each validator can view and edit only their assigned elements, while the lead validator can open the full checklist when they need the whole picture.
Scoping work this way keeps a multi-person visit organised and keeps each validator focused on the evidence they are responsible for.
A validation visit that moves through states
The visit is a sequence, not a single form: pre-visit planning, a pre-validation review where validators comment on the school's evidence, the during-visit stage where they record validation methods and verbal feedback, and a post-visit stage where elements are rated and a report is written.
Every stage carries request-for-change loops. When an admin or manager returns work, their comments appear to the validator as read-only, stamped with name, date, and time, with the latest exchange on top, so the back-and-forth stays legible.
Bringing it all together
Real screens from the shipped product, grouped by who uses them: the schools reporting on themselves, and the ADEK teams who validate them.
For schools: a guided self-evaluation
Choosing a SPIRE dimension
The self-evaluation opens on the five SPIRE dimensions. Picking one reveals its elements, keeping the nested framework navigable one level at a time.
Practice statement with reference data
Opening a practice statement surfaces its guidelines and the minimum requirements, frequency, and exposure a school must meet, before they claim it.
Evidencing a practice
For each practice the school records description, frequency, exposure, and the real activities behind it, turning a claim into checkable evidence.
The completed School SEF
A full self-evaluation form assembled from the framework, ready for the school to review and submit into the Compliance System.
For ADEK: running the validation
Planning a Wellbeing Mark visit
The ADEK admin schedules a visit and assigns the wellbeing admin and lead validator who will run it.
Assigning the checklist
Checklist elements are split across validators. Each sees only their assigned elements; the lead validator can open the full checklist.
What shipped, and what changed
Phase 1 shipped: schools can build and fill a Wellbeing Mark self-evaluation against SPIRE, evidence it, and submit it inside the Compliance System, and ADEK can review those submissions. It gave the regulator its first structured, system-held view of wellbeing across schools.
Phase 2, the validation visit workflow, scoring, and report, is designed and moving into build. Together they turn a policy framework into an operational product that runs the full loop from a school's claim to a validated result.
What I took away
The lesson that stuck: when the domain is this structured, the design work is mostly modelling. Once SPIRE was a clean data model with its rules attached, the screens almost fell out of it, and the hard calls were about where to enforce a constraint, not where to put a button.
Designing for a government regulator also raised the bar on clarity and trust. People are being judged on this data, so every state, permission, and comment trail has to be unambiguous. That constraint made the product better.
- Model the domain first; in structured systems the data model is the design
- Put the rules inside the form, so invalid work can never be submitted
- Let role, not screen, decide what each person sees in a shared system
- For anything people are judged on, make every state and permission legible