8+ años diseñando productos B2B de principio a fin — desde el encuadre hasta el handoff, con criterio de front-end.
Rediseño de los flujos core de una plataforma de atención al cliente para e-commerce.
Ver casoRediseño progresivo de una plataforma de reventa de tickets para 9.000+ brokers.
Ver casoRediseño de la herramienta de compliance anual de EY con restricciones en sistema legacy.
Ver casoAuditoría, design system y nuevo proceso de trabajo para una app web de fabricantes de hormigón.
Ver casoSoy Agostina, diseñadora de producto con 8+ años en productos B2B — desde el encuadre del problema hasta el handoff y seguimiento en producción.
También tuve 5 años de experiencia como front-end developer, lo que me permite hablar el mismo idioma que ingeniería, evitar rework y tomar decisiones de diseño con conciencia técnica desde el principio.
Basada en Paraná, Argentina 🇦🇷. Cuando no estoy diseñando, me encontrás en bici, caminando con mi perro o haciendo cerámica.
Si tenés un producto que necesita escalar, un flujo que nadie termina de entender, o querés arrancar de cero con las bases bien puestas — hablemos.
cobalto.ux@gmail.comtambién estoy en LinkedIn
Rediseño de los flujos core de una plataforma de atención al cliente para e-commerce, priorizando adopción real.
ChatCenter es una herramienta B2B de atención al cliente orientada a e-commerce. El producto tenía funcionalidades valiosas, pero secciones enteras habían quedado abandonadas porque los usuarios no las encontraban o no entendían para qué servían.
El equipo de producto detectó una oportunidad: en lugar de agregar nuevas funciones, hacer que las existentes se usaran. Ahí entré yo.
El problema no era lo que faltaba. Era que lo que existía no estaba diseñado para ser descubierto.
Antes de diseñar una sola pantalla, audité el producto existente. Mapeé los flujos principales, identifiqué dónde los usuarios se perdían y cuáles eran los puntos de abandono más críticos.
Los hallazgos más importantes: navegación sin jerarquía clara, ausencia de estados de vacío que orientaran al usuario nuevo, y flujos que pedían información en un orden que no tenía sentido para el usuario.
El usuario tipo de ChatCenter es un agente de atención al cliente con alta rotación y poco tiempo de onboarding. El producto tenía que ser autoexplicativo desde el primer uso.
Trabajé iterando wireframes con el equipo de producto, validando con usuarios reales y ajustando en función de lo que aparecía en las sesiones. Cada decisión de diseño tenía que pasar el filtro: ¿lo entiende alguien que nunca usó esto?
El resultado fue un rediseño de los flujos core — bandeja de entrada, gestión de conversaciones y configuración — con un sistema de componentes que le daba consistencia a toda la plataforma.
La métrica más relevante fue la adopción de las secciones que antes nadie usaba. Los usuarios empezaron a incorporarlas a su flujo de trabajo sin necesitar capacitación adicional.
El design system construido durante el proyecto quedó como base para el equipo de producto, permitiendo iterar más rápido en el futuro.
El mejor rediseño es el que el usuario no nota — simplemente funciona.
Rediseño progresivo de una plataforma de reventa de tickets para más de 9.000 brokers, balanceando diseño y desarrollo en simultáneo.
SkyBox es la plataforma de Vivid Seats para brokers y revendedores de tickets. Con más de 9.000 usuarios activos, el producto había crecido de forma orgánica hasta llegar a un punto donde la interfaz era difícil de escalar y los brokers seguían necesitando llamar al soporte para tareas básicas.
Mi rol fue liderar la estrategia de diseño del producto: desde el encuadre de cada problema hasta el handoff, con la particularidad de que también tenía responsabilidades de desarrollo front-end.
El mayor reto no era técnico: era cambiar progresivamente una plataforma que miles de personas usaban diariamente, sin disrumpir su flujo de trabajo.
Trabajé en estrecha colaboración con el PM para definir las prioridades. El objetivo principal fue reducir los contactos al equipo de soporte — cada ticket de soporte era una falla de diseño.
Cada vez que un usuario llama al soporte para hacer algo básico, el producto falló antes.
La estrategia fue un rediseño progresivo: trabajar sección por sección, validando con usuarios antes de implementar. Usé Google Analytics para medir tiempos de completado de tareas y comparar antes/después de cada cambio.
Arranqué construyendo el design system en Sketch: no partí de cero, sino que tomé los templates existentes como base y fui construyendo componentes a partir de los patrones ya presentes en la app. Esto garantizó consistencia sin rework masivo.
Como también hacía front-end, podía ver de primera mano qué no necesitaba construir en Figma, evitando trabajo duplicado para todo el equipo.
Los flujos rediseñados mostraron reducción en tiempos de completado de tareas medida en Google Analytics. Los usuarios empezaron a descubrir funcionalidades por su cuenta sin necesitar intervención del soporte.
El design system construido durante el proceso quedó como la base sobre la que el equipo siguió iterando.
Rediseño de la herramienta de compliance anual de EY, con restricciones técnicas en un sistema legacy sin documentación.
FACT (Form AP Compliance Tool) es la herramienta que EY usa para que sus auditores completen la declaración jurada anual de horas y datos del estudio. El problema era evidente: el formulario era tan complejo que requería un manual de 56 páginas para poder llenarlo correctamente.
Mi tarea fue rediseñar la experiencia para que el formulario fuera autoexplicativo — sin eliminar la complejidad del negocio, sino haciéndola manejable.
Si necesitás 56 páginas para explicar cómo usar algo, el problema no es el usuario.
La restricción principal no era de UX: era técnica. El sistema tenía poca documentación y flexibilidad limitada para implementar diseños modernos. El equipo de desarrollo marcaba el límite de lo posible en cada iteración.
Esto requirió un enfoque pragmático: entender profundamente qué podía y qué no podía implementarse, y diseñar dentro de esos límites sin perder el foco en el usuario. Cada decisión pasaba por el filtro de ¿esto es implementable?
El proceso fue muy iterativo y dependió de comunicación constante con el equipo de desarrollo. En lugar de diseñar la solución ideal y negociar después, empecé por entender las restricciones del sistema y diseñé dentro de ellas.
Las mejoras más impactantes: navegación contextual que indica exactamente dónde está el usuario en el proceso, validaciones en tiempo real en lugar de errores al final, y agrupación lógica de campos según el flujo mental del auditor — no la estructura de la base de datos.
Cada propuesta fue validada con el equipo técnico antes de presentarla como solución final, evitando rework y frustraciones de ambos lados.
El rediseño logró que auditores nuevos pudieran completar el formulario sin consultar el manual. La navegación contextual y las validaciones en tiempo real reemplazaron las 56 páginas de instrucciones.
El aprendizaje más valioso: en sistemas legacy, el diseño no empieza con lo ideal — empieza con lo posible, y desde ahí construís hacia adelante.
Auditoría, design system y nuevo proceso de trabajo para una app web donde fabricantes de hormigón generan sus declaraciones electrónicas de mezclas.
Climate Earth es una aplicación web donde empresas fabricantes de hormigón pueden generar declaraciones electrónicas de sus mezclas e ingredientes de productos. Es una herramienta técnica, con usuarios que no son diseñadores — son ingenieros y operadores de planta.
Los ingenieros del equipo me contactaron porque sospechaban que la plataforma necesitaba un rediseño. Mi primer paso fue validar esa sospecha con datos.
La auditoría confirmó lo que el equipo intuía. Los hallazgos principales: interfaz difícil de escalar sin espacio para nuevas secciones, navegación que no seguía patrones modernos con links perdidos en banners y falta de botón "volver" en algunos flujos, y ausencia total de un sistema de diseño previo.
Tener ese diagnóstico claro fue lo que permitió priorizar el trabajo correctamente. No todo era urgente — pero sin base, nada iba a escalar bien.
El diagnóstico es parte del diseño. Antes de proponer soluciones, hay que entender exactamente qué hay que resolver.
Antes de rediseñar una sola pantalla, construí el sistema de diseño. No como objetivo en sí, sino porque sin base, cualquier cambio iba a quedar inconsistente.
Trabajé con los colores reales de la marca, seleccioné Manrope como tipografía (fuente libre con buen soporte para uso técnico) y construí los componentes esenciales: inputs, botones, checkboxes, radio buttons y tablas con variaciones según el tipo — comparación, headers fijos, color-coded.
Las tablas fueron particularmente complejas porque los usuarios trabajaban con grandes volúmenes de datos. Diseñé variaciones específicas para cada caso de uso, no un componente genérico que no servía bien para ninguno.
La dinámica con el equipo de desarrollo era atípica: los requerimientos llegaban en calls sin aviso previo, muchas veces cuando algo ya estaba construido. Esto obligaba a ajustar el diseño a decisiones técnicas ya tomadas.
En lugar de adaptarme indefinidamente a ese flujo, propuse un touchpoint semanal fijo donde yo presentaba mis ideas antes de que el equipo avanzara en desarrollo. El cambio fue simple pero tuvo un impacto grande: el equipo podía ver el diseño antes de implementar, y yo podía incorporar las restricciones técnicas desde el inicio.
El resultado fue que los dos lados evitamos rework. La buena comunicación también me permitió ver qué no necesitaba construir en Figma — ahorrando tiempo para todos.
Climate Earth me enseñó que en proyectos donde el roadmap no está claro, la primera contribución del diseñador no siempre es visual — a veces es estructural.
Arrancar con una auditoría rigurosa, construir la base antes de diseñar pantallas y establecer un proceso de trabajo que funcionara para todos fue lo que hizo posible que los cambios visuales tuvieran impacto real.
Diseñar bien a veces es cambiar cómo trabaja el equipo antes de cambiar lo que ve el usuario.