Tworzenie rządowych usług cyfrowych: wnioski z praktyki

Tworzenie oprogramowania dla administracji publicznej różni się od działań w każdej innej dziedzinie. Stawka jest wyższa, ograniczenia są bardziej rygorystyczne, a użytkownikami są wszyscy — a nie tylko wyselekcjonowana grupa pionierów.

Po ponad 18 latach pracy w HMCTS, Ministerstwie Sprawiedliwości, Departamencie Transportu oraz DWP zgromadziłem zbiór zasad, które pozwalają odróżnić projekty, które są realizowane, od tych, które utknęły w martwym punkcie.

1. Zacznij od użytkownika, a nie od usługi

Pierwsza zasada projektowania serwisu GOV.UK — „Zacznij od potrzeb” — brzmi jak coś oczywistego. W praktyce jednak rzadko tak jest. Niemal w każdym projekcie wstępny brief opisuje system, a nie problem użytkownika.

Kiedy zaczynaliśmy pracę nad Usługi w zakresie roszczeń dotyczących własności W przypadku HMCTS pierwszą reakcją było odtworzenie papierowej procedury w formie cyfrowej. Zamiast tego poświęciliśmy pierwszy sprint na zidentyfikowanie, kto faktycznie korzysta z tej usługi: adwokaci składający wnioski zbiorczo, strony występujące samodzielnie składające wnioski jednorazowo oraz sędziowie analizujący dowody. Trzy zupełnie różne modele myślenia, jedna usługa.

// 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'],
  },
];

Powstała usługa miała trzy odrębne ścieżki. Każda decyzja dotycząca treści, każde pole formularza i każdy komunikat o błędzie zostały opracowane z myślą o konkretnej personie.

2. Traktuj dostępność jako element architektury, a nie jako audyt

Większość zespołów zajmuje się kwestią dostępności dopiero na samym końcu. Szybki przegląd za pomocą narzędzia Axe, kilka poprawek dotyczących kolorów i gotowe. To nie działa — a w sektorze publicznym nie jest to kwestia wyboru. Zgodność z wytycznymi WCAG 2.2 poziomu AA stanowi wymóg prawny wynikający z rozporządzenia w sprawie dostępności podmiotów sektora publicznego.

Zespoły, które radzą sobie z tym dobrze, uwzględniają to w definicji „zakończenia zadania”:

• Każdy nowy element został przetestowany przy użyciu czytnika ekranu (NVDA + Chrome, VoiceOver + Safari)
• Przed zatwierdzeniem PR sprawdzana jest nawigacja za pomocą klawiatury
• Kontrast kolorów jest sprawdzany na etapie projektowania, a nie na etapie tworzenia

// 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 nie jest opcjonalne w przypadku projektów rządowych

W sektorze publicznym obowiązują jedne z najsurowszych wymagań dotyczących zarządzania zmianami. Paradoksalnie jest to powód, by intensywnie inwestować w automatyzację — nie po to, by działać szybko, ale by udowodnić, że każda zmiana jest bezpieczna.

W ramach naszego projektu realizowanego we współpracy z Ministerstwem Transportu (DfT) stworzyliśmy proces, który zapewniał:

# 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

Audyt dostępności stanowił poważną przeszkodę. Niepowodzenie skanowania za pomocą narzędzia Axe zablokowało wydanie. Żadnych wyjątków ani obejść bez udokumentowanej zgody właściciela produktu na przyjęcie ryzyka.

4. Figowiec dusiciel jako narzędzie modernizacji istniejących systemów

Każdy departament rządowy posiada gdzieś 20-letni system mainframe. Model „figowca dusiciela” — polegający na stopniowym przekierowywaniu ruchu do nowej usługi przy jednoczesnym utrzymaniu starego systemu — jest najbezpieczniejszym sposobem na modernizację bez radykalnej przebudowy, która mogłaby zagrozić funkcjonowaniu usług publicznych.

Kluczem jest wczesne stworzenie warstwy routingu:

// 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}`);
}

Najważniejsze wnioski

• Badania użytkowników nie są etapem — to nieustanna działalność, która stanowi integralną część procesu realizacji
• Dostępność to architektura — projektuj z myślą o tym, testuj pod tym kątem, wprowadzaj kontrolę na tym etapie
• Zautomatyzuj wszystko, co podlega audytowi — jeśli coś da się sprawdzić maszynowo, to powinno się to zrobić
• Położyć kres tradycji — nie przepisuj, tylko przekieruj

Wdrażanie usług cyfrowych przez rząd to trudne zadanie. Jednak gdy się to udaje, efekty są ogromne — miliony ludzi korzystają z usług, które naprawdę im służą. Warto więc zadbać o to, by wszystko działało jak należy.