Una idea suele llegar como una solución: «quiero una app», «necesito una web» o «podríamos añadir inteligencia artificial». El primer trabajo de diseño consiste en retroceder un paso y entender qué está intentando hacer la persona que la usará. Una pantalla bonita puede ayudar, pero no sustituye a una necesidad bien definida.
1. Escribir el problema antes de dibujar la solución
Imagina una pequeña academia que recibe solicitudes de clases por distintos canales. El problema no es necesariamente que le falte una aplicación. Quizá nadie sabe qué solicitudes están pendientes y se repiten preguntas sobre horarios. Este es un ejemplo hipotético, pero permite hacer preguntas concretas: ¿quién recibe la consulta?, ¿qué información necesita?, ¿cuándo se considera resuelta?
Una frase de partida útil sería: «La persona que coordina las clases necesita ver las solicitudes pendientes para responder sin revisar varias conversaciones». Ya tenemos una persona, una tarea y una dificultad. Es una base mucho más precisa que una lista de funcionalidades.
2. Recortar el primer recorrido
Elige una sola tarea que merezca la pena probar de principio a fin. En la academia podría ser solicitar una clase y recibir una confirmación. Quedan fuera, de momento, los pagos, las estadísticas y los programas de fidelización. No desaparecen del proyecto: se guardan como decisiones futuras.
- Entrada: la persona encuentra una clase disponible.
- Acción: elige un horario y deja los datos imprescindibles.
- Resultado: ve qué ha solicitado y cuál será el siguiente paso.
- Excepción: el horario ya no está disponible o falta información.
3. Dar forma a las decisiones
Primero dibuja bloques: información, acción principal y resultado. Después convierte ese esquema en pantallas conectadas. Un prototipo no necesita una base de datos real para mostrar si el recorrido se entiende. Sí necesita textos creíbles y estados que representen lo que puede ocurrir, incluida una solicitud que no se puede completar.
El nivel de detalle debe responder a la pregunta de la prueba. Para comprobar el orden de los pasos bastan bocetos sencillos. Para evaluar si un botón se reconoce o si un mensaje resulta claro, conviene acercarse más a la interfaz final.
4. Observar una tarea, sin explicar la interfaz
Plantea una situación: «Quieres reservar una clase para la semana que viene». Deja que la persona intente resolverla y observa dónde duda, qué espera que ocurra y qué interpreta al terminar. Evita indicarle dónde pulsar: esa ayuda ocultaría precisamente lo que necesitas descubrir.
Anota hechos antes que conclusiones. «No vio el selector de horario» es más útil que «el diseño no funciona». Después ajusta una decisión concreta y vuelve a probarla. El prototipo es una herramienta para aprender, no una promesa de que el producto ya está construido.
5. Preparar el paso al desarrollo
Antes de programar, reúne las pantallas, los estados, los datos necesarios y las reglas que todavía generan dudas. Define también una señal de éxito: por ejemplo, completar la solicitud sin ayuda y comprender si está confirmada o pendiente. Esa claridad permite construir una primera versión pequeña y evaluar si resuelve el problema que la originó.