Public-sector software is judged by a harder standard than commercial software. It cannot assume a device, a connection, a language, or a level of familiarity, and it cannot decline to serve the people who find it most difficult. That constraint is usually treated as a compliance obligation. It is better understood as the design brief.
A commercial product can choose its users. If a segment finds the interface confusing, the product can decide that segment is not the target. A government service has no such option. Everyone who is eligible is a user, including the people least equipped to navigate a poorly designed form.
Accessibility is architecture, not a final pass
The most common failure in government delivery is treating accessibility as a review step. A portal is designed, built, and then audited; findings come back; remediation is scheduled; some of it happens.
This sequence is expensive and it does not work well, because the significant accessibility properties are structural. Whether a form's error handling is comprehensible, whether a multi-step process can be completed without losing state, whether a table of results is navigable without sight — these follow from decisions made early, in the data model and the flow, not from attributes added late.
Designing for the constraint from the start is cheaper and produces a better service for everyone. Clear error messages, predictable navigation, and forms that preserve what has been entered are not accommodations. They are just competent design that the constraint forces you to actually do.
The process cannot be redesigned to suit the software
Commercial software frequently reshapes an operation to fit the tool, and this is often reasonable. In the public sector it usually is not, because the process is typically established in policy or legislation, has been documented, and has consequences attached to each step.
The system therefore has to accommodate the process as it actually operates — including its exceptions, which are where most of the difficulty lives. A registration flow that handles the standard applicant and fails on the unusual one has solved the easy half of the problem.
The practical implication is that delivery begins with the operation, not the interface. Who submits. Who reviews. What triggers an approval. What must be recorded and retained. What happens on refusal, on appeal, on refund. Interfaces built before those answers exist are almost always rebuilt.
A service that works for the standard case and fails on the exception has solved the easy half of the problem.
Where platform capability ends
Low-code platforms are now the default for a large share of public-sector delivery, and for good reason: standard workflow, security roles, and data structures are genuinely faster to configure than to write.
The judgment that matters is knowing where configuration stops holding. Conditional approvals across multiple roles, external users with differentiated permissions, payment reconciliation, audit obligations — each of these tends to push past what the default patterns handle cleanly.
Extend too early and the result is an unmaintainable system that has abandoned the platform's advantages. Extend too late and the result is a system contorted into shapes it was never meant to take, which is worse. Getting this boundary right is most of the skill in this kind of delivery.
Constraints that do not appear in the requirements
Several requirements in public-sector work are real but rarely written on the ticket.
Data residency determines hosting decisions before anything else is settled. Audit and retention obligations shape the data model. Role separation is a structural requirement, not a permissions afterthought. And the service must remain operable by staff whose training budget is finite and whose turnover is not.
That last one deserves more attention than it gets. A system that requires an expert to administer will be administered badly, and the quality of the public-facing service degrades accordingly.
What "usable" actually means here
Usability in this context is not delight. Nobody is enjoying a permit renewal.
It means a person can determine whether they are eligible, understand what is required of them, complete the task without external assistance, know that it worked, and find out what happens next. It means the same person can do this on an old phone, on a poor connection, with a screen reader, in their second language.
That is a demanding standard, and it is the correct one. Services built to it also happen to be cheaper to operate, because the support burden of a confusing service is paid every day by staff who could be doing something else.