Public-sector technology
Designing digital public services that people can use
Principles for accessible forms, clear eligibility, resilient workflows, privacy, status communication, and maintainable government technology.
A digital public service succeeds when a person can understand what the service is, determine whether it applies to them, complete the required process, and know what happens next. The technology matters, but the public experience is shaped equally by policy language, evidence requirements, institutional workflow, support, and accountability.
Design the service, not only the portal
Digitizing a confusing process can make confusion move faster without removing it. Teams should map the full service from discovery to final outcome, including offline steps, internal reviews, exceptions, appeals, notifications, and support. Policy and operations teams must participate alongside designers and engineers.
The strongest opportunity is often simplification: remove unnecessary questions, reuse information the institution already has lawfully, explain why evidence is required, and reduce handoffs that create delay without improving control.
Make eligibility and evidence understandable
People should not need to complete a long form before learning that they are ineligible. Services should explain who can apply, what documents are needed, likely processing stages, fees, deadlines, and available support in plain language before the application begins.
Examples and checklists are often more useful than policy text copied into an interface. Important information should be visible in accessible HTML and available in the languages needed by the service population.
Build forms that recover from real life
Public forms may involve many fields, evidence uploads, family information, or information gathered over time. Users should be able to save progress, return safely, review answers, correct mistakes, and understand validation messages. Sessions and upload limits must reflect the actual task.
- Ask one coherent group of questions at a time.
- Explain errors next to the field and in a summary.
- Accept realistic file formats and clearly state size limits.
- Provide a confirmation and reference after submission.
- Design assisted-digital and offline alternatives for people who need them.
Communicate status and responsibility
Silence creates repeat visits, phone calls, and distrust. A service should show the current stage, actions required from the applicant, expected next step, and a route for help or correction. Internal teams need the same operational visibility through queues, ownership, service-level measures, and audit trails.
Notifications should avoid exposing sensitive information and should not rely on one channel. The service should remain understandable even when a message is delayed or never delivered.
Treat accessibility, privacy, and security as service quality
Accessibility enables people with disabilities and also improves use on small screens, older devices, and difficult environments. Privacy requires data minimization, clear purpose, retention rules, access controls, and a way to correct information. Security requires threat modeling, secure development, monitoring, incident response, and operational ownership.
These are not compliance decorations. A service that excludes users, exposes information, or cannot recover from failure is not a successful digital service.
Plan for institutional ownership
A public system should be maintainable after the initial project team leaves. That requires documented architecture, clear source-code and data ownership, training, support processes, accessible content governance, dependency management, backups, and realistic budgets for operation and improvement.
Government technology becomes durable when it strengthens the institution operating it. The goal is not a launch event; it is a service that continues to work, improve, and earn public trust.