Fielmo
Fielmo es un proyecto conceptual autoiniciado — una startup fintech/SaaS en fase inicial inventada, hecha por el estudio para mostrar su forma de abordar una auditoría de usabilidad y un rediseño de flujos. No fue un encargo de un negocio real.
01 — El reto
- El MVP de una fintech en fase inicial lo había construido rápido el propio equipo fundador para llegar a una demo, y la deuda de usabilidad había llegado al punto en que cada nueva función empeoraba el onboarding en lugar de mejorarlo.
- Nadie del equipo podía decir con seguridad qué flujos del producto estaban perdiendo usuarios de verdad frente a los que solo se sentían torpes — el equipo adivinaba la prioridad.
- El brief pedía una auditoría estructurada y basada en evidencia antes de cualquier trabajo de rediseño, para que el esfuerzo de arreglo fuera primero a los flujos que más importaban.
02 — El enfoque
El Sondeo consistió en usar el producto como lo haría un usuario primerizo, flujo a flujo, y aplicar una evaluación heurística contra fundamentos de WCAG en lugar de un repaso subjetivo de "esto no se siente bien". El Fundamento fue donde la auditoría se convirtió en prioridad: no todos los flujos rotos importan por igual, así que esta etapa ordenó los hallazgos entre victorias rápidas y arreglos estructurales, según el punto del embudo en el que estaba cada flujo. La Construcción, en este proyecto conceptual, se amplió a un rediseño de los dos flujos de mayor prioridad identificados — el onboarding y el flujo de transacción principal — construidos como componentes reutilizables y no como pantallas puntuales, para que el arreglo no tuviera que repetirse la próxima vez que cambiara el producto. El Acabado entregó un informe de hallazgos anotado y especificaciones de interacción lo bastante concretas para que un desarrollador pudiera implementarlas sin una reunión de seguimiento.
03 — Galería
Composiciones en marco de móvil y de navegador con bloques de color abstractos en --tint-pd (oliva-caqui), representando los estados antes/después del flujo de onboarding a nivel de anotación de componentes.
04 — Resultado
- Un informe de hallazgos priorizado que separaba victorias rápidas de arreglos estructurales, para que el equipo supiera qué atacar ese mismo sprint y qué planificar.
- Un onboarding y un flujo de transacción principal rediseñados con componentes reutilizables, no pantallas puntuales — el arreglo aguanta a medida que el producto sigue cambiando.
- Especificaciones de interacción lo bastante concretas para implementarse sin una reunión de seguimiento — la entrega fue el entregable, no una presentación sobre la entrega.
¿No estás seguro de qué flujos son realmente el problema?