Building digital public services that last

The Submit button is the most visible moment in a digital public service. The service itself begins earlier and ends much later. People first need to understand eligibility and find the correct process. They may then need to establish identity, provide evidence, respond to questions, and receive a decision in a form they can use.

Germany's Online Access Act, commonly called the OZG, reflects that broader view: electronic administration includes information and communication with the people using the service, not just a web form. Modernizing only the front end leaves the costly breaks behind it. Staff rekey data, applicants email missing documents, and portals send cases into back-office systems without receiving a reliable status in return. To the public, that is not an internal integration issue. It is a service that cannot be trusted.

The service begins before the form

Design starts with the process. What makes someone eligible? Which agency owns the case? What information may it collect, what data already exists, and which documents are actually required? Language belongs in the same discussion. An unclear term creates support calls and abandoned applications that no amount of technical polish can fix.

The OZG calls for simple, intuitive use and for involving users in the development of new electronic services. That involvement should continue after launch. Questions received by service desks, repeated mistakes, and drop-off points are evidence for the next release.

Data sharing also needs a legal and operational basis. The European Union's Single Digital Gateway Regulation generally ties cross-border automated exchange of evidence to an explicit request from the person involved. Reuse can reduce effort, but it should not become an excuse to move personal data without a defined purpose and accountable process.

Quality lives in the handoffs

The connection between an online service and a case-management system needs unambiguous fields, documented formats, versioned contracts, and named ownership. A technically successful transfer is still a failure if the record is incomplete or cannot be processed at the destination.

Error paths are part of the service design. A temporarily unavailable system requires a different response from an invalid document. A retry must not create a second case. When automation stops, staff need to know who takes over, where work continues, and how the applicant will be informed. A manual fallback can be appropriate, provided it remains controlled and does not quietly become a permanent parallel process.

These rules do not fit entirely in an API specification. Agencies also need shared status language and aligned service-level expectations. The technical and administrative agreements have to work together across organizational boundaries.

Accessibility extends through the workflow

Germany's federal accessible information technology regulation, BITV 2.0, reaches beyond individual pages to electronically supported administrative processes. Embedded forms, identity steps, and payment flows are included. Accessibility therefore applies to the full journey: instructions, validation errors, uploaded documents, follow-up questions, and confirmations.

Reusable standards help teams avoid solving the same interaction problem differently in every agency. KERN, an open user-experience standard for German public administration, combines interface components with methods for user-centered and accessible service design. It does not replace policy or content work. It gives multidisciplinary teams a shared foundation.

Operations are part of the public service

After launch, laws change. Forms, registries, interfaces, and agency responsibilities change with them. A durable service needs named policy and technical owners, a controlled release process, and a path for urgent corrections. Dependencies should be monitored, and incident escalation should lead to someone with authority rather than a search across agencies.

Page views alone reveal little about quality. More useful measures include abandonment at a specific step, recurring support questions, transfers that cannot be processed, and cases that remain idle. Publishing the service is not the finish line. The service succeeds only when people can complete the real-world process and the government can operate it reliably over time.