How we follow the GDS principles
The Government Digital Service (GDS) writes guidance on building public services that people can use.
Why we use them
It is the best public guidance we know for services people use when they are tired or stressed. Many parents come to Assembly that way.
Assembly is not a government service, and GDS has not assessed it. We follow its principles because they help families.
For each principle we say what you will find in Assembly, how we know it holds, and where we fall short.
The ten design principles
-
Start with user needs
Find out what people really need before you build anything, and do not guess.
What you will find
- We watched ten parents use Assembly while they talked through what they were thinking. In April, 48 parents tried it and told us what they thought.
- The first question tells you who can see your answers, because parents asked us that.
How we know
- Our design rule, checked in review. We check each thing parents told us against the app, and write down what we changed.
Where we fall short
- Our research is small. We have watched ten parents, and 48 more told us what they thought.
-
Do less
Only build what nobody else provides, and point people to what already works.
What you will find
- Assembly is not an emergency service. Our Urgent help page points you to 999, NHS 111 and Samaritans.
- Assembly does not give a diagnosis. It helps you describe your child to the people who can.
How we know
- Our design rule, checked in review. We check new screens for this when we review them.
-
Design with data
Let what people actually do guide your choices, instead of hunches or guesswork.
What you will find
- Parents in our study stumbled over sayings such as 'loses the thread'. We rewrote 13 questions in plain words.
- Parents asked whether a question meant now or ever. Each group of questions now asks you to think about the last month.
How we know
- Our design rule, checked in review. We went through every finding from the study, compared it with today's app, and recorded what we changed.
Where we fall short
- The parents we watched used an older version of Assembly, so some of what they found no longer applies.
-
Do the hard work to make it simple
Take on the hard work yourself, so the service is easy for the people who use it.
What you will find
- You sign in with a link or a code sent to your email. There is no password to remember and no puzzle to solve.
- Each result is one of four plain bands, such as 'priority area'. You never see a score.
How we know
- A test that must pass before any change can go in. It fails if a password or a puzzle is added to signing in.
- Our design rule, checked in review. Every result uses the same four bands, from one shared piece of code.
Where we fall short
- Some fixed wording in the report still reads older than age 11. We are rewriting it.
-
Iterate. Then iterate again
Start small, test with real people, and keep improving what you have built.
What you will find
- A practice question now comes before the real ones, so you can try the answer line first. Nothing you do there is saved.
- The first question now says that your answers do not decide whether your child gets help.
How we know
- Our design rule, checked in review. Each change came from something parents told us, and we recorded which.
Where we fall short
- We have not yet watched parents use the changed questions.
-
This is for everyone
Make things as easy to use and read as you can, starting with the people who find it hardest.
What you will find
- We aim for the words in the app to suit a reading age of 11.
- You can make the text bigger, turn motion down, and choose light or dark mode.
How we know
- A test that must pass before any change can go in. It fails if new wording in the app reads older than age 11, or 14 for consent and privacy.
Where we fall short
- No person has yet used the Assembly app with a screen reader.
-
Understand context
Think about where people are, and what they are using, when they come to your service.
What you will find
- Many parents open Assembly from an email on their phone, so we design each screen for a phone first.
- You can stop at any point and pick up where you left off. If your connection drops, your answers wait on your device and are sent later.
How we know
- A test that must pass before any change can go in. It checks that an answer waiting to be sent is kept and sent again.
- Our design rule, checked in review. We judge each new screen at phone size first.
Where we fall short
- If your answers are waiting to be sent, the app does not tell you yet.
-
Build digital services, not websites
A service helps people get something done, so think about every step, online and off.
What you will find
- If your child's school invited you, you choose whether its special needs lead (SENCO) sees your answers.
- Your child's report includes next steps. You can share it with teachers, doctors or anyone who supports your child.
How we know
- Our design rule, checked in review. When we review a new screen, we check how it fits the steps before and after it.
-
Be consistent, not uniform
Use the same words and patterns wherever you can, and improve them when you find a better way.
What you will find
- Every result in the app uses the same four bands, with the same names.
- The website and the app share one set of colours.
How we know
- A test that must pass before any change can go in. It checks the contrast of our design system's colour pairs, in light and dark mode.
Where we fall short
- The example profile on our home page still uses different band names from the app.
-
Make things open: it makes things better
Share what you do, including what goes wrong, so others can check it and help improve it.
What you will find
- We publish where we stand on every WCAG criterion, including what is broken and what we have not checked.
- The full record is also a data file that anyone can download.
How we know
- A test that must pass before any change can go in. It checks that each claim in the record points at a real check in our code.
Where we fall short
- Our code is not public.
- No one outside Assembly has checked this record.
GOV.UK added an eleventh principle in 2025, minimise environmental impact. We have not written up how we meet it yet.
Two guides from the GOV.UK Service Manual
-
Building a robust frontend using progressive enhancement
Make each page work with plain HTML first, then add extras such as JavaScript on top.
What you will find
- You can answer every question in the app with JavaScript switched off.
- You can also add a child and make the sharing choice without it.
- With JavaScript on, the same screens gain extras such as the answer slider.
How we know
- A test that must pass before any change can go in. It checks that each kind of question can be answered with JavaScript off.
- A test that must pass before we release the app, unless we override it and record why. Browser tests with JavaScript off cover adding a child, comments and the sharing choice.
Where we fall short
- The forms on this website, such as the early access sign-up, still need JavaScript.
- No person has yet gone through the whole questionnaire with JavaScript off.
-
One thing per page
Ask one question, or give one piece of information, on each page.
What you will find
- The questionnaire shows one question on each screen.
- The welcome tour gives one idea on each card.
How we know
- A test that must pass before any change can go in. It checks that every card in the questionnaire holds exactly one question.