Casos de uso: escenarios completos de interacción con el sistema
Un caso de uso describe paso a paso cómo un actor logra un objetivo con el sistema, con sus flujos alternativos. Qué lleva, cómo se escribe y cuándo usarlo.
¿Qué es un caso de uso?
Es un documento que describe una interacción completa. Su pieza central es el flujo principal, la secuencia de pasos en la que todo sale bien. Alrededor de ese flujo se escriben las condiciones que tienen que cumplirse antes de empezar, los resultados que quedan después y las excepciones.
El formato viene de la ingeniería de software, pero es útil en diseño de producto cuando hay muchos caminos posibles. La referencia clásica es el libro Writing Effective Use Cases de Alistair Cockburn (2001). Una especificación típica incluye una descripción breve, el flujo principal, los flujos alternativos, las precondiciones y las postcondiciones, según el template de RUP (RUP, “Use Case Specification”).
¿Qué lleva un buen caso de uso?
Una plantilla práctica para producto suele incluir:
- Identificador y nombre. Un verbo y un objeto: «Pagar una factura».
- Actores. El actor principal, que persigue el objetivo, y los secundarios, como un servicio de pagos.
- Disparador. Lo que inicia el caso: un clic, una fecha, un mensaje que llega.
- Precondiciones. Lo que tiene que ser cierto antes de empezar: el usuario ha iniciado sesión, tiene una tarjeta guardada.
- Flujo principal. La secuencia de pasos en la que todo sale bien, escrita como diálogo entre actor y sistema.
- Flujos alternativos. Los caminos que se apartan del principal.
- Postcondiciones. Lo que queda al terminar: la factura está marcada como pagada, llega un correo.
El template de RUP añade además requisitos especiales (por ejemplo, de rendimiento o de accesibilidad) y puntos de extensión. Visual Paradigm usa un ejemplo de «Place Order» (realizar pedido) con la precondición «User is logged in», un flujo principal de cinco pasos y la postcondición «Order is placed successfully» (Visual Paradigm, “Use Case Guide”).
¿Por qué le importa a un diseñador?
Porque casi todo el valor de un caso de uso está en los flujos alternativos. El camino feliz lo conocen todos. Lo que se olvida es el pago rechazado, la sesión que caduca a mitad de un formulario o el usuario que no tiene el dato que le pedimos.
Featurebase lo resume bien: la historia de usuario es breve y se centra en el resultado, mientras que el caso de uso es detallado y cubre variantes y errores (Featurebase, “Use case vs user story”). Esa diferencia importa cuando alguien tiene que implementar o probar el comportamiento.
| Historia de usuario | Caso de uso | |
|---|---|---|
| Nivel de detalle | Visión general centrada en el resultado | Interacciones paso a paso entre usuario y sistema |
| Cubre | El escenario principal de éxito | Camino feliz, alternativas y errores |
| Sirve para | Planificar y priorizar | Documentar, implementar y probar comportamiento complejo |
Un caso de uso también te obliga a nombrar al actor y a la precondición. Muchas pantallas que parecían obvias se revelan como casos distintos cuando alguien escribe quién hace qué y en qué estado.
¿Cómo se escriben los flujos alternativos?
El template de RUP dice que las alternativas simples pueden escribirse dentro del flujo de eventos, y que las complejas merecen una subsección propia. Además, establece que, cuando un flujo alternativo termina, se retoma el flujo principal, salvo que se indique lo contrario (RUP, “Use Case Specification”).
En la práctica, pregúntate en cada paso del flujo principal: ¿qué puede hacer el actor aquí que no sea lo esperado? ¿qué puede fallar? Cada respuesta es un flujo alternativo, con su propio final.
Ejemplo
Ejemplo ilustrativo: un caso de uso «Pagar una factura» en una app bancaria. El flujo principal tiene cinco pasos: elegir factura, confirmar importe, seleccionar cuenta, autorizar con huella y ver el comprobante. Los flujos alternativos son tres: saldo insuficiente (el sistema ofrece otra cuenta o cancelar), huella no reconocida (se pide el PIN) y pago que tarda más de diez segundos (se muestra estado «en proceso» y se notifica al terminar). Con eso escrito, el diseñador ya sabe que hacen falta cuatro pantallas de error, un estado intermedio y un aviso posterior. Nada de eso aparecía en el mockup del camino feliz.
¿Cuándo NO conviene usarlo?
- Para un producto simple o una funcionalidad pequeña. Un caso de uso de tres pasos es papeleo. Una historia de usuario o un boceto basta.
- Cuando el equipo no los va a leer. Un documento que nadie consulta se desactualiza sin que nadie lo note.
- Como sustituto de investigación. El caso describe cómo debería ocurrir, no cómo ocurre. Valídalo con entrevistas de usuario o observación.
- Para describir la interfaz. Un caso de uso dice qué pasa, no cómo se ve. Para eso están los wireframes y los flujos de usuario.
Errores comunes
- Escribir el flujo principal con detalles de interfaz: «el usuario hace clic en el botón azul».
- Olvidar las precondiciones, por ejemplo que el usuario tiene sesión iniciada.
- Dejar los flujos alternativos sin final: no decir cómo vuelve el caso o cómo termina.
- Crear un caso por pantalla en vez de uno por objetivo del usuario.
- Actualizar el mockup y no el caso de uso, o al revés.
Cómo empezar mañana
Elige una tarea de tu producto que tenga pagos, permisos o formularios largos, donde los errores cuesten caro. Escribe el flujo principal en seis pasos como máximo, en forma de diálogo: «El usuario elige…», «El sistema muestra…». Después recorre cada paso y anota qué puede salir mal. Con esa lista tendrás los flujos alternativos. Si la tarea también necesita una historia para planificar, el formato de job stories te ayuda a entender la situación antes de describir el comportamiento.