Imagina la escena: alguien en una tienda con unos zapatos en la mano se pregunta ¿me alcanza?. Esa pregunta tan cotidiana es, en realidad, el primer caso de uso de tu billetera digital y la pieza que alinea todo el producto alrededor de una necesidad concreta.
Aquí vas a aprender a traducir esa escena en una acción medible: registrar un gasto en menos de 30 segundos usando un solo prompt en tu builder. Es una práctica útil para quienes están construyendo productos digitales con IA y quieren que cada pantalla tenga un propósito claro.
¿Qué es un caso de uso y por qué define tu producto?
Un caso de uso es la unidad mínima que conecta a una persona con tu producto. Sin él, las pantallas se ven bonitas pero no resuelven nada.
La estructura tiene tres partes que debes tener siempre presentes [00:34]:
- La situación que está pasando en la vida de la persona.
- La acción que quiere hacer en ese momento.
- El resultado, es decir, para qué lo hace y qué gana al final.
Si te falta una de estas piezas, el producto se vuelve borroso. Si las tres están claras, tienes una brújula para diseñar.
¿Qué es un caso de uso en diseño de producto? Es la combinación de una situación real, una acción concreta y un resultado esperado. Si puedes nombrar las tres, tienes un caso de uso accionable.
¿Cómo aplicar el caso de uso a las pantallas de la billetera?
El ejercicio concreto de la clase parte de un caso muy específico [01:00]: la situación es que acabas de comprar algo, la acción es registrarlo antes de que se te olvide, y el resultado es saber al final del mes en qué se te fue la plata.
Con ese caso definido, el siguiente paso es alinear las cuatro pantallas de la billetera con un único prompt dirigido al builder. La instrucción pide que el flujo cubra:
- El dashboard principal con los totales.
- La lista de movimientos.
- El detalle de cada movimiento con todos los datos.
- El botón de guardar gasto, clave para recibir la información del usuario, validarla e insertarla en el dashboard.
Un detalle importante: en este punto se pide el recorrido visual completo, pero todavía sin guardar nada en la base de datos. Eso te permite iterar la interfaz sin ensuciar tu modelo de datos.
¿Cómo se ve la prueba de los 30 segundos?
Una vez el modelo termina, llega lo que en la clase llaman la prueba de oro [02:09]. Se agrega un nuevo gasto real para validar que el flujo funciona.
El ejemplo concreto es registrar la suscripción a Platzi por $179 000 COP, categorizarla como servicio y confirmar el gasto. Tras hacerlo, el dashboard incrementa el total a $734 950, y al entrar al detalle del nuevo movimiento aparece la hora exacta del registro, la categoría y el método de pago (este último inventado por el modelo, lo cual ya te da una pista de qué afinar después).
Si el camino se siente claro y se completa en menos de 30 segundos, el caso de uso ya está dirigiendo el producto.
¿Qué detalles puedes añadir para mejorar el flujo?
Mirar las cuatro pantallas alineadas es solo el comienzo. La pregunta que debes hacerte es si hay algo que falta para que ese registro de gasto sea aún más rápido y útil.
Algunas ideas que puedes explorar y pedirle al builder con un nuevo prompt:
- Un texto más claro en el botón de guardar o en los campos del formulario.
- Un campo adicional, por ejemplo, una nota corta para recordar el contexto del gasto.
- Un filtro en la pantalla de movimientos por categoría, fecha o método de pago.
- Un selector predefinido de métodos de pago, para que el modelo no tenga que inventarlos.
¿Cómo mido si mi caso de uso funciona? Cronometra a un usuario real haciendo la acción central. Si la completa en el tiempo objetivo (en este caso, 30 segundos), tu caso de uso está dirigiendo bien el producto.
Cada ajuste que añadas debería responder a la misma pregunta: ¿esto hace que la persona registre su gasto más rápido y con menos fricción? Si la respuesta es sí, vale la pena. Si no, probablemente sea ruido visual.
Cuéntame en los comentarios qué detalles agregaste a tu billetera y por qué los consideraste importantes para tu caso de uso.
