Sistema de componentes para un marketplace de servicios

Tokens, variantes y estados documentados para un equipo de tres personas que venía publicando pantallas nuevas cada dos semanas.

El marketplace de servicios profesionales crecía rápido: cada sprint sumaba pantallas y cada pantalla resolvía botones, campos y tarjetas a su manera. Nadie había definido reglas, así que el mismo botón primario aparecía con tres alturas distintas y dos tonos de azul. La librería que armamos no busca ser exhaustiva, sino dejar por escrito lo mínimo para que cualquiera del equipo construya sin inventar de nuevo.

El punto de partida

Tres personas, un backlog con features nuevas y ninguna convención escrita. Los colores vivían en el archivo de Figma de cada diseñador y el espaciado se decidía a ojo según la pantalla. Cuando entraba alguien nuevo, las primeras dos semanas se iban en preguntar qué componente usar.

Cómo lo encaramos

Arrancamos por los tokens: escala de color, espaciado en múltiplos de cuatro, dos familias tipográficas con pesos definidos. Sobre esa base armamos los componentes con sus variantes y estados: reposo, hover, foco, deshabilitado y error. Cada ficha incluye notas de accesibilidad sobre contraste, foco visible y área táctil mínima.

Qué quedó documentado

Botones, campos de formulario, tarjetas de servicio, chips de categoría y avisos. La documentación está escrita para que la lea alguien que recién se suma: qué hace cada componente, cuándo no usarlo y qué variante corresponde según el contexto. Sin capturas decorativas de más.

Resultado

El equipo dejó de discutir tonos y tamaños en cada revisión. Las pantallas nuevas salen más rápido porque parten de piezas ya resueltas, y las inconsistencias que antes aparecían en producción ahora se detectan en el archivo antes de pasar a desarrollo. La librería sigue viva: cada componente nuevo se suma con la misma ficha y las mismas reglas.

Casos que se pueden recorrer antes de decidir

Cada pieza del catalogo es una maqueta funcional con su contexto: que problema habia, como se resolvio la jerarquia y que notas quedaron sobre accesibilidad y rendimiento. Los tres casos que siguen salieron de equipos chicos que necesitaban mostrar trabajo real sin armar un sitio desde cero.

Pantalla de alta de usuario en una fintech con pasos de verificacion y campos de identidad

Onboarding

Onboarding para fintech de pagos

Flujo de alta en cuatro pasos con verificacion progresiva

El alta original pedia todos los datos en una sola pantalla y perdia usuarios en el segundo campo. Se reorganizo en cuatro pasos: identidad, datos fiscales, cuenta bancaria y confirmacion. Cada paso indica que falta y que ya quedo validado, y los errores se explican junto al campo que los origina. La maqueta incluye variantes para usuario nuevo, invitado por un comercio y reintento tras rechazo.

Ver el caso completo

Tablero de control de entregas urbanas con mapa, lista de envios y estados de incidencia

Dashboard

Dashboard operativo para logistica urbana

Tablero de entregas con jerarquia por urgencia y filtros por zona

Operaciones seguia las entregas en una planilla compartida y perdia tiempo cruzando zona con estado del envio. La maqueta propone tres niveles de lectura: resumen del dia, lista por zona y detalle del envio. Las incidencias se marcan con color y texto, no solo con color, para que sigan siendo legibles en pantallas mal calibradas. Quedan documentados los estados vacio, cargando, con datos y con error de sincronizacion.

Ver el caso completo

Documentacion de un sistema de componentes con tokens de color, tipografia y variantes de botones

Sistema de diseno

Sistema de componentes para un marketplace de servicios

Tokens, variantes y estados documentados para un equipo de tres personas

El marketplace sumaba pantallas nuevas cada sprint y cada una resolvia botones, campos y tarjetas a su manera. El sistema parte de tokens de color, espaciado y tipografia, y define componentes con sus variantes y estados: reposo, hover, foco, deshabilitado y error. Cada componente incluye notas de accesibilidad sobre contraste, foco visible y tamano minimo de area tactil. La documentacion esta escrita para que alguien que se suma al equipo pueda construir sin preguntar.

Ver el caso completo