Es extraño cómo los sistemas de diseño son tan rutinarios y, sin embargo, tan difíciles

Los sistemas de diseño para la UI de software se consideran ampliamente necesarios para la coherencia y la escala, pero muchos equipos descubren que son sorprendentemente difíciles de definir, construir y adoptar eficazmente. Los comentarios destacan problemas recurrentes: una alineación vaga sobre qué es un sistema de diseño, la sobreoptimización para la flexibilidad futura, tratarlo como un artefacto estático en lugar de un proceso evolutivo respaldado por código, y la política organizativa y la gobernanza necesarias para mantenerlo utilizable. Algunos ven valor cuando los sistemas están liderados por equipos experimentados e interdisciplinarios y se aplican con “opiniones firmes, pero poco arraigadas”, mientras que otros sostienen que, para muchas empresas, se convierten en una carga burocrática y poco utilizada que incluso puede limitar un buen diseño de producto.

Qué es (y qué no es) un sistema de diseño

  • Muchos distinguen entre:
    • Lenguaje de diseño (estilo visual, marca, reglas)
    • Sistema de diseño (implementación reutilizable y estándares para gestionar la UI a escala)
    • Bibliotecas de componentes (código de UI)
  • Algunos sostienen que un sistema de diseño es un proceso (“diseñar de forma sistemática”) más que un artefacto fijo.
  • Otros critican las definiciones vagas y de alto nivel y lo ven de forma más concreta como reglas sobre apariencia, contenido y componentes.

Por qué los sistemas de diseño son difíciles

  • El problema central: las personas y la alineación, no las herramientas. Los equipos a menudo discrepan sobre qué es un sistema de diseño, qué problemas resuelve y cómo aporta valor.
  • Compromiso clásico: optimizar para la flexibilidad → demasiado complejo, inflado; optimizar para la velocidad → arrepentimiento y reescrituras más adelante.
  • Los productos nuevos se topan inevitablemente con casos que el sistema no cubre, lo que crea excepciones y extensiones ad hoc.
  • La gobernanza y el mantenimiento son más difíciles que la creación inicial; los sistemas nunca están “terminados”.

Proceso, gobernanza y adopción

  • La adopción falla cuando: los diseños no coinciden con el sistema, los colaboradores no leen o no confían en la documentación, o la documentación queda obsoleta.
  • Algunos informan que los modelos de “devolver contribuciones” rara vez funcionan; un equipo pequeño, sénior y cohesionado suele producir mejores sistemas.
  • Los sistemas excesivamente rígidos pueden volverse burocráticos, sofocar la creatividad y usarse como un instrumento contundente para rechazar diseños contextualmente mejores.
  • Otros ven la restricción y la uniformidad precisamente como el objetivo, especialmente en múltiples productos.

Perspectivas de diseño frente a ingeniería

  • Tanto diseñadores como ingenieros reconocen que están redescubriendo problemas similares de diseño de sistemas (diseño de API, microservicios, cuadrículas, branding).
  • Tensión sobre si el código o los archivos de diseño son la verdadera “fuente de verdad”; varios sostienen que los componentes ya desplegados deben ser la prioridad.
  • Algunos diseñadores resienten los sistemas como símbolos de “worse is better” y del ahorro de costes por encima de hacer “lo correcto”.

Herramientas y enfoques de implementación

  • Se elogia Figma por variantes/variables, pero se considera fundamentalmente tradicional.
  • Tailwind es alabado por algunos como “la mayor parte de las ventajas con pocas desventajas”, pero otros dicen que solo es un framework de CSS, no un sistema de diseño.
  • Se recomiendan encarecidamente primitivas robustas y centradas en accesibilidad (por ejemplo, equivalentes a Radix/React-Aria) en lugar de reinventar widgets básicos.
  • Integrar sistemas en productos heredados se describe como especialmente doloroso.

Cuándo conviene tener un sistema de diseño

  • Algunos ven los sistemas de diseño como algo esencial solo para organizaciones grandes o varios productos activos; en equipos pequeños pueden ser un “org smell”.
  • El éxito parece requerir talento sénior, responsabilidad interdisciplinaria (diseño/ingeniería/producto), valores predeterminados accesibles y cambio cultural.