--- title: "Un design system es una lista de decisiones" description: "Un sistema de diseño se sostiene sobre decisiones acordadas y sobre quién puede cambiarlas, no sobre el número de componentes que tiene el catálogo." canonical: https://caricalia.com/notas/design-system-no-es-una-libreria last-updated: 2026-09-08 --- # Un design system es una lista de decisiones > Los sistemas de diseño montados como catálogo se abandonan al año. Lo que aguanta es el acuerdo sobre qué se decide y quién lo cambia. Publicado: 2026-09-08 Autor: carlos Temas: diseño, sistema de diseño, producto --- ## Qué contiene de verdad un sistema de diseño Un sistema de diseño es el conjunto de decisiones que tu producto ya no vuelve a discutir, más el acuerdo sobre quién puede cambiarlas. Los componentes son el sitio donde esas decisiones quedan escritas en código. Las decisiones son cosas como cuántos tamaños de texto existen y para qué sirve cada uno. Qué significa exactamente el color de aviso. Qué se ve cuando una tabla no tiene datos. Cómo se llama la acción que borra algo. Cada una se responde una vez y se escribe. Si un sistema de diseño tiene muchas piezas dibujadas y ninguna línea que explique cuándo se usa cada una, lo que hay es un catálogo de imágenes ordenado. ## Cómo se nota la diferencia al año Se nota en el número de componentes que hacen casi lo mismo. Cuando el sistema solo es catálogo, cada equipo que necesita algo que no está se fabrica su versión y sigue. Con el tiempo hay varios botones de peligro con rojos distintos, varias formas de pedir confirmación y un calendario por producto. Nadie ha hecho nada mal: no había ninguna regla que dijera qué hacer cuando la pieza no existe. Brad Frost describe ese punto en [A Design System Governance Process](https://bradfrost.com/blog/post/a-design-system-governance-process/): si quien usa el sistema no puede hacer lo que necesita hacer, el sistema entero corre riesgo de quedarse obsoleto. Frost propone un procedimiento explícito para los casos en que el componente no existe o solo sirve a medias. Es de 2019. El segundo síntoma tarda más en aparecer y cuesta más. Los diseños dejan de parecerse al producto. Se aprueban pantallas en un fichero de diseño, se construyen aproximadamente, y como la diferencia es pequeña cada vez, nadie la corrige. Con el tiempo, lo que se enseña a un cliente y lo que ese cliente encuentra al entrar dejan de parecerse. ## Qué pasa cuando diseño y desarrollo son departamentos Las decisiones se toman dos veces, y la segunda gana. En el reparto habitual, diseño entrega un fichero con las pantallas y desarrollo lo construye. Pero un fichero de diseño no dice qué se ve cuando la carga tarda seis segundos, ni qué aparece si el usuario no tiene permiso, ni cómo se comporta la tabla con un nombre de cliente muy largo. Esas decisiones se toman igualmente, y las toma quien está escribiendo el código. El estado de error y el estado vacío son buena parte de la experiencia real de un producto de trabajo. El otro coste es la ida y vuelta. Diseño propone algo que por dentro cuesta semanas y nadie lo dice hasta la revisión. Ingeniería resuelve por su cuenta un caso raro de una forma que rompe una regla que sí estaba acordada. ## Cómo lo hacemos aquí Quien diseña una pantalla construye su componente, dentro del mismo equipo y sobre el mismo material desde el primer día. Cómo funciona el proceso por dentro y cómo lo vive quien lo usa se definen a la vez, en un solo documento, no en dos ficheros que se sincronizan después y acaban divergiendo. De ahí salen dos condiciones que van en el contrato. Una pantalla no se aprueba por correo sobre imágenes: se aprueba con el cliente haciendo clic en una maqueta navegable. Y las pantallas se entregan construidas, en el mismo repositorio que el resto, así que lo que se aprueba en la maqueta es lo que se despliega. Eso explica por qué el [wireframe](/glosario/wireframe) aquí dura días y no semanas. No hace falta perfeccionar un dibujo cuando la aprobación de verdad ocurre sobre algo que se puede tocar. ## Cuándo montar un sistema de diseño, y cuándo no Depende del número de personas que van a tomar decisiones sobre la interfaz sin hablar entre ellas. Con una persona diseñando y otra construyendo, un sistema formal es sobrecoste. Lo que hace falta es un puñado de decisiones escritas donde ambas las vean. En cuanto hay dos equipos trabajando en paralelo sobre el mismo producto, el sistema se paga solo: el coste de que cada equipo invente su versión sube por encima del de mantenerlo. Y si el producto tiene varios años y nadie sabe cuántos estilos de botón hay dentro, lo primero es contar lo que ya existe. Ese recuento es lo que cambia la conversación: la lista escrita de los estilos que ya existen ordena la discusión mejor que un argumento sobre consistencia. ## Qué preguntar antes de encargarlo Pregunta quién va a poder cambiar una decisión del sistema, y qué tiene que hacer para cambiarla. Si no hay respuesta, lo que te van a entregar es un catálogo sin mantenimiento. Pregunta qué pasa cuando un equipo necesita algo que no está. Ese caso aparece pronto. Y pregunta si lo entregado incluye los estados incómodos: error, vacío, sin permisos, carga lenta. Un sistema que solo cubre el camino feliz deja fuera un presupuesto que aparece después. Separar qué parte de una interfaz descosida es de diseño y qué parte viene de cómo está construido por dentro es de las primeras cosas que hace [un diagnóstico](/diagnostico). Cómo trabajamos está en [diseño de producto](/marca-y-producto).