Tema 3.2 — Sistemas de diseño y prototipado

Un sistema de diseño convierte las buenas decisiones de diseño en infraestructura compartida y reutilizable —de modo que la accesibilidad, la seguridad clínica y la consistencia se incorporan una vez y se heredan en todas partes, en lugar de volver a discutirse y volver a romperse en cada pantalla.

Por qué esto importa en la salud y la atención#

En la salud y la atención, la interfaz a menudo son los últimos centímetros entre una decisión clínica y un paciente. Un campo de medicación confuso, un selector de fecha inaccesible, un botón que significa "cancelar cita" en un servicio y "cancelar y perder tus datos" en otro —estos no son problemas cosméticos. Son problemas de seguridad del paciente, problemas de equidad, y problemas de confianza. Cuando cada equipo diseña sus propios componentes desde cero, los defectos se multiplican y las garantías de seguridad se vuelven imposibles de razonar a través de una cartera.

Un sistema de diseño es cómo dejas de pagar por los mismos errores repetidamente. Cuando un componente accesible y bien probado se construye una vez y se reutiliza en docenas de servicios, arreglas un defecto de accesibilidad o una ambigüedad de seguridad en un lugar y cada servicio hereda la corrección. La alternativa —interfaces a medida en todas partes— significa calidad desconocida y desigual: algunos servicios cumplen con las Pautas de Accesibilidad para el Contenido Web (WCAG) y algunos silenciosamente excluyen a las mismas personas que más dependen de los servicios públicos de salud.

La consistencia también es una cuestión de comprensión. Los pacientes y el personal se mueven entre servicios —una aplicación del Servicio Nacional de Salud (NHS), un portal ambulatorio de un fideicomiso, una herramienta de reservas de una consulta general— y cada patrón desconocido impone carga cognitiva. En una población que incluye a personas que están enfermas, ansiosas, mayores, digitalmente excluidas, o usando tecnología de asistencia, esa carga no se distribuye uniformemente. Los patrones compartidos la reducen para todos. Este tema trata sobre la maquinaria —componentes, patrones, tokens, prototipos, y operaciones de diseño— que hace que el diseño seguro, accesible y consistente sea el camino de menor resistencia en lugar de un acto de heroísmo.

Conceptos clave#

Un sistema de diseño es una única fuente de verdad para los componentes, patrones, estilos y orientación reutilizables usados para construir un conjunto de servicios digitales. Es más que una guía de estilo: empareja componentes funcionales y codificados con el razonamiento de diseño, las notas de accesibilidad y la orientación de uso que te dicen cuándo y cómo usar cada uno. Los dos ejemplos públicos más relevantes son el sistema de diseño del NHS (mantenido por NHS England, construido sobre el front-end de NHS.UK) y el GOV.UK Design System, mantenido por el Government Digital Service (GDS). Ambos son abiertos, de libre acceso, y probados en batalla a través de millones de interacciones.

Una biblioteca de componentes contiene los bloques de construcción discretos —botones, entradas de formulario, encabezados, resúmenes de errores— mientras que una biblioteca de patrones contiene las soluciones de orden superior a problemas recurrentes: cómo pedir una fecha de nacimiento, cómo estructurar una página de preguntas, cómo reportar un error, cómo pedir a un usuario su número de NHS. Los componentes son el vocabulario; los patrones son las oraciones. Ambos se basan en la ingeniería de software basada en componentes, donde los sistemas se ensamblan a partir de partes reutilizables, débilmente acopladas e independientemente comprobables.

Los tokens de diseño son las decisiones compartidas más pequeñas expresadas como variables nombradas —un color, una unidad de espaciado, un tamaño de fuente, un contorno de estado de foco. Porque los tokens se referencian por nombre en lugar de codificarse directamente, un cambio a un token (digamos, aumentar el tamaño mínimo del objetivo táctil o el contraste) se propaga consistentemente a cada componente que lo usa. Los tokens son el mecanismo que mantiene un sistema coherente a medida que escala, y que hace posible tematizar un sistema compartido para uso local sin bifurcarlo.

Una única fuente de verdad es la idea rectora: cada decisión de diseño se domina en exactamente un lugar, para que no pueda desincronizarse entre servicios. Cuando el diseño, el código y la orientación de un componente viven todos en una biblioteca autorizada única, eliminas la clase de errores donde la imagen y el producto no coinciden.

El prototipado de software es la práctica de construir versiones deliberadamente incompletas de un servicio para aprender algo antes de comprometerte a construir la cosa real. Los prototipos van de baja fidelidad (bocetos en papel, wireframes en escala de grises) a alta fidelidad (interactivos, realistas, a menudo construidos en código). El principio de GDS es prototipar para aprender, no para conservar: el trabajo de un prototipo es responder una pregunta a través de pruebas de usabilidad con usuarios reales, después de lo cual se desecha —esto es prototipado desechable (o "rápido"), distinto de un prototipo evolutivo que pretendes endurecer hacia producción.

DesignOps (operaciones de diseño) es la disciplina de operar el diseño a escala —las personas, flujos de trabajo, gobernanza, modelo de contribución y herramientas que mantienen un sistema de diseño compartido saludable, financiado y confiable a través de una organización o sistema de atención integrada (ICS). Es al diseño lo que la ingeniería de plataforma es al código: mayormente invisible cuando funciona, dolorosamente obvio cuando no. El prototipado se hace en herramientas de diseño como Figma o directamente en código usando el front-end de un sistema de diseño, lo que nos lleva al desarrollo web front-end —la capa de HTML, CSS y JavaScript donde la reutilización realmente reduce la duplicación, el coste y el riesgo.

Este tema deliberadamente no vuelve a cubrir qué necesitan los usuarios (véase el Tema 3.0 — Investigación de usuarios y diseño de servicios) o cómo se escriben las palabras (véase el Tema 3.1 — Diseño de contenidos y alfabetización en salud). Esas disciplinas alimentan el sistema de diseño; este tema trata sobre la maquinaria reutilizable que lleva sus conclusiones de forma segura a producción.

Buenas prácticas#

1. Adoptar antes de construir. Comienza desde el sistema de diseño del NHS y el GOV.UK Design System en lugar de inventar el tuyo propio. Ya codifican años de pruebas de accesibilidad, diseño de contenido, y uso en el mundo real a través de servicios de salud y gobierno. Reinventar un selector de fecha o un resumen de errores no es un buen uso de la capacidad escasa y costosa de diseño e ingeniería, y una versión casera casi siempre será menos accesible. Extiende y tematiza estos sistemas para necesidades locales; no los bifurques sin una razón deliberada y documentada.

2. Incorporar la accesibilidad y la seguridad clínica en los componentes compartidos, no en las pantallas individuales. Todo el caso económico y de seguridad para un sistema de diseño es que arreglas algo una vez y lo heredas en todas partes. Un componente de fecha de nacimiento accesible, navegable por teclado, probado con lector de pantalla, construido y asegurado una vez, protege cada servicio que lo usa. Incorpora la conformidad con WCAG, el manejo sensato de errores, y los comportamientos relevantes para la seguridad (confirmación clara de acciones destructivas, unidades no ambiguas para dosis y medidas) en el componente mismo, para que los equipos no puedan fácilmente equivocarse (véase el Tema 1.9 — Inclusión digital y accesibilidad, y el Tema 1.6 — Seguridad clínica y gestión de riesgos).

3. Prototipar para aprender, no para conservar. Trata los prototipos como experimentos desechables que responden una pregunta específica —"¿puede un paciente con baja alfabetización en salud completar esta derivación?"— de forma barata y rápida. Ajusta la fidelidad a la pregunta: usa bocetos de baja fidelidad para probar el flujo y la comprensión temprano, y prototipos codificados de alta fidelidad para probar la interacción realista, la accesibilidad, y los casos límite más tarde. Resiste la atracción de promover un prototipo directamente a producción; el código de prototipo optimizado para velocidad de aprendizaje rara vez es lo suficientemente seguro, protegido, o mantenible para un servicio clínico en vivo.

4. Prototipar en el front-end real cuando la interacción y la accesibilidad son la pregunta. Los prototipos en herramientas de diseño (Figma y similares) son excelentes para explorar el diseño, el flujo, y el contenido rápida y colaborativamente. Pero no pueden probar fielmente la navegación por teclado, el comportamiento del lector de pantalla, la gestión del foco, o el rendimiento en hardware antiguo del patrimonio del NHS. Cuando esos son los riesgos, prototipa en código usando el front-end del sistema de diseño, para que estés probando algo cercano a lo que los usuarios reales realmente experimentarán con tecnología de asistencia real.

5. Probar los prototipos con usuarios reales antes de construir. Un prototipo que nunca se pone frente a usuarios representativos es solo una opinión costosa. Prueba con personas que reflejen tu población real —incluyendo personas mayores, personas con discapacidades, personas con baja confianza digital, y personal trabajando bajo presión de tiempo. Incluso cinco participantes sacarán a la luz la mayoría de los problemas graves de usabilidad y comprensión, y encontrarlos en un prototipo es órdenes de magnitud más barato que encontrarlos en producción (véase el Tema 3.7 — Pruebas y aseguramiento de la calidad).

6. Gestionar los tokens como el contrato para la consistencia. Expresa colores, espaciado, tipografía, y estados de interacción como tokens de diseño nombrados, y trata los cambios a ellos con la seriedad de un cambio de dependencia compartida. Los tokens te permiten hacer cumplir el contraste mínimo, el tamaño del objetivo táctil, y la visibilidad del foco en todo el sistema, y permiten que un equipo local vuelva a tematizar para su marca sin romper las garantías de accesibilidad subyacentes. Cuando cambia un estándar nacional, quieres cambiar un token, no auditar diez mil pantallas.

7. Ejecutar un modelo de contribución, no un jardín amurallado. Un sistema de diseño que solo acepta aportes de un equipo central siempre irá por detrás de las necesidades reales del servicio y será resentido por los equipos de entrega. Publica una ruta clara para que los equipos propongan nuevos componentes y patrones, con criterios sobre qué se acepta, quién lo revisa, y cómo se aseguran la accesibilidad y la seguridad antes de que algo se promueva a la biblioteca compartida. Este es trabajo central de DesignOps: equilibra la tensión entre la flexibilidad local y la consistencia compartida sin dejar que el sistema se pudra o se fragmente.

8. Versionar, documentar y comunicar los cambios. Trata el sistema de diseño como un producto con usuarios (tus equipos de entrega), una hoja de ruta, notas de versión, y un canal de soporte. El versionado semántico, los registros de cambios, y los avisos claros de obsolescencia permiten a los equipos adoptar mejoras de forma segura y en su propio calendario. Los cambios disruptivos no documentados destruyen la confianza que hace que los equipos elijan el sistema compartido en lugar de construir el suyo propio.

9. Medir la adopción y la calidad, no solo la existencia. Un sistema de diseño entrega valor solo cuando se usa. Rastrea qué servicios usan los componentes compartidos, dónde los equipos han tenido que construir alternativas a medida (y por qué), y si la conformidad de accesibilidad mejora a medida que aumenta la adopción. Las altas tasas de soluciones alternativas locales son una señal de que al sistema le falta algo real —trátalas como backlog, no como desobediencia.

Preguntas para debatir con tu equipo#

1. ¿Dónde debería situarse la línea entre la consistencia compartida y la flexibilidad local, y quién decide? Esta es la tensión de gobernanza central de cualquier sistema de diseño. Demasiado rígido, y los equipos de entrega se sienten bloqueados, construyen componentes en la sombra, y evitan el sistema —fragmentando la misma consistencia que intentabas proteger. Demasiado laxo, y el "sistema" se convierte en un montón de elementos individuales vagamente relacionados sin garantías compartidas de seguridad o accesibilidad. En un contexto de salud y atención las consecuencias son específicas: alguna variación es legítima (un servicio de crisis de salud mental tiene necesidades genuinamente diferentes a las de un sistema de reserva de citas rutinario), mientras que alguna variación es peligrosa (formas inconsistentes de confirmar una acción clínica destructiva). Una buena respuesta nombra cuáles decisiones son no negociables (accesibilidad, patrones críticos para la seguridad, comportamientos de interacción centrales) y cuáles están abiertas a tematización local, y define un proceso explícito y humano para que un equipo solicite una excepción o contribuya un nuevo patrón en lugar de simplemente prohibir la divergencia.

2. ¿Cómo se asegurarán realmente la accesibilidad y la seguridad clínica dentro de nuestros componentes —y quién lo aprueba? Es fácil afirmar que la accesibilidad y la seguridad están "incorporadas"; es difícil garantizarlo. Esta pregunta te obliga a ser concreto sobre el pipeline de aseguramiento: quién prueba cada componente frente a WCAG, con qué tecnologías de asistencia, y con qué usuarios discapacitados; cómo se revisan los comportamientos relevantes para la seguridad frente a tu proceso de seguridad clínica (DCB0129/DCB0160); y qué evidencia se adjunta a un componente antes de que se publique como "seguro para reutilizar". El debate debería sacar a la luz brechas honestas —quizás tienes verificaciones automatizadas de contraste pero nunca has probado con un usuario real de lector de pantalla, o tu Oficial de Seguridad Clínica nunca ha revisado la biblioteca de componentes compartida. Una respuesta sólida produce un propietario nombrado, un régimen de pruebas definido, y una regla de que ningún componente entra en la biblioteca compartida sin evidencia documentada de accesibilidad y seguridad, porque un defecto heredado por cincuenta servicios es cincuenta veces el daño.

3. ¿Quién financia, dota de personal, y mantiene el sistema de diseño una vez que se desvanece el entusiasmo inicial? Los sistemas de diseño frecuentemente se crean en un estallido de energía y luego se abandonan silenciosamente cuando el equipo fundador se muda a otra cosa, dejando una biblioteca obsoleta en la que los equipos ya no confían. Esta es fundamentalmente una pregunta de DesignOps y financiación, no una pregunta de diseño. Debate honestamente si tienes un equipo permanente y financiado responsable del sistema como un producto continuo —con capacidad para soporte, revisión de contribuciones, versionado, y mantener el ritmo con los sistemas ascendentes del NHS y GOV.UK— o si estás confiando en buena voluntad que se evaporará. En un ICS esto es aún más agudo: ¿el sistema es propiedad de una organización dominante, gobernado conjuntamente, o huérfano entre ellas? Una buena respuesta trata el sistema de diseño como infraestructura de larga duración con un propietario nombrado, un presupuesto continuo, y una relación clara con los sistemas nacionales sobre los que se construye, en lugar de un proyecto que "termina".

4. ¿Cuál es nuestra relación con los sistemas ascendentes del NHS y GOV.UK —y cómo mantendremos el ritmo con ellos a medida que cambian? Adoptar un sistema de diseño nacional no es una descarga única; es una dependencia continua de infraestructura que no controlas. Esta pregunta te obliga a decidir, deliberadamente, dónde te sitúas en el espectro desde "tematizar ligeramente y seguir de cerca lo ascendente" hasta "bifurcar y divergir". Cada elección tiene un coste: permanecer cerca significa absorber cambios ascendentes (una nueva corrección de accesibilidad, un patrón revisado) según el calendario de otra persona y ocasionalmente reelaborar personalizaciones locales; bifurcar significa que posees cada futura corrección de accesibilidad y seguridad que el equipo nacional de otro modo te habría dado gratis. En la salud y la atención la atracción de divergir es real —los flujos de trabajo clínicos y la marca local crean presión genuina— pero cada divergencia es una responsabilidad permanente. Una buena respuesta nombra quién vigila las notas de versión ascendentes, cómo se estructuran las extensiones locales para que sobrevivan a una actualización ascendente, y la prueba explícita que una divergencia propuesta debe pasar antes de permitirse, para que "necesitábamos que se viera diferente" nunca se convierta silenciosamente en "ahora mantenemos una bifurcación obsoleta y menos accesible del selector de fecha del NHS".

5. ¿Cómo mantendremos realmente la línea entre "prototipar para aprender" y "construir para conservar"? Todos están de acuerdo en principio en que los prototipos desechables no deberían convertirse en servicios de producción; el fallo sucede bajo presión de plazo, cuando un prototipo convincente de alta fidelidad está ahí mismo y lanzarlo parece un atajo. Esta pregunta hace que el límite sea concreto en lugar de aspiracional. Debate qué prácticamente evita que el código de prototipo —optimizado para velocidad de aprendizaje, no para seguridad, resiliencia, o mantenibilidad— se promueva a un servicio clínico en vivo: ¿es una separación técnica (prototipos construidos en un entorno aislado que no puede llegar a producción), una puerta de gobernanza (sin aprobación de seguridad clínica, sin puesta en marcha), o meramente una buena intención compartida que se evapora la primera vez que se retrasa una fecha de entrega? Las consecuencias de la salud y la atención son específicas, porque el código no asegurado en una vía clínica es una exposición de seguridad del paciente, no solo deuda técnica. Una respuesta honesta admite de dónde vendrá la presión, nombra quién está empoderado para decir que no, y define qué requiere realmente "reconstruir para producción a partir de componentes asegurados" para que el límite se mantenga cuando se pone a prueba.

6. ¿Cómo sabremos si el sistema de diseño realmente está funcionando —y qué haremos cuando las métricas sean incómodas? Un sistema de diseño puede existir, estar bellamente documentado, y aun así entregar poco valor si los equipos silenciosamente lo evitan. Esta pregunta va más allá de "tenemos un sistema de diseño" hasta "se está ganando su lugar". Decide qué medirás: adopción a través de servicios, la tasa y razones de las soluciones alternativas a medida, si la conformidad de accesibilidad realmente mejora a medida que aumenta la adopción, y cuánto tiempo ahorran los equipos al reutilizar en lugar de reconstruir. La parte difícil no es recopilar los números sino acordar de antemano cómo los leerás —porque una alta tasa de soluciones alternativas locales es una señal de que al sistema compartido le falta algo real, no evidencia de que los equipos de entrega están siendo desobedientes. Una buena respuesta se compromete a tratar los datos de adopción incómodos como entrada de backlog y hoja de ruta, define quién los revisa y con qué frecuencia, y resiste la tentación de medir solo lo halagador (existencia, número de descargas) en lugar de lo que importa (servicios más seguros, más accesibles, más consistentes realmente entregados).

En la práctica: un ejemplo de salud y atención#

Un sistema de atención integrada que cubre tres fideicomisos de agudos, un fideicomiso de salud mental, y un proveedor comunitario decide consolidar su patrimonio digital orientado al paciente. Hoy cada organización opera su propio portal ambulatorio; entre ellos tienen cuatro selectores de fecha incompatibles, tres formas diferentes de pedir un número de NHS, y una conformidad de accesibilidad enormemente variable. Una auditoría interna encuentra que solo uno de los cuatro portales pasa una prueba básica de lector de pantalla de su flujo de reserva de citas —una clara exposición de equidad y seguridad clínica.

El ICS establece un pequeño equipo de sistema de diseño financiado conjuntamente. En lugar de construir desde cero, adoptan el sistema de diseño del NHS como su base y definen una capa local delgada de tokens de diseño para la marca específica del ICS, más un puñado de patrones genuinamente locales (por ejemplo, un patrón compartido para reservar apoyo de intérprete, que ninguno de los sistemas nacionales cubre). Cada componente compartido lleva evidencia documentada de WCAG y una aprobación del Oficial de Seguridad Clínica del ICS bajo el proceso DCB0129 antes de publicarse.

Antes de reconstruir el flujo de reserva ambulatoria, el equipo prototipa. Comienzan con baja fidelidad, probando una versión en papel y escala de grises del nuevo flujo con doce participantes reclutados para reflejar la población local —incluyendo dos usuarios de lector de pantalla, tres personas mayores de 75 años, y varios con baja confianza digital. El prototipo expone un problema serio de comprensión: los pacientes no pueden distinguir una acción de "reprogramar" de una acción de "cancelar". El equipo arregla el patrón, luego construye un prototipo codificado de alta fidelidad usando el front-end del sistema de diseño y vuelve a probar, esta vez confirmando el comportamiento del teclado y el lector de pantalla en el hardware real usado en las clínicas ambulatorias de un fideicomiso asociado.

Solo entonces construyen de verdad, ensamblando el servicio de producción en gran parte a partir de componentes asegurados y reutilizables. Dieciocho meses después, una actualización de WCAG endurece los requisitos de visibilidad del foco. Porque el estilo de foco vive en un único token de diseño, el equipo lanza un cambio y cada servicio del ICS lo hereda en la siguiente versión —una corrección que, bajo el antiguo patrimonio fragmentado, habría significado cinco proyectos de remediación separados y, realísticamente, al menos un servicio quedaría roto.

Perspectivas sectoriales#

Startup#

Una pequeña startup de salud digital casi nunca debería construir su propio sistema de diseño desde cero —no puede permitirse la sobrecarga de pruebas de accesibilidad, y los inversores están pagando por validación clínica, no botones a medida. Adopta el front-end del NHS o GOV.UK donde estás construyendo para usuarios del NHS, y trata el prototipado como tu ventaja competitiva central: prototipos baratos, rápidos, desechables probados con pacientes reales te permiten aprender más rápido que competidores mejor financiados. El riesgo es el opuesto —promover un prototipo elegante de alta fidelidad directamente a producción para cumplir con una demostración para inversores, llevando código no asegurado e inseguro a un servicio clínico en vivo. Mantén una línea dura entre "prototipar para aprender" y "construir para conservar", incluso bajo presión de financiación.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o una clínica de un solo emplazamiento comisionando una herramienta orientada al paciente— tiene pacientes en vivo pero ninguna capacidad de diseño o front-end dedicada, y no puede absorber el coste de componentes a medida. Su movimiento más poderoso es insistir en que cualquier proveedor construya sobre el front-end del NHS o GOV.UK, para que las garantías de accesibilidad y seguridad vengan heredadas en lugar de prometidas, y hacer de eso una condición escrita del contrato en lugar de una esperanza. Rara vez necesita operar su propio sistema de diseño; necesita consumir uno bien, y reconocer que la demostración elegante de un proveedor no es evidencia de un servicio en vivo accesible y asegurado. Donde sí prototipa —probando un nuevo flujo de reserva en línea con sus pacientes reales, a menudo mayores o menos confiados digitalmente— unas pocas sesiones con usuarios reales captarán mucho más de lo que una maqueta pulida jamás revelará. Aplican los mismos deberes estatutarios de accesibilidad y seguridad clínica que a un gran fideicomiso, así que la pregunta honesta no es si cumplir sino cómo obtener el cumplimiento heredado de forma económica de la infraestructura nacional compartida.

Gran organización#

Un gran fideicomiso del NHS o una empresa de tecnología de salud ya tiene múltiples equipos construyendo interfaces superpuestas, así que su problema es la fragmentación y el coste duplicado. El caso de valor es un equipo de sistema de diseño financiado y permanente ejecutando un modelo de contribución real, con métricas de adopción reportadas al liderazgo y una línea de gobernanza clara hacia la seguridad clínica y el aseguramiento de accesibilidad. La tensión central es política: los equipos de entrega poderosos se resisten a ceder control, y un equipo central de mano dura genera componentes en la sombra. Las grandes organizaciones tienen éxito haciendo que el sistema compartido sea la elección genuinamente más fácil —bien documentado, bien soportado, y demostrablemente de mayor calidad— en lugar de exigirlo y esperar.

Gobierno#

Un organismo nacional como NHS England o GDS opera el sistema de diseño como infraestructura pública usada por organizaciones que no controla, así que la apertura, la estabilidad, y la compatibilidad hacia atrás importan enormemente. Sus obligaciones son las más fuertes: regulaciones estatutarias de accesibilidad, deberes de igualdad, y la realidad de que un defecto en un componente nacional compartido se propaga a millones de ciudadanos. El trabajo trata menos de invención y más de administración —versionado claro, política de obsolescencia, evidencia exhaustiva de accesibilidad, y capacidad de respuesta a los cientos de equipos aguas abajo. El sistema de diseño del NHS y el GOV.UK Design System son los ejemplos de referencia precisamente porque tratan el sistema como un bien público de larga duración, no un proyecto.

Modos de fallo comunes#

• El sistema abandonado. Un sistema de diseño se construye con fanfarria, luego se deja sin mantener cuando el equipo fundador se dispersa; los equipos pierden confianza y vuelven a la deriva hacia el trabajo a medida. Evítalo financiando un equipo de producto permanente, no un proyecto único.
• La imagen que miente. Los archivos de diseño y el código de producción no coinciden porque no hay una única fuente de verdad, así que "el sistema de diseño" describe algo que el producto ya no hace. Mantén los componentes codificados y su documentación autorizados y versionados juntos.
• Accesibilidad como idea de último momento. Los componentes se lanzan sin pruebas reales de tecnología de asistencia, así que un patrón inaccesible se hereda en todas partes —multiplicando, no reduciendo, el daño. Exige evidencia documentada de WCAG y lector de pantalla antes de que se publique cualquier componente.
• Prototipo a producción. Un prototipo de alta fidelidad se promueve directamente a un servicio en vivo para ahorrar tiempo, llevando código inseguro, no mantenible, no asegurado a un entorno clínico. Haz cumplir el límite desechable; reconstruye para producción a partir de componentes asegurados.
• El jardín amurallado. Un equipo central rechaza todas las contribuciones, así que el sistema nunca satisface las necesidades reales del servicio y los equipos de entrega lo evitan. Publica un proceso de contribución y excepción y trata las soluciones alternativas locales como señal de backlog.
• Teatro de consistencia. Se hace cumplir una uniformidad rígida donde se justifica una variación local genuina (servicios de crisis, pediatría), degradando la seguridad y la usabilidad en nombre del orden. Distingue las decisiones no negociables de las legítimamente locales.
• Probar la fidelidad equivocada. Los riesgos de interacción y accesibilidad se "prueban" solo en una herramienta de diseño estática que no puede ejercer el comportamiento del teclado o el lector de pantalla, dando una falsa confianza. Prototipa en código cuando la interacción es la pregunta.

Modelo de madurez#

Lista de verificación#

• Has adoptado el sistema de diseño del NHS y/o el GOV.UK Design System como tu base en lugar de construir desde cero.
• Los componentes compartidos llevan evidencia documentada de conformidad WCAG, probada con tecnología de asistencia real y usuarios discapacitados.
• Los componentes relevantes para la seguridad han sido revisados bajo tu proceso de seguridad clínica antes de publicarse para reutilización.
• Los tokens de diseño gobiernan el color, el espaciado, la tipografía, y los estados de interacción, habilitando cambios en todo el sistema desde un lugar.
• Existe una única fuente de verdad donde los componentes codificados y su orientación viven y se versionan juntos.
• Los prototipos se ajustan en fidelidad a la pregunta, se prueban con una muestra representativa de usuarios, y se tratan como desechables.
• Los flujos críticos de interacción y accesibilidad se prototipan en código, no solo en una herramienta de diseño.
• Un equipo financiado y nombrado posee el sistema de diseño como un producto continuo, con una hoja de ruta y un canal de soporte.
• Un proceso publicado de contribución y excepción permite a los equipos de entrega proponer nuevos componentes y patrones.
• La adopción y la calidad se miden, y las altas tasas de solución alternativa local se tratan como backlog, no desobediencia.

Fuentes clave#

• Sistema de diseño del NHS — NHS England: componentes, patrones, estilos, y orientación de accesibilidad para servicios digitales del NHS.
• GOV.UK Design System — Government Digital Service: estilos, componentes, y patrones para servicios del gobierno del Reino Unido.
• Manual de Servicio de GOV.UK — prototipado y "hacer un prototipo" — Government Digital Service: orientación sobre prototipar para aprender y probar con usuarios.
• NHS Digital Service Standard — NHS England: el estándar frente al cual se evalúan los servicios compartidos y consistentes.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: el estándar de conformidad de accesibilidad.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — gobierno del Reino Unido: el deber estatutario de accesibilidad para servicios del sector público.
• Estándares de gestión de riesgo clínico DCB0129 / DCB0160 — NHS England: estándares de seguridad clínica para la fabricación y despliegue de sistemas de TI de salud.
• Double Diamond del Design Council — Design Council: el modelo descubrir–definir–desarrollar–entregar que sustenta el descubrimiento y el diseño.

Referencias#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards