UI kit: qué es y cuándo basta con uno

¿Qué es un UI kit y qué no es?

Un UI kit es, en la práctica, el paquete visual de un producto: los componentes dibujados, con sus estilos base y algunas variantes, listos para arrastrarse a un archivo de diseño. Muchas plantillas y kits que se venden o se descargan funcionan así.

Conviene separar tres términos que se confunden:

• UI kit: el conjunto visual de componentes. Responde a la pregunta “¿cómo se ve esto?”.
• Librería de componentes: un conjunto de componentes reutilizables, en diseño o en código, que el equipo comparte. Figma la describe como una colección de activos (componentes, variables y estilos) que se comparten para reutilizarlos.
• Design system: el conjunto completo de estándares, criterios de uso, documentación y componentes. Nielsen Norman Group lo define como un conjunto completo de estándares para gestionar el diseño a escala, con componentes y patrones reutilizables.

Las fuentes citadas al final definen “design system” y “librería”, pero no “UI kit”: la distinción de arriba es una síntesis práctica de esta wiki, no una cita. Lo que sí dicen es que el design system incluye las reglas de uso, no solo los componentes. El sistema de diseño explica esa parte con más detalle.

¿Por qué le importa a un diseñador junior?

Porque es probablemente el primer artefacto de sistema que vas a tocar. Un equipo pequeño empieza con un archivo de Figma que tiene botones, campos y una paleta. Si ese archivo está bien hecho, ahorra horas. Si está mal hecho, todas las pantallas empiezan a divergir.

Nielsen Norman Group advierte que un design system mal implementado y mantenido puede convertirse en una colección inmanejable de componentes y código. Un UI kit mal organizado puede hacer lo mismo a menor escala. Por eso importa entender cuándo basta con el kit y cuándo ya necesitas más.

¿Qué debe incluir un UI kit para ser útil?

1. Estilos base: colores, tipografía y espaciado, idealmente como variables o tokens y no como valores sueltos.
2. Componentes con estados: cada botón con sus estados (normal, al pasar el cursor, pulsado, desactivado) y cada campo con su error y su ayuda.
3. Variantes controladas: pocas, bien nombradas. Si cada botón tiene decenas de variantes, el archivo se vuelve difícil de usar. La explosión de variantes es el problema típico.
4. Pantallas de ejemplo: al menos una pantalla que use los componentes en contexto. Sin ella, nadie sabe cómo deben combinarse.
5. Una nota de uso: dos o tres frases por componente que digan cuándo usarlo y cuándo no.

Figma recomienda separar las librerías de los archivos donde se diseña, para tener un archivo que sea la fuente de verdad y no se mezcle con trabajo ajeno. Publicar una librería exige acceso de edición al archivo y está disponible en los planes Professional, Education, Organization, Government y Enterprise; en el plan gratuito Starter se pueden crear componentes y estilos, pero no publicarlos como librería.

¿Cuándo basta con un UI kit?

• El producto es pequeño y lo diseña y lo mantiene un equipo de dos o tres personas.
• La interfaz no cambia cada semana. Si los componentes casi no cambian, no hay mucho que sincronizar.
• El trabajo es un proyecto puntual, como una landing o un prototipo para validar una idea.
• No hay un equipo de frontend que implemente los componentes. En ese caso, el kit es una referencia visual, no una fuente de código.

Nielsen Norman Group señala que mantener un design system es una actividad que consume tiempo y requiere un equipo dedicado. Si no puedes asegurar eso, un UI kit bien cuidado vale más que un design system a medio hacer.

¿Cuándo NO basta con un UI kit?

• Cuando varios equipos usan los mismos componentes. Sin reglas compartidas, cada equipo modifica el suyo.
• Cuando el código y el diseño tienen que coincidir. Un archivo de Figma no garantiza que el componente en código se comporte igual. Storybook, descrito como un directorio interactivo de componentes y sus historias, sirve para esa parte.
• Cuando la accesibilidad debe documentarse por componente. Los estados de foco y los contrastes necesitan reglas, no solo dibujos.

En estos casos, el kit es el punto de partida, no el destino. Para la capa de código, revisa Storybook y la página sobre Atomic Design, que describe cómo se organizan los componentes por niveles de complejidad.

Ejemplo

Ejemplo ilustrativo: una app de reservas de 12 pantallas, diseñada por dos personas.

• Qué tienen: un archivo de Figma con 14 componentes (botones, campos, tarjetas, navegación), 3 estilos de texto y 6 colores, más una pantalla de ejemplo por flujo principal.
• Qué no tienen: reglas escritas, documentación de estados de error ni una implementación en código.
• Decisión: el UI kit es suficiente mientras el producto esté en fase de validación. Cuando un tercer equipo empiece a usar los componentes, se decide si pasar a un design system.

Esa decisión se revisa cada trimestre. Una señal posible para cambiar: que alguien pregunte “¿qué botón uso?” varias veces por semana.

El diseño asistido por IA también afecta esta decisión. Si quieres saber cómo los agentes leen un sistema de componentes, revisa el artículo sobre diseño de sistema legible por IA.

Errores comunes

• Llamar “design system” a un archivo con botones y colores, sin reglas ni documentación.
• Crear decenas de variantes en vez de componentes bien nombrados.
• Dibujar cada pantalla sin componentes, lo que hace imposible cambiar un color en todo el producto.
• Mezclar el archivo de componentes con los archivos de trabajo, sin separar la librería.
• Crear un kit completo antes de tener las pantallas que lo necesitan.

Fuentes

• Nielsen Norman Group, Design Systems 101
• Figma, Components collection: Library fundamentals
• Figma, Publish a library
• Brad Frost, Atomic Design, Chapter 2
• Storybook, Why Storybook?