¿Hacen solo el diseño o también implementan?

Ambos, y en nuestro caso es difícil separarlos: entregamos el design system en código, con los componentes funcionando. Si tu equipo implementa, recibe los componentes y la documentación, lo que evita la clásica pérdida entre la imagen aprobada y la pantalla publicada.

¿Necesito cambiar toda mi identidad visual?

Casi nunca. Lo habitual es que la marca esté bien y falte el sistema alrededor: escala tipográfica, paleta con contraste verificado, espaciado consistente, estados de componente. Un rediseño completo de marca es otro proyecto, y decimos cuándo no hace falta.

¿La accesibilidad encarece el proyecto?

Hecha desde el inicio, casi no pesa: es elegir colores con contraste adecuado, marcar el HTML correctamente y probar navegación por teclado. Lo caro es adaptarla después, cuando el componente ya está repartido en treinta pantallas.

Web design que sobrevive al handoff

Design system con identidad propia, componentes accesibles y microinteracciones sobrias. Trabajamos en equipo con tu producto o nos hacemos cargo del ciclo completo.

El diseño lindo que se vuelve pantalla fea en producción casi nunca es culpa de quien programó. Es síntoma de diseño entregado como imagen: cada estado que nadie dibujó — campo con error, lista vacía, nombre demasiado largo, conexión lenta — termina decidido a las apuradas por otra persona.

Trabajamos con design system en código desde el principio. Lo que aprobás es lo que va a producción, con los estados difíciles ya resueltos.

Dónde actuamos

Identidad visual y design system
UX research y flujos críticos
Prototipado navegable
Handoff y tokens en código

Qué recibís

Brand guidelines + componentes en Figma
Design tokens listos para Tailwind/CSS
Prototipos validados con usuarios
Guía de microcopy y accesibilidad

Del problema al componente

Empezamos por entender qué está intentando hacer la persona en la pantalla, no cómo debería verse la pantalla. Eso suele reordenar prioridades: mucha interfaz pesada existe porque se diseñó desde la estructura de la base de datos y no desde el trabajo real.

Después diseñamos componentes, no páginas: botón, campo, aviso, tabla, modal — cada uno con sus estados de foco, error, carga y vacío. Las páginas se arman desde ahí, y la pantalla siguiente nace consistente sin que nadie decida nada de nuevo.

Diseño en código, no en imagen

Los tokens de color, tipografía, espaciado y radio se vuelven variables CSS reales. Eso no es un detalle de implementación: es lo que permite cambiar el tema entero, verificar contraste automáticamente y que el modo claro y el oscuro nazcan juntos en lugar de que uno sea adaptación improvisada del otro.

El contraste WCAG 2.2 AA es criterio de aceptación, verificado por herramienta en cada cambio. Un color que no pasa contraste es un bug y bloquea la entrega como tal.

Preguntas frecuentes

¿Hacen solo el diseño o también implementan?
Ambos, y en nuestro caso es difícil separarlos: entregamos el design system en código, con los componentes funcionando. Si tu equipo implementa, recibe los componentes y la documentación, lo que evita la clásica pérdida entre la imagen aprobada y la pantalla publicada.
¿Necesito cambiar toda mi identidad visual?
Casi nunca. Lo habitual es que la marca esté bien y falte el sistema alrededor: escala tipográfica, paleta con contraste verificado, espaciado consistente, estados de componente. Un rediseño completo de marca es otro proyecto, y decimos cuándo no hace falta.
¿La accesibilidad encarece el proyecto?
Hecha desde el inicio, casi no pesa: es elegir colores con contraste adecuado, marcar el HTML correctamente y probar navegación por teclado. Lo caro es adaptarla después, cuando el componente ya está repartido en treinta pantallas.

Los proyectos suelen pedir más de un frente. Estos son los que más aparecen junto con este.