Storybook es una herramienta de documentación visual que permite construir, visualizar y compartir componentes de interfaz dentro de un sistema de diseño. Si trabajas con HTML, CSS y JavaScript y buscas una fuente de verdad para tu equipo, esta guía te muestra qué encontrarás en el curso y por qué Storybook se volvió pieza clave del front-end moderno.

Por qué Storybook importa en un sistema de diseño

Un design system no vive solo en Figma ni solo en código: vive en la conversación entre diseño y desarrollo. Y ahí es donde Storybook se vuelve protagonista.

Cuando construyes componentes reutilizables, necesitas un lugar donde el resto del equipo pueda verlos, inspeccionarlos y confirmar que ya están listos para usarse. Ese lugar es Storybook. Imagina que terminas un botón con sus estilos y variantes; al publicarlo, cualquier persona del equipo puede entrar y decir este botón ya existe, lo puedo reutilizar.

¿Qué es Storybook? Es una herramienta de documentación visual para componentes de UI. Te permite construirlos con CSS y JavaScript, visualizarlos aislados y compartirlos como referencia oficial del equipo.

La profe Stephanie Aguilar, senior front-end developer, lo explica desde el inicio del curso [0:00]: Storybook funciona como un librito de cuentos donde cada componente tiene su historia, sus variantes y sus escenarios.

Qué conocimientos previos necesitas para tomar el curso

Antes de abrir Storybook, conviene tener bases sólidas en front-end. No se trata de saberlo todo, pero sí de moverte con comodidad en componentes y estilos.

Estos son los temas que se asumen como base [7:30]:

• Crear componentes con JavaScript y manipular el DOM.
• Estilizar con CSS usando metodología BEM.
• Entender container queries para diseño responsivo a nivel de contenedor.
• Tener nociones básicas de testing.

Si alguno te falta, no te frenes. En la lectura siguiente del curso encontrarás enlaces para nutrirte antes de avanzar.

Cómo se conecta Storybook con Figma

Este curso es la continuación natural del curso de Sistemas de diseño con Figma, donde se construyeron los fundamentos visuales y los primeros componentes [1:30]. Ahí se definió qué es un design system, quiénes participan y cómo fluye el proceso entre equipos.

Conocer lo que hace diseño te vuelve un desarrollador integral. No eres una isla: nutres tu trabajo entendiendo el de otros.

Qué fundamentos y componentes vas a desarrollar

El proyecto parte de un Figma ya construido con dos pantallas: una de foundations y otra de componentes [4:50]. Esos archivos son la fuente de verdad que vas a traducir a código.

Los fundamentos cubren cuatro áreas clave del sistema:

• Tipografías con tamaños estándar de 40, 32, 18 y 16 píxeles.
• Colores definidos como tokens que luego pasarás a custom properties de CSS.
• Espaciados consistentes para mobile y desktop.
• Elevación mediante shadows que generan jerarquía en el eje Z.

¿Qué son los tokens de diseño? Son variables que guardan decisiones visuales como colores, tamaños o espaciados. En código se traducen a custom properties para mantener coherencia en todo el sitio.

Después de los fundamentos, llegan los componentes. En el curso se desarrollan dos: el botón y la card.

Qué arquitectura siguen los componentes

Cada componente trae una arquitectura definida desde diseño que tú debes respetar al programarlo [6:20]. El botón se construye con tres dimensiones: tamaño, estilo y estado. La card maneja tamaño y estado.

La idea es que al cambiar la arquitectura desde el código, las variantes se actualicen solas. Así garantizas que lo que ve el usuario coincida exactamente con lo que diseñó el equipo.

Y aquí viene un spoiler: para la card vas a usar container queries, una técnica de CSS que permite a un componente adaptarse según el tamaño de su contenedor, no del viewport. Eso le da independencia y la hace verdaderamente reutilizable.

Cómo Storybook se convierte en la fuente de verdad del equipo

Cuando diseño te entrega una pantalla con hero, cards y footer, tu primer reflejo debería ser abrir Storybook. Si los componentes están ahí, están listos para usarse.

¿Por qué Storybook se llama fuente de verdad? Porque centraliza los componentes ya aprobados, sus variantes y sus escenarios. Si está documentado en Storybook, está listo para producción.

Dentro de la herramienta puedes inspeccionar cada componente, probar sus variantes, simular escenarios mobile y desktop, y validar comportamientos. Eso reduce duplicación de código y errores de comunicación entre diseño y desarrollo.

El trabajo colaborativo es el corazón del design system: no son solo desarrolladores ni solo diseñadores, es un equipo que comparte un lenguaje visual y técnico.

¿Ya tienes claro qué componente quieres documentar primero en tu propio Storybook? Cuéntame en los comentarios cuál sería tu punto de partida.