Organización con campus y aplicaciones propias
Cada una con su botón, su formulario y su tabla, resueltos de nuevo cada vez.
Ingeniería y calidad
Sistema de diseño para productos EdTech
Este sistema comparte componentes, variables de diseño, patrones de producto y pruebas visuales entre varias aplicaciones.
El problema
Cuando cada equipo resuelve desde cero la interfaz, la accesibilidad y los patrones complejos de su producto, la velocidad inicial se paga con inconsistencias, errores y mantenimiento duplicado.
Un sistema de diseño también fija cómo se resuelven tareas educativas recurrentes.
La navegación, el progreso, la evaluación, los estados vacíos, los errores y la accesibilidad se repiten en productos distintos. Documentarlos como patrones reduce las decisiones locales y permite que diseño e ingeniería compartan el mismo contrato.
Decisión principal
Empezar por los patrones de producto compartidos.
Diseño los componentes a partir de recorridos reales: encontrar una actividad, entregar una evidencia, conocer un estado o recuperarse de un error. Incorporo después las variables de diseño y las variantes necesarias para mantener ese comportamiento de forma coherente.
Criterios de diseño
- 01
Centralizo las decisiones estables y permito variaciones entre productos mediante variables y composición.
- 02
Ejecuto comprobaciones iniciales de interacción y accesibilidad dentro del sistema de diseño. Quedan por fijar la versión de WCAG, el nivel de conformidad y las pruebas que deberá superar cada componente.
- 03
La biblioteca incluye patrones completos de aplicación, además de componentes visuales básicos.
Límites del producto
Cada producto conserva las variaciones que exige su contexto.
Una aplicación de consulta, una de gestión y una de creación de contenido tienen densidades y responsabilidades diferentes. El sistema comparte fundamentos y permite variaciones justificadas, en lugar de forzar una única interfaz para cualquier tarea.
Capacidades del sistema
- 01Catálogo de componentes reutilizables
- 02Variables y temas de producto
- 03Patrones para presentar datos y flujos operativos
- 04Storybook y pruebas de interacción
Criterio de validación
La adopción se comprueba cuando varios productos utilizan el sistema.
Para evaluarla, reviso la accesibilidad, los estados, la documentación, las pruebas visuales y el coste de integración. También observo cuándo un equipo evita el componente, porque esa fricción suele revelar que el patrón o su contrato necesitan corregirse.
Evidencia descrita para el sistema de diseño para productos EdTech
- Paquete compartido en uso
- Pruebas automatizadas de componentes e interacción
- Pensado para que aplicaciones con interfaces distintas compartan el mismo contrato de componentes
Preguntas abiertas
Decisiones pendientes en el sistema de diseño para productos EdTech.
El sistema solo debe crecer después de acordar cómo se gobiernan las contribuciones y se publican las versiones. También hay que fijar la versión de WCAG y el nivel de conformidad, los criterios aplicables y las pruebas manuales y automatizadas que debe superar cada componente.
- Gobierno de contribuciones
- Estrategia de versiones
- Umbrales y criterios de accesibilidad
- Límites entre sistema y producto
Contextos en los que encaja
Quién tiene varias aplicaciones y una sola marca
La incoherencia visual cuesta tiempo en cada pantalla nueva, mucho antes de que alguien se queje del aspecto.
Equipos que trabajan en paralelo
Dos personas resolviendo el mismo componente a la vez y de dos maneras distintas.
Accesibilidad exigible
Cada equipo tiene que resolver por su cuenta el contraste, el foco y la navegación por teclado.
Cambio de identidad visual
Y hay que perseguir el color por cuatro aplicaciones y ochenta pantallas.
Decisiones de arquitectura
Las decisiones que lleva dentro
Un sistema de diseño vale por lo que evita repetir, no por lo bonito que sea.
- 01
La accesibilidad empieza en el componente
El sistema incorpora desde el componente el contraste, el foco visible y la navegación por teclado. La conformidad se verifica también en los patrones, las pantallas, el contenido y los recorridos completos, con la versión de WCAG, el nivel y las pruebas manuales y automatizadas acordadas.
- 02
Variables antes que valores
Los colores y las medidas que representan decisiones compartidas se definen como variables del sistema; las excepciones propias de una pantalla quedan acotadas y documentadas.
- 03
Componentes con su caso de uso
Cada pieza documenta para qué sirve y cuándo no usarla. Sin eso, el catálogo crece con variantes difíciles de distinguir.
- 04
Pruebas visuales automáticas
Un cambio se comprueba antes de publicarse en las historias, estados, pantallas y navegadores incluidos en la suite; la cobertura y sus huecos quedan registrados.
A escala
Qué cambia con el número de aplicaciones
- Una aplicación
Puede bastar un fichero de estilos bien organizado; la decisión depende del número de patrones, del equipo y de la frecuencia de cambio.
- Dos o tres productos
Puede empezar a compensar, sobre todo si comparten equipo o identidad visual.
- Varios equipos en paralelo
Hace falta un contrato común de componentes y patrones. Según el número de productos, las dependencias y el modelo de gobierno, la organización puede adoptar un sistema de diseño completo o una biblioteca más acotada con normas compartidas.
Capacidades puestas en práctica
Patrones compartidos que reducen decisiones repetidas entre productos
Este sistema muestra cómo convierto los recorridos, la accesibilidad y los estados recurrentes en componentes que varios productos pueden adoptar y someter a prueba.
- 01Sistemas de diseño
- 02Accesibilidad
- 03Pruebas de interacción
- 04Gobierno y adopción
Contexto profesional