El siguiente artículo se ofrece únicamente con fines informativos y no pretende proporcionar, ni debe considerarse, asesoramiento legal o financiero. Consulte a sus propios asesores legales o contables si tiene preguntas sobre este tema.

En Flex, somos un equipo de ingeniería pequeño conocido por rendir muy por encima de nuestro peso, con una gran propensión a la acción. Después de unos años de rápidos cambios de producto y giros estratégicos, habíamos acumulado una deuda de UX significativa que empezó a mostrar una experiencia poco fluida. 

Todavía necesitábamos lanzar rápidamente, pero con un estándar de calidad mucho más alto y un entendimiento común de lo que realmente significaba "calidad". Sin embargo, cuando se me propuso la idea de crear un sistema de diseño, me entró un ligero pánico.

Habiendo construido dos sistemas de diseño anteriormente, conocía los escollos que pueden implicar: trabajo personalizado innecesario, discusiones triviales, documentación desactualizada, etc. No teníamos el tiempo ni los recursos para enredarnos en la carga que los sistemas de diseño pueden conllevar. 

La Petición

La pregunta rápidamente fue: "¿Cómo podemos implementar un sistema de diseño 'ligero', uno que aporte valor sin ralentizarnos?"

Lo primero que tuvimos que hacer fue evaluar lo que implicaba un sistema de diseño integral frente al sistema ligero que pretendíamos construir.

Sistemas de Diseño Normales e Integrales

• Componentes personalizados (botones, modales, tablas, etc.)
• Herramientas personalizadas (configuraciones de Storybook, infraestructura interna)
• Procesos/gobernanza para los cambios
• Altos costes de mantenimiento

Sistemas de Diseño Ligeros

• Solo los componentes y patrones más utilizados
• Fácil de adoptar: la documentación y el código residen donde los desarrolladores ya trabajan
• Aprovecha las bibliotecas existentes en lugar de construir desde cero (cuando sea posible)
• Tiene estándares para mostrar su uso

Nuestras Limitaciones: Equipo pequeño, grandes objetivos.

Empezamos con una serie elegante de diseños que abarcaban desde componentes a nivel atómico (botones, campos de entrada, etc.) hasta diseños comunes y flujos de varios pasos. 

Durante todo este proceso, hicimos todo lo posible para no crear ningún componente nuevo a menos que fuera absolutamente necesario. Aprovechar nuestras herramientas elegidas era imperativo. Somos una empresa pequeña que entrega una gran cantidad de trabajo cada semana; lo último que necesitábamos era enredarnos en minucias sobre problemas personalizados derivados de componentes personalizados.

Aunque las inconsistencias visuales eran evidentes, un problema más profundo que había notado en Flex era la falta de un enfoque unificado para construir interfaces de usuario comunes, como los formularios. Podías ir al código base y encontrar cinco formas diferentes en que estábamos implementando las interfaces de usuario de los formularios. Estaba claro que necesitábamos una serie de estándares.

Creación de una serie de estándares unificados

Anteriormente habíamos empezado a trabajar en una sección de 'guía rápida' para que los desarrolladores tuvieran una colección de mejores prácticas para copiar/pegar. Este se convirtió en el lugar perfecto para mostrar nuestro sistema de diseño emergente. Podríamos usar esta área (más tarde renombrada como “Playground”) para permitir a los desarrolladores ver y usar estos estándares para nuestras interfaces de usuario más comunes y así acelerar su trabajo, y también permitir a los diseñadores ver que lo que construyeron es realmente lo que se está utilizando. Finalmente, tener esto incrustado en nuestra propia aplicación web (en lugar de externamente, a través de una plataforma como Storybook) ayudó a asegurar su uso.

Sin embargo, la historia acababa de empezar. Teníamos un par de dragones que matar primero:

1. Estábamos anclados a una versión anterior de nuestra biblioteca de UI elegida y sería un esfuerzo bastante hercúleo actualizarla. Este cambio abarcaría la totalidad tanto de nuestra aplicación de cara al cliente como de nuestra herramienta interna, Alfred.
2. Necesitábamos combinar repositorios para co-localizar nuestras aplicaciones internas y web para asegurar el uso del sistema de diseño entre aplicaciones.

Después de completar esos hitos, rediseñamos ambas aplicaciones para que coincidieran con los nuevos diseños y el impulso empezó a crecer.

Multiplicadores de fuerza

Al rediseñar nuestra herramienta interna, Alfred, y la aplicación web, empezamos a crear una serie de mejores prácticas en Playground. Con el tiempo, Playground contuvo el “80/20” de nuestros casos de uso — un centro integral para componentes, diseños y utilidades compartidas.

‍

‍

Aunque sabíamos que Playground sería beneficioso para que los desarrolladores copiaran/pegaran componentes y aceleraran su trabajo, esta colección de estándares resultó ser perfecta para que los LLM entendieran cómo se debía generar el código de la interfaz de usuario.

Presentamos: Cursor

Poco después de que empezamos a construir Playground, nuestro equipo de frontend empezó a usar Cursor AI. Nuestro Playground de referencia de reglas de Cursor fue creado para usarlo como punto de partida al generar cualquier código basado en UI:

• Para ver ejemplos de cómo usar los componentes de nuestro sistema de diseño, consulta el Playground en `src/areas/playground`.
• Al implementar nuevos componentes como Drawers, Tables, Wizards, Layouts, etc., copia el archivo tal como está implementado en el Playground y úsalo como punto de partida en el área en la que estés trabajando.
• La mayoría de las veces no actualizarás ningún archivo en `src/areas/playground`, sino que simplemente usarás los componentes de allí como puntos de partida para copiarlos en nuevas carpetas en `src/areas`.

Nuestro esfuerzo previo de re-tematización resultó muy beneficioso aquí, ya que allanó el camino para que Cursor construyera interfaces de usuario consistentes con nuestro sistema de diseño sin tener que consultar ninguna guía de estilo.

Para profundizar en «lo que significa la calidad frontend en Flex», codificamos los estándares que habíamos acordado previamente como equipo de UI. Cursor hace referencia a esto, además de a las reglas de Playground, para que el LLM entienda no solo lo que debe construirse, sino cómo construirlo en conjunto con nuestras diversas herramientas y convenciones. Aquí hay un fragmento de cómo hacemos referencia a nuestra biblioteca de UI actual, Mantine, desde nuestro archivo de reglas de Cursor:

• Usa Mantine como tu biblioteca base de componentes React.
• Aprovecha al máximo la biblioteca Mantine, incluyendo componentes de `@mantine/core`, hooks de `@mantine/hooks`, formularios con `@mantine/form`.
• Para los componentes, siempre intenta usar primero los componentes de nuestras carpetas `components/core` o `components/composites`; de lo contrario, usa los componentes principales de Mantine siempre que sea posible.
• Evita usar estilos en línea o clases; primero, siempre intenta usar las props de Mantine para estilizar colores y colores de fondo, espaciado y tamaños, etc.
• Para los colores, usa siempre nuestros colores de tema de Mantine (es decir, `theme.colors.yourColorHere[index]`).
• Para el espaciado y los tamaños, usa la función `rem()` de Mantine en lugar de valores en píxeles o numéricos, es decir, `gap={rem(12)}`

Resultados de Flex

Usar la IA junto con nuestro sistema de diseño ha cambiado las reglas del juego en todos los aspectos para crear y mantener un estándar más alto de velocidad y calidad. ¡Nuestra reciente función de Cuentas por Cobrar se construyó completamente en tres semanas! 

Asimismo, utilizar Playground como una sólida colección de componentes y patrones ha reforzado nuestro estándar de calidad, tanto para desarrolladores como para LLMs. Al buscar un enfoque más ligero para construir un sistema de diseño, hemos podido evitar las numerosas trampas a menudo asociadas con los sistemas de diseño, preservando al mismo tiempo las ventajas de la consistencia y la dirección.

Recientemente, hemos utilizado Playground como un recurso educativo para mostrar cómo los desarrolladores pueden usar alternativas a una herramienta de gestión de estado que estamos intentando desaprobar activamente. En un futuro próximo, nuestro objetivo es adjuntar nuestros estándares de Playground a nuestra compilación de CI para asegurar aún más su adopción.

Lecciones para otros equipos

Si estás en una etapa temprana, esto es lo que recomendamos:

• Empieza poco a poco: Enfócate en tus componentes de UI más utilizados
• Evita el trabajo personalizado: La mayoría de las bibliotecas de componentes de UI modernas se pueden utilizar para impulsar tu iniciativa de sistema de diseño. Reserva el trabajo personalizado para componentes y flujos de trabajo más complejos
• Define claramente qué es "bueno": Asegúrate de que tu equipo tenga un conjunto de estándares acordados en torno a las herramientas de UI y las convenciones de codificación para que puedas codificarlos con herramientas de IA
• Hazlo evidente para tu equipo: Integra tu sistema de diseño en el producto para ayudar a asegurar que se utilice
• Hazlo accesible para los LLM: Asegúrate de que tus herramientas de IA puedan referenciar fácilmente tu sistema de diseño y tus estándares para asegurar la alineación antes de generar código

Consideraciones finales

Probablemente no necesitas un sistema de diseño personalizado o completo. Necesitas uno útil.

En Flex, nuestro sistema de diseño se ha convertido en un multiplicador en ingeniería, producto y diseño. Nos ha ayudado a avanzar más rápido con un estándar de calidad mucho más alto.

Para equipos en fase inicial que apuestan por la velocidad y las herramientas de IA, esta podría ser una de las inversiones en infraestructura más inteligentes que puedes hacer.

‍