AVIT es un producto de inversión del mercado de valores de Costa Rica. Cuando entré, su diseño vivía entero en Figma: pantallas preciosas, una por estado, y un equipo que tardaba semanas en saber si una idea funcionaba. No había un solo prototipo que se pudiera tocar. Esto es lo que construí para cambiar eso —y sigue en obra.
El producto todavía no salió al público y el trabajo continúa, así que esto es un recorte, no un caso cerrado. Muestro el método, el sistema de diseño y las piezas que puedo enseñar. Quedan fuera el link al laboratorio, las pantallas del cliente y cualquier cifra de negocio: los porcentajes que aparecen en las capturas están enmascarados a propósito. Lo iré ampliando por capítulos a medida que el proyecto avance.
el contexto
Mi rol es de Product Designer con el sombrero puesto en dos cosas a la vez: el sistema de diseño y el prototipado. AVIT es mobile first, para Costa Rica, y buena parte de sus flujos son innegociables porque los pide la regulación —lo que hace que cada decisión de diseño tenga poco margen y mucho peso.
& prototipado
& sigue
20 prototipos
el punto de partida
La librería de Figma se llamaba COMPONENTS y se había ido a la deriva sin que nadie lo notara. Había cuatro componentes publicados por duplicado —Button, Button Group, Social Button, Download App Button— y nadie sabía cuál era el bueno. Los nombres de los tokens traían typos horneados: pimario 100 sin la erre, terceario en lugar de terciario, tittle (xl) con dos tes. Varias definiciones de grid mentían: una rejilla llamada «10 columns» tenía nueve. Las sombras estaban coloreadas con la paleta por defecto de Tailwind, no con el morado de la marca. Y no existían tokens de espaciado ni de radio: simplemente no estaban.
El handoff era el clásico, y lo llamo clásico porque lo he vivido en todos lados: una pantalla estática por estado, y los estados que faltaban se preguntaban después. Las medidas se leían del panel de Figma. Los comentarios vivían encerrados en el archivo de diseño, donde solo entra quien tiene cuenta. El flujo se explicaba con flechas.
Nada de eso es culpa de nadie. Es lo que pasa cuando la documentación y el producto viven en herramientas distintas y solo una de las dos se ejecuta.
auditar antes de construir
Antes de dibujar nada, exporté los tokens de Figma y me senté a leerlos. Salieron 85 tokens de color en diez familias, 49 estilos tipográficos entre Montserrat y Open Sans, 14 sombras y 18 definiciones de grid, además de los 23 componentes publicados en la librería.
Documenté cada defecto que encontré en vez de arreglarlo en silencio. Esa fue la decisión menos obvia y la que más rindió: si la documentación corrige el typo y Figma no, la documentación empieza a mentir el mismo día que se escribe. Así que pimario 100 quedó escrito como pimario 100, con una nota al lado explicando qué pasó. Lo mismo con la página que Figma titula «Iconography» y describe como Ionicons cuando los layers son, en realidad, Boxicons: manda la realidad, no el título.
Los tokens que Figma no tenía los inventé y los marqué como convención local, para que se distingan de lo exportado: una escala de espaciado de cinco pasos derivada de los propios gutters de la rejilla, y una escala de cuatro radios.
El sistema dejó de ser un archivo que se consulta y pasó a ser código que se ejecuta: los mismos tokens alimentan la documentación, el laboratorio y —más adelante— la app.
el sistema, en vivo
Esta es la pieza que mejor explica por qué un prototipo que se toca vale más que una pantalla que se mira. Movés el nivel de riesgo y todo lo demás responde: la composición, el donut, la descripción. En una imagen estática esto son cinco pantallas y una flecha; acá es un gesto.
Paso 2 de 3
Elegí tu estrategia
- Renta fija40 %
- Acciones globales40 %
- Mercados emergentes12 %
- Efectivo8 %
Un punto de partida equilibrado: la mitad de la cartera busca crecer y la otra mitad amortigua los años malos.
Reconstrucción del patrón de interacción con la paleta y los radios reales de AVIT. Los porcentajes son inventados para esta demo.
un problema, varias opciones
El laboratorio tiene una regla y de ahí sale todo lo demás: un problema nunca se resuelve con una propuesta. Cada problema de UX vive como un proyecto fechado, con su contexto y su hipótesis escritas antes de dibujar, y debajo cuelgan todas las opciones que llegamos a construir, numeradas.
Antes de la primera opción hay research. Miro cómo resuelven el mismo problema otras apps de inversión, sobre todo las de la región: son las que marcan qué patrones la gente de acá ya sabe usar, y cuáles todavía hay que explicar. Repaso las evaluaciones de UX del flujo actual para ver dónde se traba hoy. Y averiguo qué partes del flujo son obligatorias por regulación, porque esas no se tocan por más que estorben y conviene saberlo antes de proponer algo que después no se puede construir. Con eso escribo la hipótesis. Dibujar viene después.
Las opciones descartadas no se borran. Se marcan como ocultas —salen de la lista— pero su ruta sigue viva, así que cualquiera puede volver a entrar y ver por qué se descartó. De veinte prototipos construidos, la mayoría están hoy ocultos. Esa diferencia es parte del argumento: se descartó con el prototipo andando, no con una imagen.
las notas al margen
Cuando le enseñás un prototipo a un cliente pasa siempre lo mismo: entiende qué ve, pero no por qué está así. Y si no estás vos ahí para contarlo, el prototipo se lee mal.
Por eso cada prototipo lleva su propia capa de anotaciones. Son notas adhesivas que viven en los márgenes de la pantalla, ancladas a la altura de lo que explican: la de la izquierda cuenta el cambio, la de la derecha el porqué. Cada una tiene un tono según lo que es —un cambio clave, una advertencia, algo pendiente de confirmar— y una posición mínima deseada; si la nota de arriba crece, el margen empuja a la de abajo en vez de solaparla. En pantallas angostas los márgenes desaparecen y las notas se apilan debajo del teléfono, en orden de lectura.
El efecto secundario fue el bueno. Como las notas van dentro del prototipo y no en un documento aparte, la reunión dejó de ser una presentación y pasó a ser una lectura: el cliente entra por su cuenta, recorre, entiende el razonamiento, y llega a la llamada con preguntas en vez de con dudas. Escribir la nota también me obliga a mí: si no puedo defender un cambio en cuatro líneas, probablemente el cambio no está listo.
comentar sobre el píxel
El cliente pidió una cosa muy concreta y muy razonable: poder dejar feedback sin tener cuenta de Figma y sin que se pierda en un chat. Así que construí comentarios posicionales dentro del propio laboratorio.
En cualquier prototipo hay un botón flotante. Por defecto el prototipo está limpio —los pins escondidos, sin ensuciar el diseño— y el botón muestra cuántos hilos hay. Al activarlo aparecen todos los pins, y un click sobre la pantalla clava uno nuevo justo ahí. Cada pin es un hilo: se abre, se responde, se marca como resuelto —el pin se atenúa— y se puede arrastrar para reubicarlo. Quien comenta solo deja su nombre; el email es opcional. No hay registro, no hay login, no hay invitación que aceptar.
Por debajo es una única tabla en Supabase con Row Level Security: lectura abierta, inserción validada por longitud, y las respuestas modeladas en la misma tabla apuntando al comentario raíz. La decisión de diseño que más me gusta de todo el sistema es también la menos visible: las coordenadas del pin no se guardan en píxeles, se guardan en porcentaje del marco del prototipo. Por eso el mismo comentario cae en el mismo punto relativo tanto si lo abrís en un escritorio, donde el prototipo vive en un marco de 420 px, como en un teléfono, donde ocupa todo el ancho. Un pin en píxeles se habría despegado del elemento que señala en cuanto alguien cambiara de pantalla.
Yo lo leo todo desde un tablero aparte, agrupado por proyecto y por opción, con las respuestas anidadas y un contador de lo nuevo desde la última visita. El laboratorio publicado además está detrás de una clave que corre en el edge, antes de servir nada: quien no la tiene ni siquiera descarga el JavaScript, y si falta la configuración el sitio falla cerrado en vez de destapar los prototipos.
iterar en abierto
El circuito quedó así: rama, cambio, deploy de preview automático, link al cliente, comentario clavado en la pantalla, merge. Entre mayo y agosto de 2026 eso fueron 274 commits y unas 114 pull requests, con varias exploraciones abiertas en paralelo cuando había que comparar caminos.
Lo más honesto de trabajar así no son los aciertos, son las vueltas atrás, y quedan todas registradas. Hubo un capítulo del flujo que el cliente pidió por la mañana y retiró el mismo día. Hubo una opción descartada que volvimos a hacer visible semanas después, porque el problema cambió de forma. Hubo copys de la búsqueda con IA que tuve que neutralizar para que en ningún caso pudieran leerse como «recomendación» o «asesoría». Y hubo una revisión legal que reescribió una pantalla entera: la app dejó de sugerir un nivel de riesgo y pasó a describir el que está seleccionado, se subió la caída posible a la tarjeta cerrada para que el trade-off se viera sin expandir nada, y se añadió una confirmación explícita antes de invertir.
Ese último cambio es exactamente el prototipo que se puede tocar más arriba en este caso.
del lab a la app
En agosto el laboratorio dejó de ser el final del camino. Los flujos que ya estaban resueltos empezaron a graduarse a una segunda aplicación construida en Ionic y Angular —el stack real del producto— corriendo la verificación de identidad de Metamap de verdad y los datos que exige Alpaca como custodio.
Son dos aplicaciones con propósitos distintos y no comparten código: el laboratorio compara opciones, la app corre una sola versión como correría la de producción. Lo único que comparten son los tokens, duplicados a propósito. Y la regla es de una sola dirección: primero el lab, después la app. Nada se porta antes de estar resuelto.
Dos ejemplos de lo que cambió por el camino. El onboarding del producto de ahorro pasó de cinco pantallas a una sola, con la única decisión que de verdad hace falta —la moneda— arriba del todo. Y la apertura de cuenta, que hoy son cinco pasos y más de cincuenta pantallas contando una sola rama, quedó recortada a quince turnos en seis capítulos: la validación de identidad se mudó al primer capítulo para que falle temprano en vez de a los treinta pasos, y el escaneo del documento rellena los datos en vez de hacer que la persona los teclee.
Ese segundo caso trae además la decisión de la que más orgullosa estoy, y es una pantalla que decidí borrar. El estado «solicitud en revisión» dura horas o días; una pantalla de cierre se lee una vez y queda atrás. Lo que le falta a la persona tiene que vivir donde vuelve, que es el inicio.
lo que me llevo
- Auditar es diseñar. Las horas que pasé leyendo tokens exportados —encontrando typos, rejillas que mentían y sombras de otra paleta— valieron más que cualquier pantalla nueva. No se puede construir encima de un sistema en el que nadie confía.
- Documentar el defecto en vez de taparlo. Si la doc corrige lo que Figma no corrige, la doc empieza a mentir el día que se escribe. Preservé los typos con una nota al lado, y el archivo siguió siendo verdad.
- Una propuesta no es una decisión. Construir varias opciones cuesta más, pero convierte la conversación: se deja de discutir gustos y se empieza a comparar comportamientos. Y descartar con el prototipo andando deja un registro que una imagen no deja.
- La argumentación va pegada a la pantalla. Las notas al margen hicieron que el cliente pudiera recorrer solo y entender el porqué. La reunión dejó de ser una presentación y pasó a ser una conversación.
- El detalle invisible es el que sostiene. Guardar los comentarios en porcentaje y no en píxeles no se ve en ninguna captura, y es lo único que hace que el feedback siga señalando lo que señalaba.
- Todavía estoy en ello. Quedan capítulos por escribir, decisiones por revertir y flujos por graduar. Voy actualizando este caso a medida que pueda contarlo.