Digital public service development

A simple form only collects a request. A real digital public service also handles case status, supporting files, reminders, approvals, action history, and the instruction back office. Without that continuity, you only move the entry point without improving real processing.

You need to start from the decisions and supporting files that are actually necessary, then remove fields, documents, and branches that help neither the citizen nor the instruction process. A good digital journey does not hide administrative complexity; it restructures it so it can be understood and handled at the right moment.

Because supporting files determine case completeness, processing time, and the ability to review a decision months later. If upload, checking, replacement, and historization stay unclear, the whole service falls back on calls, emails, and off-workflow handling.

The citizen journey and the back office must be designed together around the same objects: case, file, status, follow-up request, decision, and history. If you design a polished front layer first and only address instruction afterwards, agents often inherit a second job instead of a true simplification.

The clearest indicators are often average processing time, the share of complete cases at first submission, reminder volume, the proportion of requests followed without phone calls, and the amount of manual rework on the agent side. You need to measure real processing outcomes, not only the number of submitted forms.

You need framed branches, explicit statuses, and visible manual handoffs when a standard rule no longer fits. The danger is not the exception itself, but the moment it leaves the system entirely and breaks the case history.

Not systematically. An account brings continuity when the citizen needs to come back, complete, track, or retrieve decisions over time. If the service concerns a very one-off procedure, it can be more relevant to frame the workflow and history first before opening a broader citizen space.

You need to address them while framing journeys, components, forms, error messages, and documentary evidence. When accessibility is postponed until final QA, it becomes a costly correction list instead of a design principle aligned with public service delivery.

At minimum you need functional mapping, a clear view of roles, flows, integrations, business rules, environments, and takeover conditions. Reversibility does not rest on an abstract promise: it depends on deliverables that allow another team to understand, maintain, and evolve the service.