Creación de servicios digitales públicos: lecciones desde la primera línea

El desarrollo de software para la administración pública no se parece a ningún otro ámbito. Hay mucho más en juego, las restricciones son más estrictas y los usuarios son todos los ciudadanos, no un segmento selecto de usuarios pioneros.

Tras más de 18 años trabajando en el HMCTS, el Ministerio de Justicia, el Departamento de Transporte y el DWP, he recopilado una serie de principios que distinguen los proyectos que se llevan a cabo de los que se estancan.

1. Empieza por el usuario, no por el servicio

El primer principio de diseño de GOV.UK —«Empezar por las necesidades»— parece obvio. Sin embargo, en la práctica rara vez lo es. En casi todos los proyectos, el pliego de condiciones inicial describe un sistema en lugar de un problema del usuario.

Cuando empezamos con el Servicio de reclamaciones de posesión En el caso de HMCTS, la primera idea fue reproducir digitalmente el proceso en papel. En lugar de eso, dedicamos el primer sprint a identificar quién utilizaba realmente el servicio: abogados que presentaban documentos de forma masiva, litigantes que actuaban por cuenta propia y que presentaban un solo documento, y jueces que revisaban las pruebas. Tres modelos mentales completamente diferentes, un solo servicio.

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

El servicio resultante contaba con tres flujos distintos. Cada decisión sobre el contenido, cada campo del formulario y cada mensaje de error se diseñó pensando en un perfil de usuario concreto.

2. Considerar la accesibilidad como arquitectura, no como una auditoría

La mayoría de los equipos se limitan a añadir la accesibilidad a última hora. Un rápido repaso con el ratón, unos cuantos ajustes de color y ya está. Esto no funciona, y en la administración pública no es opcional. El cumplimiento de las WCAG 2.2 nivel AA es un requisito legal según el Reglamento de Accesibilidad de los Organismos del Sector Público.

Los equipos que lo hacen bien lo incorporan en la «definición de «hecho»»:

• Todos los componentes nuevos se han probado con un lector de pantalla (NVDA + Chrome, VoiceOver + Safari).
• Antes de aprobar una solicitud de incorporación de cambios, se comprueba la navegación mediante el teclado.
• El contraste de colores se comprueba en la fase de diseño, no en la de desarrollo.

// 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. La integración continua y la entrega continua (CI/CD) no son opcionales en los proyectos públicos

Los servicios públicos tienen algunos de los requisitos más estrictos en materia de gestión del cambio que existen. Paradójicamente, esa es una razón para invertir fuertemente en automatización, no para actuar con rapidez, sino para demostrar que cada cambio es seguro.

En el marco de nuestra colaboración con el DfT, creamos un proceso que garantizaba:

# 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

La auditoría de accesibilidad fue un requisito imprescindible. Un escaneo de Axe que dio resultado negativo bloqueó el lanzamiento. No se admitieron excepciones ni modificaciones sin una aceptación documentada del riesgo por parte del responsable del producto.

4. La higuera estranguladora para la modernización del legado

Todos los departamentos gubernamentales tienen en algún lugar un sistema mainframe con 20 años de antigüedad. El modelo de la «higuera estranguladora» —que consiste en desviar gradualmente el tráfico hacia un nuevo servicio sin dejar de mantener activo el sistema heredado— es la forma más segura de modernizarse sin necesidad de una reescritura radical que ponga en riesgo los servicios públicos.

La clave está en crear una capa de enrutamiento desde el principio:

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

Puntos clave

• La investigación sobre los usuarios no es una fase — es una actividad continua que se entrelaza con la entrega
• La accesibilidad es arquitectura — diseñarlo, probarlo y controlarlo
• Automatizar todo lo que sea auditable — si una máquina puede comprobarlo, debería hacerlo
• Acabar con lo tradicional — No reescribas, redirige

La prestación de servicios digitales por parte de la Administración es complicada. Pero cuando funciona, el impacto es enorme: millones de personas interactúan con servicios que realmente les prestan ayuda. Por eso merece la pena hacerlo bien.