La creazione dei servizi digitali della pubblica amministrazione: insegnamenti dal campo

Lo sviluppo di software per la pubblica amministrazione è diverso da qualsiasi altro settore. La posta in gioco è più alta, i vincoli sono più rigidi e gli utenti sono tutti, non un segmento selezionato di early adopters.

Dopo oltre 18 anni di lavoro presso l’HMCTS, il Ministero della Giustizia, il Dipartimento dei Trasporti e il DWP, ho individuato una serie di principi che distinguono i progetti che vengono portati a termine da quelli che si arenano.

1. Partire dall’utente, non dal servizio

Il primo principio di progettazione di GOV.UK — “Partire dalle esigenze” — sembra ovvio. Ma nella pratica lo è raramente. In quasi tutti i progetti, il brief iniziale descrive un sistema piuttosto che un problema dell’utente.

Quando abbiamo iniziato a lavorare sul Servizio per le rivendicazioni di possesso Per l’HMCTS, l’istinto era quello di replicare digitalmente la procedura cartacea. Invece, abbiamo dedicato il primo sprint a individuare chi utilizzasse effettivamente il servizio: avvocati che presentavano istanze in blocco, parti in causa che presentavano istanze una sola volta, giudici che esaminavano le prove. Tre modelli mentali completamente diversi, un unico servizio.

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

Il servizio che ne è risultato presentava tre flussi distinti. Ogni scelta relativa ai contenuti, ogni campo del modulo, ogni messaggio di errore è stato concepito per un profilo utente specifico.

2. Considerare l’accessibilità come un aspetto dell’architettura, non come una semplice verifica

La maggior parte dei team si limita ad aggiungere l’accessibilità all’ultimo momento. Una rapida revisione con Axe, qualche ritocco ai colori e via, il prodotto è pronto. Questo approccio non funziona — e nel settore pubblico non è facoltativo. La conformità alle WCAG 2.2 livello AA è un requisito legale ai sensi del Regolamento sull’accessibilità degli enti del settore pubblico.

I team che lo fanno bene lo integrano nella “Definizione di ‘Fatto’”:

• Ogni nuovo componente è stato testato con uno screen reader (NVDA + Chrome, VoiceOver + Safari)
• Prima dell’approvazione del PR viene verificata la navigazione da tastiera
• Il contrasto cromatico viene verificato in fase di progettazione, non in fase di sviluppo

// 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. Il CI/CD non è facoltativo nei progetti governativi

I servizi pubblici sono soggetti ad alcuni dei requisiti più rigorosi in materia di gestione del cambiamento. Paradossalmente, questo è un motivo per investire massicciamente nell’automazione: non per agire in fretta, ma per dimostrare che ogni cambiamento è sicuro.

Nell’ambito del nostro progetto con il DfT abbiamo realizzato una pipeline che garantiva:

# 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

L’audit sull’accessibilità è stato un ostacolo insormontabile. Una scansione Axe che ha dato esito negativo ha bloccato il rilascio. Nessuna eccezione, nessuna deroga senza un’accettazione documentata del rischio da parte del product owner.

4. Il fico strangolatore per la modernizzazione dei sistemi legacy

Ogni dipartimento governativo dispone, da qualche parte, di un sistema mainframe vecchio di vent’anni. Il modello del “fico strangolatore” — che consiste nell’indirizzare gradualmente il traffico verso un nuovo servizio mantenendo attivo il sistema legacy — rappresenta il modo più sicuro per modernizzarsi senza ricorrere a una riscrittura radicale che metterebbe a rischio i servizi pubblici.

La chiave sta nel creare fin da subito un livello di instradamento:

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

Punti chiave

• La ricerca sugli utenti non è una fase — è un’attività continua che si intreccia con la consegna
• L’accessibilità è architettura — progettarlo, testarlo, controllarne l’avanzamento
• Automatizzare tutto ciò che è verificabile — se può essere verificato da una macchina, dovrebbe esserlo
• Mettiamo fine al passato — non riscrivere, reindirizzare

L’erogazione dei servizi pubblici digitali è complessa. Ma quando funziona, l’impatto è enorme: milioni di persone che interagiscono con servizi che rispondono effettivamente alle loro esigenze. Vale la pena fare le cose per bene.