Aufbau digitaler Behördendienste: Erkenntnisse aus der Praxis

Die Entwicklung von Software für die öffentliche Verwaltung unterscheidet sich von allen anderen Bereichen. Es steht mehr auf dem Spiel, die Vorgaben sind strenger, und die Nutzer sind alle Bürger – nicht nur eine ausgewählte Gruppe von Early Adopters.

Nach mehr als 18 Jahren Tätigkeit bei HMCTS, dem Justizministerium, dem Verkehrsministerium und dem DWP habe ich eine Reihe von Grundsätzen zusammengestellt, anhand derer sich erfolgreiche Projekte von solchen unterscheiden lassen, die ins Stocken geraten.

1. Beginnen Sie beim Nutzer, nicht beim Dienst

Das erste Gestaltungsprinzip von GOV.UK – „Bei den Bedürfnissen ansetzen“ – klingt selbstverständlich. In der Praxis ist dies jedoch selten der Fall. Bei fast jedem Projekt beschreibt das ursprüngliche Briefing eher ein System als ein Nutzerproblem.

Als wir mit dem Dienstleistung im Bereich Besitzansprüche Bei HMCTS war der erste Impuls, den Papierprozess digital nachzubilden. Stattdessen haben wir im ersten Sprint erfasst, wer den Dienst tatsächlich nutzt: Rechtsanwälte, die Anträge in großer Zahl einreichen, Prozessparteien, die selbst vor Gericht auftreten und einmalig einen Antrag stellen, sowie Richter, die Beweismittel prüfen. Drei völlig unterschiedliche Denkmodelle, ein Dienst.

// Mapping user journeys before writing a line of code
interface UserJourney {
  persona:    'solicitor' | 'litigant-in-person' | 'judge';
  entryPoint: string;
  primaryTask: string;
  painPoints:  string[];
}

const journeys: UserJourney[] = [
  {
    persona:     'solicitor',
    entryPoint:  'bulk upload CSV',
    primaryTask: 'file 50+ claims per week efficiently',
    painPoints:  ['repetitive data entry', 'no batch status updates'],
  },
  {
    persona:     'litigant-in-person',
    entryPoint:  'GOV.UK search',
    primaryTask: 'understand what I need to do',
    painPoints:  ['legal jargon', 'no guidance on documents needed'],
  },
];

Der daraus resultierende Dienst umfasste drei unterschiedliche Abläufe. Jede inhaltliche Entscheidung, jedes Formularfeld und jede Fehlermeldung wurde für eine bestimmte Persona verfasst.

2. Barrierefreiheit als Architektur betrachten, nicht als Audit

Die meisten Teams fügen Barrierefreiheit erst am Ende als Nachzügler hinzu. Ein kurzer Blick mit der Axt, ein paar Farbkorrekturen, und schon wird das Produkt veröffentlicht. Das funktioniert nicht – und im öffentlichen Dienst ist es keine Option. Die Einhaltung der WCAG 2.2 AA-Richtlinien ist gemäß den Barrierefreiheitsvorschriften für öffentliche Einrichtungen gesetzlich vorgeschrieben.

Teams, die dies gut umsetzen, integrieren es in ihre „Definition of Done“:

• Jede neue Komponente wurde mit einem Screenreader getestet (NVDA + Chrome, VoiceOver + Safari).
• Die Tastaturnavigation wird vor der Freigabe des PR überprüft
• Der Farbkontrast wird bereits in der Entwurfsphase und nicht erst in der Entwicklungsphase überprüft.

// Design tokens that guarantee contrast ratios
// — checked against WCAG 1.4.3 (contrast ratio ≥ 4.5:1 for normal text)
$gov-text-on-white:  #0b0c0c; // 21:1 — always safe
$gov-link:           #1d70b8; // 4.54:1 on white — just passes
$gov-link-visited:   #4c2c92; // 5.0:1 on white — passes
$gov-focus:          #ffdd00; // High-vis focus ring

3. CI/CD ist bei Regierungsprojekten kein optionales Element

Behörden unterliegen einigen der strengsten Anforderungen im Bereich des Änderungsmanagements überhaupt. Paradoxerweise ist genau das ein Grund, massiv in Automatisierung zu investieren – nicht, um schnell voranzukommen, sondern um nachzuweisen, dass jede Änderung sicher ist.

Im Rahmen unseres DfT-Projekts haben wir eine Pipeline aufgebaut, die Folgendes sicherstellte:

# Simplified CI pipeline for a GDS-style service
stages:
  - lint
  - unit-test
  - integration-test
  - accessibility-audit
  - security-scan
  - deploy-to-staging
  - smoke-test
  - deploy-to-prod

accessibility-audit:
  script:
    - npx axe-cli https://staging.service.gov.uk --tags wcag2a,wcag2aa
  allow_failure: false  # Hard gate — accessibility failures block the release

Das Barrierefreiheits-Audit war eine strenge Hürde. Ein fehlgeschlagener Axe-Scan verhinderte die Veröffentlichung. Es gab keine Ausnahmen und keine Umgehungen ohne eine dokumentierte Risikoakzeptanz durch den Product Owner.

4. Die Würgefeige als Symbol für die Modernisierung des Bestands

Jedes Ministerium verfügt irgendwo über ein 20 Jahre altes Mainframe-System. Das „Strangler-Fig“-Modell – bei dem der Datenverkehr schrittweise auf einen neuen Dienst umgeleitet wird, während das Altsystem weiterbetrieben wird – ist der sicherste Weg zur Modernisierung, ohne eine radikale Neuprogrammierung, die die öffentlichen Dienste gefährden könnte.

Der Schlüssel liegt darin, frühzeitig eine Routing-Ebene aufzubauen:

// Simplified strangler fig routing middleware
import type { Request, Response, NextFunction } from 'express';

const featureFlags = {
  useNewClaimsService: process.env.NEW_CLAIMS_ENABLED === 'true',
  useNewPaymentsFlow:  process.env.NEW_PAYMENTS_ENABLED === 'true',
};

export function routerMiddleware(req: Request, res: Response, next: NextFunction) {
  if (req.path.startsWith('/claims') && featureFlags.useNewClaimsService) {
    return next(); // New service handles it
  }
  // Fall through to legacy proxy
  res.redirect(307, `${process.env.LEGACY_BASE_URL}${req.path}`);
}

Die wichtigsten Erkenntnisse

• Nutzerforschung ist keine Phase — es handelt sich um eine fortlaufende Tätigkeit, die sich durch den gesamten Lieferprozess zieht
• Barrierefreiheit ist Architektur — dafür entwerfen, dafür testen, danach entscheiden
• Alles, was nachprüfbar ist, automatisieren — wenn es maschinell überprüft werden kann, sollte es auch überprüft werden
• Das Erbe ersticken — Nicht umschreiben, sondern umleiten

Die Bereitstellung digitaler Behördendienste ist eine Herausforderung. Aber wenn sie funktioniert, sind die Auswirkungen enorm – Millionen von Menschen nutzen Dienste, die ihnen tatsächlich helfen. Das ist es wert, richtig gemacht zu werden.