Government Digital Delivery
Requirements for Government Digital Portals: What's Different and Why It Matters
Most government portals fail at the requirements stage, not the build stage. Three different teams agree the form looks right. Then a citizen with a screen reader cannot get past field two, the policy team realises step four contradicts a regulation nobody flagged, and the operations team learns about case ownership the week of launch. None of that is a coding problem. All of it is a requirements problem.
The screen is not the requirement. The service is.
What does this person actually need to finish? A renewal. A status check. A reported change of address. The form is just the visible part. Behind it sits a citizen who may or may not have their documents ready, an operations team that has to pick up the case after submission, a policy rule that may have changed since the last release, and a data record that has to reconcile with three other systems.
If the requirement only describes the screen, the team is going to ship a form that works and a service that does not. I want the requirement to follow the citizen through the whole thing — including what happens when they cannot continue, when they come back two weeks later, and when a human has to take over.
Accessibility is a design decision, not a QA pass
Every team I have seen treat accessibility as a final check has rebuilt half the portal late. Focus order changes layout. Screen-reader expectations change validation copy. Keyboard navigation changes how errors surface. Document upload alone has three different accessibility paths depending on whether someone is using assistive tech, a phone camera, or a desktop scanner.
Government services do not get to ship an inaccessible version and fix it next quarter. The requirement has to name what good looks like before the design starts — not after a tester flags it in week 9.
Policy says what. Workflow says how.
Policy documents tell you what must be true. They almost never tell you how the portal enforces it, what an exception looks like, who can override the rule, what evidence gets stored, or how a citizen who fails the check gets a path forward. Translating that gap is most of the business analysis work in government delivery.
I write this as a matrix: every policy line on the left, the workflow behaviour on the right, the exception path below it, and the owner named explicitly. If a row is empty, the requirement is not finished.
Data and privacy need a name on every field
Government services move sensitive data between systems and teams that often do not share infrastructure. Where does the SIN live? Who can read it in the support tool? How long does the address change get retained after the case closes? Which fields are consented separately? Which appear in the audit log?
I have seen portals launch with a clean front end and a data map that nobody owns. Six months later there is a privacy review and the team finds out three fields were being logged in plain text because nobody wrote the requirement down.
What I actually produce
For a portal initiative I would produce a service journey (citizen, ops team, policy rule, data record on one page), a stakeholder map with veto-power escalation, a policy-to-workflow matrix, a data dictionary, accessibility acceptance criteria, exception paths, and a go-live readiness view that names owners for every gate.
It is not a bigger document. It is a clearer service. The point of all of that is one thing: the team in the room can decide before the team in delivery has to guess.
Continue reading