Tres piezas que salieron de pedidos concretos: un alta que perdía gente, un tablero que reemplazó una planilla y un sistema que ordenó un marketplace. Cada caso se puede recorrer por dentro, con las decisiones de jerarquía, los estados documentados y las notas de accesibilidad que quedaron en el archivo.
Flujo de alta en cuatro pasos con verificacion progresiva
El alta original pedía todo en una sola pantalla y perdía usuarios en el segundo campo. Se reorganizó en cuatro pasos: identidad, datos fiscales, cuenta bancaria y confirmación. Cada paso indica qué falta y qué ya quedó 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 entregas con jerarquia por urgencia y filtros por zona
Operaciones seguía los repartos en una planilla compartida y cruzaba zona con estado a mano. La maqueta propone tres niveles de lectura: resumen del día, lista por zona y detalle del envío. Las incidencias se marcan con color y texto, no solo con color, para que se lean en pantallas mal calibradas. Quedan documentados los estados vacío, cargando, con datos y con error de sincronización.
Ver el caso completo
Tokens, variantes y estados documentados para un equipo de tres personas
El marketplace sumaba pantallas cada sprint y cada una resolvía botones, campos y tarjetas a su manera. El sistema arranca por tokens de color, espaciado y tipografía, y define componentes con sus variantes y estados: reposo, hover, foco, deshabilitado y error. Cada pieza lleva notas de accesibilidad sobre contraste, foco visible y tamaño mínimo de área táctil. La documentación está escrita para que alguien que se suma al equipo construya sin preguntar.
Ver el caso completoCada pieza del catalogo se muestra con la pantalla que importa y una nota corta sobre por que quedo asi. Sin renders decorativos: estados reales, jerarquia de lectura y el detalle que resolvio el problema del cliente.
Las capturas salen del prototipo navegable, no de un mockup estatico. Eso permite ver como se comporta un flujo antes de invertir en desarrollo y detectar donde se traba la lectura.
En cada caso anotamos tres cosas: que problema resolvia la pantalla, que decision de jerarquia visual se tomo y que nota de accesibilidad o rendimiento quedo pendiente. Esa parte suele ser la mas util para el equipo que recibe el trabajo.
Comentarios de clientes de Buenos Aires, Rosario y Córdoba que usaron las maquetas navegables para decidir con su equipo técnico y de producto. Sin métricas infladas: qué cambió en su forma de trabajar después de la revisión.
Fintech regional
"Llegamos con un alta de usuario que perdía gente en el segundo campo. Ver el flujo de cuatro pasos funcionando en la maqueta nos ahorró dos semanas de discusión interna. El equipo de desarrollo entendió el orden de validación sin que tuviéramos que dibujar nada."
Mariana L.
Product Lead, pagos digitales
Logística urbana
"Trabajábamos las entregas en una planilla y cruzábamos zona con estado a mano. El tablero con tres niveles de lectura nos ordenó la operación diaria. Lo que más nos sirvió fue ver los estados vacío y con error de sincronización antes de tener el backend listo."
Diego R.
Coordinador de operaciones, CABA
Marketplace de servicios
"Somos tres personas y cada sprint agregaba pantallas con botones distintos. El sistema de componentes con tokens y estados nos dio una base para no reinventar lo mismo. Las notas de accesibilidad sobre foco visible y área táctil las aplicamos directo en el código."
Sofía M.
Fundadora, marketplace profesional
"Pedimos la revisión con una semana de anticipación y llegamos con el flujo de checkout a medio definir. Salimos con las decisiones de jerarquía visual tomadas y capturas del proceso para mostrarle al cliente final. No tuvimos que armar un sitio desde cero para presentarlo."
Tomás V.
Diseñador freelance, Rosario
"Nos interesaba ver cómo se comportaba el onboarding antes de invertir en desarrollo. La maqueta navegable nos dejó probar el reintento tras rechazo y ajustar los mensajes de error. Es la primera vez que un prototipo nos sirve para decidir, no solo para mostrar."
Lucía P.
CTO, estudio de producto, Córdoba