Idea principal

La cadena habitual de diseño de interfaz va en un sentido: se dibuja una pantalla en Figma y luego un desarrollador front-end la reimplementa. La maqueta es una representación — muestra lo que se quiere obtener, y nada de lo que contiene es directamente reutilizable.

El estatus cambia cuando el design system se reconstruye desde el repositorio en lugar de mantenerse al lado: componentes realmente existentes, estados realmente gestionados, convenciones de desarrollo del equipo, actualizaciones a medida que el repositorio evoluciona. La maqueta ya no expresa una intención en un vocabulario ajeno al código, compone elementos que existen. Lo que produce se convierte en una primera base que el desarrollo puede retomar.

El desplazamiento afecta a la posición en la cadena, no a la herramienta. Figma sigue siendo excelente para diseñar pantallas; lo que se mueve es lo que su salida vale aguas abajo.

Por qué es importante

Es el caso más demostrativo de la inversión: el diseño es la etapa que se cree más alejada del código, ya que lo precede. Mostrar que también puede alimentarse del repositorio indica que la frontera entre diseño, implementación y documentación se reduce por los dos extremos.

También desplaza el punto de atención de un equipo de diseño: mantener la correspondencia entre el design system y el código se vuelve más decisivo que la calidad del dibujo en sí.

Matices y límites

Un design system derivado del código encierra el diseño en lo existente. Vuelve fluida la composición de pantallas a partir de lo que ya está implementado y hostil a lo que aún no existe — exactamente allí donde el diseño tiene más valor.

Y la reconstrucción solo es útil si se mantiene: un design system derivado una vez y luego dejado en su sitio vuelve a ser una representación, con un retraso adicional respecto a una maqueta asumida como tal.

Preguntas abiertas

• ¿Cómo conserva un diseño que parte de lo existente la capacidad de proponer lo que el producto aún no sabe hacer?