Una App y dos sitio web conectados por componentes reutilizables
Cuando el gobierno necesitaba 3 productos digitales en 3 meses sin ninguna base existente, la única respuesta viable no era un diseño — era un sistema.
En enero de 2017, la SFP (Secretaría de la Función Pública) de México, llegó con un encargo inusual para una dependencia de gobierno: diseñar dos sitios web y una app móvil desde cero, en tres meses.
En papel parecía un problema de recursos. En la práctica era algo más profundo. Tres equipos distintos diseñarían simultáneamente, en tres contextos de producto diferentes, sin componentes compartidos, sin un sistema de marca digital existente y sin tiempo para construir uno antes de entregar.
La restricción real no era el calendario. Era que ninguno de los tres productos podía esperar a los otros.
El brief tenía dos dimensiones ocultas: tres equipos diseñando simultáneamente, y un requisito de consistencia que hacía imposibles las decisiones ad hoc. Lo que el proyecto realmente necesitaba no era un diseñador — era un arquitecto de sistemas.
El instinto al construir un design system es terminarlo antes de empezar los productos. Definir cada token, documentar cada componente, acordar cada regla, y después entregarlo.
Ese instinto habría matado el proyecto. Tres meses no dejaban espacio para el pensamiento secuencial. El sistema tenía que construirse junto con los productos que lo usarían, con el uso real de cada equipo determinando qué se documentaba a continuación.
Ya había visto esta tensión en Scotiabank. La lección allá fue la misma: un design system no termina antes del primer producto. Co-evoluciona con él. En el momento en que reformulé esto como infraestructura en lugar de entregable, todo el enfoque cambió.
Esto implicó que debía de entender mi ley de pareto: que era ese 20% de componentes que me daría ese 80% de adopción. necesitaba un enfoque leean que arrancara solo con los componentes necesarios y de ahi ir iterano.
Lo que se entregó no fue un sistema perfecto. Fue el sistema correcto para estos tres productos en este momento, y esa distinción resultó importar más que la perfección.
Antes de diseñar un solo componente, necesitaba entender qué tipo de productos eran realmente esos tres. El benchmarking no era sobre inspiración visual — era sobre identificar los patrones de interacción que necesitarían escalar. El insight que surgió: los tres productos eran fundamentalmente experiencias de formularios de múltiples pasos. Esa única observación lo definió todo.
No un sistema completo en Figma. Un conjunto mínimo de componentes — botones, campos de formulario, modales, steppers — inyectados directamente en los tres productos reales. Los componentes se definieron con contexto completo: no solo qué son, sino cuándo usarlos, por qué y qué variaciones existen. El uso real reveló brechas que el diseño hipotético nunca habría expuesto.
Tres equipos diseñando simultáneamente desde la misma fuente de verdad. Cuando un equipo quería una nueva variante de componente, debía documentarse y añadirse al sistema — sin decisiones ad hoc. La restricción parecía fricción al principio. En la tercera semana, era la forma más rápida de tomar decisiones: "¿El sistema ya tiene esto? Si no, ¿debería?"
El benchmarking aquí no era sobre encontrar inspiración visual. Era sobre entender cómo otros sistemas habían resuelto el mismo desafío de fondo: formularios y recolección de datos a escala, con un amplio rango de sofisticación del usuario.
Cada referencia aportó algo específico — no un estilo a copiar, sino una decisión de diseño que entender lo suficientemente bien como para adoptarla o rechazarla de manera deliberada.
Sistemas de grilla sólidos, jerarquía tipográfica contundente y cero decoración. Un servicio de gobierno no necesita ser hermoso — necesita ser inequívoco para usuarios con baja alfabetización digital.
La lección no fue el lenguaje visual de Material — fue la forma tan sistemática en que documentaba los estados de los componentes: vacío, activo, relleno, deshabilitado, error, validado. Los formularios se ganan o se pierden por la claridad de los estados.
Cada componente estaba documentado no solo visualmente sino funcionalmente: control, trigger, menú, contexto. Un design system que los desarrolladores no pueden implementar con precisión es solo una guía de estilo.
La decisión de marca fue deliberada: reusar en lugar de reinventar. La SFP ya tenía una paleta de colores (el esquema oficial de gob.mx) y un logotipo. En lugar de rediseñar la identidad, la extendí — añadiendo tipografía y formalizando el sistema de tokens digitales.
Montserrat para encabezados, Roboto para texto de cuerpo. Ambas de código abierto, ambas ya en uso en las propiedades digitales del gobierno mexicano. Esto eliminó una decisión sin sacrificar calidad.
La mayoría de la documentación de componentes responde una pregunta: ¿qué es esto? El sistema Publik fue documentado para responder tres: qué es, cuándo se usa y cuáles son todos los estados en que puede estar. Esa tercera pregunta — los estados — es donde la mayoría de los equipos perdía consistencia en la práctica.
Cuando un desarrollador conoce explícitamente cada estado válido, no hay espacio para la interpretación. La decisión de diseño ya está tomada. Los desacuerdos sobre "cómo debería verse esto en el estado de error" no ocurren porque la especificación ya tiene esa respuesta.
Desde el inicio hubo un patrón que se fue voviendo más obvio: Denuncia Ciudadana recopila reportes. Trabaja En recopila solicitudes. Denuncia Paisano recopila denuncias anónimas. Los tres productos eran, en su núcleo, máquinas de recolección de información. Las diferencias superficiales, eporte cívico vs. búsqueda de empleo vs. anonimato móvil, eran reales, pero no cambiaban el modelo de interacción subyacente.
El patrón se hizo obvio al mirar los productos desde abajo, desde el nivel de componente hacia arriba; en lugar de desde el brief hacia abajo.
La consecuencia práctica fue significativa: optimizar los componentes de formulario una vez significaba optimizar los tres productos simultáneamente. Un mejor patrón de validación de campos de texto mejoró Denuncia Ciudadana, Trabaja En y Denuncia Paisano en un solo cambio. Así es como se ve el apalancamiento de un sistema en la práctica.
Si el sistema se hubiera diseñado de arriba hacia abajo, desde una especificación "completa" imaginada, este patrón quizá nunca se habría visto. Construir reveló lo que el brief habría mostrado.
La prueba real de un design system no es cómo se ve en una librería — es si los mismos componentes pueden responder problemas de diseño diferentes sin necesitar ser reconstruidos. Estos tres productos lo demostraron.
Un sitio web para que los ciudadanos reporten corrupción e irregularidades administrativas de funcionarios de gobierno. El desafío central de UX fue un formulario de 5 pasos — uno de los flujos de mayor fricción para diseñar bien.
El componente stepper del sistema y los campos de formulario validados hicieron el trabajo estructural. El desafío de diseño pasó de "cómo construimos este formulario" a "cómo reducimos la carga cognitiva en cinco pasos progresivos".
Una plataforma de búsqueda de empleo para oportunidades en el gobierno. Dos flujos de usuario distintos — búsqueda y descubrimiento para candidatos, y una ruta de registro para postulantes — requerían que los mismos componentes respondieran modos de interacción muy diferentes.
La búsqueda usó botones, dropdowns y componentes de lista de resultados. El registro usó los mismos campos de formulario que Denuncia Ciudadana, con modales para los estados de confirmación. Los mismos componentes, una composición completamente distinta.
Una app móvil para que los ciudadanos reporten abuso de autoridad de forma anónima, con capacidad de geolocalización. Las restricciones del móvil requirieron adaptar cada componente a targets táctiles — áreas de toque más grandes, espaciado más generoso, steppers simplificados — pero la lógica de los componentes no cambió.
El hecho de que el móvil usara los mismos componentes conceptuales que los dos productos web fue la validación más clara del sistema: las mismas decisiones estructurales escalaron entre tamaños de pantalla sin requerir un proceso de diseño paralelo.
"Un design system no termina con del primer producto.
Co-evoluciona con él ."
Los stakeholders de la SFP reportaron un aumento del 20% en las tasas de completación de formularios comparado con las versiones anteriores. Pero la métrica cuantitativa subestima lo que realmente cambió.
Los tres productos parecían venir de la misma familia, No porque fueran visualmente idénticos, no lo eran, sino porque compartían la misma lógica estructural, las mismas decisiones de componentes y los mismos patrones de interacción. Los usuarios que se movían entre productos y no tenían que reaprender nada.
Antes del sistema, las conversaciones entre diseñadores, POs y desarrolladores requerían traducción constante — "el botón azul en Denuncia" versus "la acción primaria en Trabaja". Después del sistema, el vocabulario era compartido. Las decisiones fueron más rápidas porque la referencia era clara.
Tres productos en tres meses versus un estimado de nueve meses trabajando secuencialmente sin un sistema. El diseño dejó de ser un cuello de botella y se convirtió en un acelerador.
Los product owners tuvieron un nuevo tipo de pregunta que podían hacer: "¿Deberíamos usar el componente Modal existente aquí, o este caso necesita algo nuevo?" Esa pregunta, es la pregunta correcta. Sin un sistema, nunca pasaria hace.
Las brechas de Publik son brechas que importan, y nombrarlas con precisión vale más que enterrarlas.
La presión de tiempo es real. Tres meses para tres productos es genuinamente ajustado. Pero "no tuvimos tiempo" es solo la mitad de la explicación, la otra mitad es entender qué costó en esa priorización, para que la próxima vez el tradeoff se haga conscientemente.
Sin pruebas de navegación por teclado. Sin auditoría de contraste de color. Sin etiquetas ARIA integradas en los componentes. En un producto comercial esto es un descuido serio. En un producto de gobierno, la accesibilidad no es legalmente requerida en México, deber{ia ser una aspiración para volverse un ejemplo aseguir. La accesibilidad debió haber sido una restricción de diseño desde el día uno, no un elemento para la "próxima versión".
El design system vivía en Figma. Los desarrolladores de para la App Denuncia Paisano ya tenían un estandar, pero ninguna librería en react o algun framework web. lounico que se logro fue una librería básica de utilidades CSS. Un track paralelo de web components habría cerrado la brecha entre la especificación y la implementación.
La mejora del 20% en completación de formularios se midió contra las versiones anteriores, no contra pruebas de usuario del nuevo sistema. Nunca probamos si los ciudadanos entendían el stepper, encontraban claros los mensajes de error o se sentían seguros enviando reportes anónimos. Las métricas de negocio confirmaron la dirección, pero no validaron el diseño.
Publik se ubica de manera diferente a otros proyectos en mi portafolio porque la métrica de éxito era distinta. En un proyecto de producto, el éxito se mide por el outcome que queremos generar en el usuario. En un proyecto de sistema, el éxito se mide por si otras personas pueden construir productos más rápido y con mayor coherencia.
El trabajo del design system era no ser notado. Cuando los equipos diseñan desde un sistema compartido y los productos se sienten consistentes, los usuarios no ven el sistema, ven tres servicios de gobierno coherentes. Esa invisibilidad es el objetivo. También es por qué el trabajo de sistemas es difícil de explicar: el caso de éxito es la ausencia de problemas visibles.
Accesibilidad desde el día uno, no en una versión futura. Un track paralelo de librería CSS. Ambas cosas se sienten como "deseable tenerlas" bajo presión de tiempo, y ambas son un error postergar en un contexto de gobierno. La próxima vez que construya un sistema para una institución pública, esos dos elementos son alcance no negociable, no alcance condicional.
Un design system en una startup es sobre reutilización de componentes. En una organización grande como Scotiabank, es sobre consistencia entre equipos dispersos. En gobierno — en Publik — era sobre algo más: la capacidad de escalar servicios públicos sin multiplicar el esfuerzo de diseño proporcionalmente. Entender qué tipo de sistema estás construyendo cambia cada decisión, desde qué priorizar primero hasta cómo medir si funcionó.
Publik no fue un sistema hermoso. Fue un sistema capaz. Para tres productos en tres meses para una dependencia de gobierno sin ninguna base de diseño digital, la capacidad era el objetivo correcto.