Diseñar funciones de aplicaciones y flujos de usuario
Publicado el · Actualizado el
Diseñar funciones de aplicaciones empieza por la tarea del usuario y su resultado, junto con los pasos, datos y estados necesarios. Escribe criterios de aceptación antes de implementar y comprueba el recorrido completo, no solo una pantalla.
Define la necesidad y el alcance inicial
Describe una situación concreta. En una aplicación de tareas, alguien puede necesitar asignar trabajo a otra persona y saber si lo aceptó. «Añadir colaboración inteligente» no define el comportamiento requerido. Indica quién inicia, qué sabe al comenzar y qué debe saber al terminar. Identifica el problema actual: responsabilidad confusa, respuesta tardía o historial invisible. Así evitas añadir controles sin resolver la tarea principal. Una necesidad precisa también ayuda a decidir si la función propuesta aporta valor o simplemente agrega pasos al trabajo existente.
Elige una parte pequeña que pueda probarse por separado. La primera versión puede incluir selección de persona, solicitud de asignación, estado pendiente y aceptación o rechazo. Conversación grupal, valoración y calendario no son necesarios solo porque se relacionen con colaboración. Explica la relación con lo existente: ¿cambia inmediatamente el responsable o crea una propuesta pendiente? Define alcance actual, decisiones posteriores y gestión de excepciones. Puedes entregar este resumen a Infera Agent tras comprobar las posibilidades del proyecto y qué requisitos necesitan configuración adicional antes de implementarse.
- Nombra usuario, situación y resultado.
- Identifica un problema observable.
- Delimita una primera versión.
Relaciona el recorrido con los datos
Escribe pasos sencillos: abrir tarea, elegir persona, revisar elección, confirmar solicitud y consultar resultado. Para cada paso define entrada, salida y fuente de información. La lista de personas necesita una fuente clara e identificadores estables, en vez de nombres que pueden repetirse. Decide dónde se guardan tarea y solicitud y quién ve cada elemento. Una visualización no debe describirse como un cambio de datos. Esta diferencia facilita implementación, revisión y uso diario. Cada dato mostrado debe corresponder a una fuente que el equipo pueda reconocer y comprobar.
Define estados anteriores y posteriores. Distingue propuesta, aceptación, retirada y rechazo, y establece cuándo cambia realmente el responsable. El texto no debe anunciar una aceptación inexistente. Explica cómo regresar a la tarea para consultar el estado y qué ocurre si la persona deja de estar disponible o la tarea se cierra antes de responder. Separa notificación y guardado: una solicitud almacenada no prueba la entrega del mensaje. Describe el seguimiento manual si no hay un mecanismo implementado. Así se entienden también los casos que continúan pendientes.
- Define entradas y salidas.
- Usa identificadores estables.
- Distingue estado guardado y mensaje.
Diseña estados normales y excepcionales
Muestra información necesaria para decidir: tarea, responsable actual, persona elegida y consecuencias de confirmar junto a la acción. Nombra la operación real, por ejemplo «Enviar solicitud de asignación» si requiere aceptación. No anuncies la asignación antes de que ocurra. Define qué aparece durante la espera, con una lista vacía o con información ausente. El usuario debe saber si puede continuar, cambiar una elección y consultar después el estado. Revisa los textos junto con la distribución, en lugar de dejarlos para el final del proceso.
Prueba casos que afectan la decisión: responsable ya seleccionado, persona no disponible, tarea cerrada durante la revisión o confirmación repetida. Define resultados antes de decidir la implementación. Ante un fallo conserva entradas útiles y explica el siguiente paso disponible sin anunciar éxito. Comprueba pantallas pequeñas y nombres largos; la información esencial no debe depender de un único color. Si los datos cambian durante la espera, define cómo aparece el nuevo estado y cómo se explica su diferencia respecto al anterior. El usuario necesita comprender qué información sigue siendo válida.
- Nombra la operación real.
- Define espera, vacío y fallo.
- Prueba cambios y confirmación repetida.
Comprueba funcionamiento y utilidad
Convierte el recorrido en criterios verificables: una selección válida crea una solicitud en el estado previsto; aceptar cambia el responsable; rechazar conserva el anterior y muestra el resultado; volver a abrir presenta el estado guardado. «La función funciona» no basta. Relaciona cada criterio con caso, datos y resultado visible. Prueba cuentas de emisor y destinatario cuando exista ese recorrido. Compara pantallas con registros para evitar resultados contradictorios detrás de interfaces convincentes. Define dónde comprobar cada consecuencia y qué información demuestra que el caso terminó correctamente.
Pide a una persona que pruebe la tarea que explique lo entendido antes de confirmar y lo esperado después. Observa dónde se detiene, repite acciones o pregunta por la responsabilidad. Registra comportamientos concretos y modifica su causa. Repite casos principales y recorridos cercanos afectados después de corregir. Guarda resumen, criterios y decisiones pendientes. Revisa uso real antes de ampliar. El éxito práctico es completar la tarea y entender el resultado, no acumular controles ni parecer completo en una captura. Las observaciones ayudan a elegir mejoras según necesidades demostradas.
- Relaciona criterios, casos y resultados.
- Comprueba ambas partes y registros.
- Evalúa comprensión antes de ampliar.
Preguntas
¿Empiezo por pantalla o problema?
Por la situación y el resultado requerido. Define luego pasos y datos. La pantalla apoya ese recorrido y las decisiones que contiene.
¿Cómo elijo la primera versión?
Selecciona el recorrido mínimo que complete la tarea principal y permita revisión. Explica sus relaciones con funciones existentes y pospone añadidos innecesarios.
¿Qué criterio de aceptación es útil?
Uno que relaciona estado, acción y resultado comprobable, como una solicitud guardada y cambio de responsable al aceptar. Evita afirmaciones generales sin datos.
¿Cuándo amplío la función?
Tras comprobar casos habituales, excepciones y comprensión del usuario. Elige añadidos por comportamiento observado, no por una colección de posibilidades sin necesidad identificada.