Proyecto conceptual Diseño de Producto

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.

Un plano cercano de pantallas de interfaz con marcas de esquina de selección sobre un panel fintech, con un acento de luz cálida en un elemento seleccionado.

01 — El reto

  1. 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.
  2. 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.
  3. 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.

04 — Resultado

  1. 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.
  2. 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.
  3. 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?