Cómo Sofía Álvarez usó Useberry e IA para construir una app de finanzas

Nota editorial: Conocimos el proyecto Milestone de Sofía al ver cómo conectó la investigación, el card sorting en Useberry, el diseño y la IA a lo largo de un mismo flujo de producto, de punta a punta. La invitamos a contar cómo cada etapa le dio mejor contexto a la siguiente y en qué puntos el criterio humano siguió siendo clave, a medida que una parte cada vez mayor de la ejecución pasaba a manos de la IA.

Sofía Álvarez es product designer y explora la investigación UX, el diseño de producto y los flujos de trabajo asistidos por IA. Podés seguirla en LinkedIn.

Lo que Milestone me enseñó sobre la IA

Por Sofía Álvarez

Empecé este proyecto con una idea: diseñar un sistema en el que cada paso dejara el contexto suficiente para que la IA pudiera ejecutar el siguiente sin tener que improvisar.

Milestone es una app de finanzas personales que construí sola, de punta a punta: investigación, arquitectura, diseño, código y deploy.

Al principio pensaba mucho en cómo las distintas herramientas de IA podían ayudarme a ir más rápido. Pero a medida que el proyecto avanzaba, me di cuenta de que lo más interesante no era simplemente que la IA pudiera escribir código.

Lo que en realidad estaba haciendo era delegar una cadena completa de trabajo. Y esa cadena funcionaba porque cada etapa le dejaba a la siguiente algunas decisiones ya tomadas, en lugar de pasarle otra pregunta abierta.

El problema no era de funcionalidades: era emocional

Milestone partió de una hipótesis bastante típica: quizás la gente no maneja sus finanzas porque las apps que existen son demasiado complejas, demasiado frías o, directamente, no logran generar un hábito.

Para comprobar si eso era realmente así, entrevisté a usuarios reales. La hipótesis no estaba del todo errada, pero las entrevistas me mostraron que el problema era mucho más profundo.

Todas las personas que entrevisté ya usaban alguna herramienta para organizar su dinero: la app del banco, una billetera virtual, un Excel o incluso un cuaderno. Pero en algún momento, todas habían pasado por lo mismo: dejaron de registrar sus gastos.

No porque fueran vagas o no les importara su situación financiera, sino porque sostener el registro terminaba pesándoles más que el beneficio que obtenían.

Además, la mayoría de las apps asume un nivel de disciplina que en la vida cotidiana, en realidad, no existe. Cuando alguien vuelve después de un tiempo sin registrar nada, muchas veces se encuentra con saldos negativos, rachas rotas o información incompleta.

Se diseña mucho para sostener un hábito, pero muy poco para el momento en que alguien decide volver. De esas entrevistas salió un insight clave que terminó guiando gran parte del proyecto:

El usuario no quiere controlar sus gastos, quiere sentir tranquilidad.

Ese insight pesó más que cualquier lista de funcionalidades, porque se convirtió en el primer contexto que usé para evaluar las decisiones que vinieron después: tanto las que tomé yo como las que empecé a delegar en herramientas de IA.

El card sorting con usuarios reales definió la arquitectura de información

La arquitectura de información de Milestone no salió de un sitemap armado solo a mi criterio ni de un benchmark de otras apps. Antes de definirla, hice un card sorting abierto en Useberry, en el que usuarios reales agruparon 21 funcionalidades según cómo entendían la relación entre ellas.

No tomé los resultados como una verdad absoluta. Antes de usarlos como base para la arquitectura, revisé personalmente la matriz de similitud y la cuadrícula de estandarización, para asegurarme de que las agrupaciones fueran consistentes y de no estar confundiendo ruido con un patrón real.

Una vez confirmados esos clusters, usé el MCP de Claude en Figma para generar un primer sitemap. El resultado fueron seis secciones: Inicio, Registros, Ahorro, Aprender, Perfil y Configuración.

En ese punto, la IA no tuvo que inventar categorías ni decidir por su cuenta cómo se relacionaban las funcionalidades. Esa información ya venía de las personas que participaron del card sorting y, antes de que llegara a Claude, yo ya había revisado e interpretado esos resultados.

Cuando el card sorting y las entrevistas apuntaban en direcciones distintas

De todos modos, el proceso no fue tan lineal como puede sonar. Cuando llevé ese sitemap a wireframes de baja fidelidad, la sección “Aprender” empezó a chocar con algo que había surgido en las entrevistas.

El card sorting había agrupado esa funcionalidad con bastante consistencia. Pero en las conversaciones con usuarios, nadie había expresado la necesidad de una sección donde sentarse a estudiar finanzas. Lo que necesitaban era entender qué hacer en el momento exacto en que surgía la duda, sin sentir que tenían que frenar para tomar una clase. Así que decidí disolver la sección “Aprender”.

Los tips y las minilecciones dejaron de ser una sección de navegación y pasaron a ser contenido contextual. Ahora aparecen cuando creás una meta, cuando registrás un gasto o en el momento en que tenés que tomar una decisión.

También integré “Configuración” dentro de Perfil. Otras funcionalidades que el card sorting había agrupado como conceptos —como tachar un gasto fijo, editar un registro o filtrar el historial— resultaron tener más sentido como acciones dentro de una pantalla que como secciones aparte.

Esta parte fue especialmente importante para mí, porque me recordó que el card sorting muestra cómo las personas agrupan mentalmente distintos conceptos, pero eso no significa que esos grupos tengan que trasladarse tal cual a la navegación final.

Interpretar los resultados y decidir qué hacer con ellos seguía siendo parte de mi trabajo. La arquitectura final quedó con cinco secciones: Inicio, Ahorro, Registrar, Historial y Perfil.

También hubo decisiones sobre qué no construir todavía. El simulador de ahorro y los tips contextuales llegaron al producto, mientras que el sistema de logros e insignias, que en un principio había pensado como una sección propia de gamificación, se redujo por ahora a una animación que aparece cuando alguien completa una meta. El resto quedó para una etapa posterior.

No fue porque la investigación hubiera descartado la gamificación. Fue, simplemente, una decisión de alcance: preferí no construir de más antes de saber si lo esencial del producto funcionaba.

De una pantalla validada a un producto vivo

Con la arquitectura más clara, mapeé el flujo completo en Figma, desde la primera interacción hasta el uso sostenido.

En lugar de llevar de entrada todo el producto a alta fidelidad, decidí priorizar un solo flujo, el de Metas de ahorro, y construir alrededor de él un sistema de componentes real.

Documenté 61 variantes sobre el UI Kit de Material Design 3 y lo adapté al branding de Milestone, porque quería que el producto tuviera identidad propia y no terminara pareciéndose a una app bancaria más.

Pasar de pantallas diseñadas a un producto en funcionamiento implicó un proceso de prompt engineering muy deliberado. Traduje cada pantalla de Figma en instrucciones que Claude Code pudiera ejecutar sin demasiada ambigüedad, y construí la aplicación completa en Flutter y Firebase. Para ese momento, muchas de las decisiones importantes ya estaban tomadas.

La investigación había definido el problema. El card sorting había aportado evidencia para la arquitectura. Los wireframes me habían ayudado a interpretar esa información. Y el sistema de componentes había establecido cómo traducirla a la interfaz.

Claude Code no tuvo que decidir qué significaba una “meta de ahorro” para un usuario ni cómo había que organizar la información. Esas decisiones ya estaban resueltas.

Hubo, además, una parte del proceso que me gusta contar, porque muestra que el desarrollo no fue ni de cerca tan prolijo como puede parecer cuando se cuenta la historia con todo ya terminado.

Para tener un prototipo clickeable con el que testear, hice las cosas un poco al revés de lo habitual. En lugar de prototipar primero en Figma y programar después, tomé el código que ya había desarrollado en Flutter y usé el MCP de Claude para llevarlo de vuelta a Figma como prototipo.

Antes de mostrárselo a usuarios, hice mi propio UAT y encontré un ícono roto que, si hubiera aparecido durante el test, probablemente le habría restado credibilidad al prototipo.

Lo que encontró el testing, y por qué nueve deploys es el número que importa

Después llegó el momento de poner el producto frente a usuarios reales. Combiné sesiones moderadas con un test de prototipo no moderado, y ahí apareció el hallazgo que más me importó de todo el proyecto:

Una meta de ahorro de $20.000 se marcaba como “lograda” cuando la persona había ahorrado solo $5.000.

No era solo un problema visual: era un bug de integridad de datos. Si hubiera llegado a producción, la app le habría dicho a alguien que había alcanzado una meta de la que en realidad todavía estaba lejos. Y eso tocaba de lleno uno de los problemas que habían aparecido en la investigación: la confianza.

Si una app de finanzas no puede decirte correctamente cuánto ahorraste, se vuelve muy difícil confiar en el resto de la información que te muestra. A partir de ahí, la IA empezó a cumplir un rol distinto del que había tenido durante la arquitectura o el diseño.

Cada hallazgo del testing se convirtió en una instrucción concreta para Claude Code, que implementaba el fix correspondiente. Después, yo volvía a verificar el resultado. Fueron nueve iteraciones reales y, antes de publicar cada una, revisaba el proyecto con flutter analyze y flutter build web.

Otra vez: lo importante no era que la IA supiera por sí sola qué estaba mal. El testing había convertido un problema abierto en un problema concreto que la IA sí podía resolver. Nueve deploys después, la app sigue funcionando.

La decisión nunca fue de la IA

Después de recorrer todo este proceso, creo que lo que más me quedó no tiene que ver con ninguna herramienta en particular, sino con dónde se tomaron realmente las decisiones. En ningún momento necesité que la IA adivinara.

El card sorting me permitió sacar parte de la arquitectura de mi propia cabeza y apoyarla en lo que habían expresado usuarios reales. La investigación, a su vez, me obligó a reinterpretar esa arquitectura cuando entró en conflicto con lo que las personas realmente necesitaban.

El diseño tradujo esas decisiones en pantallas y componentes concretos, y el testing encontró un problema que, de haber llegado a producción, habría dañado justamente la confianza que estaba tratando de construir.

La agencia estuvo en cada una de esas decisiones: qué tomar del card sorting y qué reinterpretar, qué construir primero y qué dejar para después, qué información darle a la IA y en qué momento.

La IA pudo hacerse cargo de una parte cada vez más grande de la ejecución porque le quedaban menos decisiones ambiguas por resolver. Por eso, después de Milestone, empecé a pensar el trabajo con agentes de una forma un poco distinta.

Para mí, un agente no reemplaza el criterio del diseñador. Lo interesante no es solo que ahora podamos hacer más cosas con IA, sino que tenemos que aprender a decidir qué vale la pena delegar, qué contexto necesita cada decisión y qué decisiones siguen siendo nuestras.

Desde el equipo de Useberry

Lo que más nos llamó la atención del proceso de Sofía fue cómo la investigación siguió orientando el trabajo, incluso a medida que la IA asumía más parte de la ejecución. El card sorting ayudó a orientar la arquitectura, la interpretación que Sofía hizo de la investigación la modificó y, más adelante, el testing convirtió otro problema abierto en algo concreto sobre lo que se podía actuar. Es un ejemplo útil de cómo la IA puede avanzar más rápido cuando las decisiones a su alrededor tienen mejor contexto.

Gracias a Sofía Álvarez por compartir con nosotros el proceso de Milestone. Si querés conocer los métodos de investigación detrás de un flujo de trabajo similar, podés leer más sobre el card sorting con Useberry o ver cómo el testing de prototipos en Useberry puede ayudarte a incorporar el comportamiento real de los usuarios en las decisiones de producto antes de que el desarrollo avance demasiado.

Convertí mejor investigación en mejores decisiones de producto

Hacé card sorting, tests de prototipos y mucho más con Useberry para validar ideas antes de construir.

Conocé Useberry