34. Casos de uso y prototipos de interfaz

34.1 Introducción

Los casos de uso describen cómo un actor interactúa con el sistema para lograr un objetivo. Los prototipos de interfaz muestran una posible forma visual de realizar esa interacción.

Ambos elementos se complementan. El caso de uso explica el comportamiento esperado; el prototipo ayuda a visualizar pantallas, datos, mensajes, decisiones y recorrido del usuario.

Un prototipo no reemplaza al caso de uso, y un caso de uso no define por sí solo el diseño visual final. Juntos permiten validar si el flujo es comprensible, completo y usable.

34.2 Qué es un prototipo de interfaz

Un prototipo de interfaz es una representación preliminar de cómo podría verse o funcionar una pantalla, formulario, flujo o interacción. Puede ser de baja fidelidad, como un boceto simple, o de alta fidelidad, con diseño visual más detallado.

Su objetivo principal es explorar y validar ideas antes de construir la solución definitiva. Permite detectar problemas de comprensión, información faltante o pasos innecesarios.

34.3 Relación con casos de uso

El caso de uso indica qué debe ocurrir. El prototipo muestra una posible manera de hacerlo. Por ejemplo, si el flujo principal dice que el paciente selecciona especialidad, profesional y horario, el prototipo puede mostrar cómo se organizarán esas selecciones en la interfaz.

Esta relación permite revisar si la interfaz realmente facilita el objetivo del actor.

34.4 Del caso de uso al prototipo

Un caso de uso puede guiar la construcción del prototipo. Los pasos del flujo principal sugieren pantallas o estados de interfaz; los datos de entrada indican campos o selecciones; los mensajes del sistema sugieren confirmaciones, advertencias y errores; las alternativas muestran decisiones que el usuario puede tomar.

34.5 Qué información aporta el caso de uso al prototipo

El caso de uso aporta información clave para diseñar el prototipo:

• Actor principal y objetivo.
• Flujo principal de eventos.
• Datos de entrada necesarios.
• Datos de salida esperados.
• Mensajes de confirmación, error y advertencia.
• Flujos alternativos y decisiones del usuario.
• Reglas de negocio que condicionan la interfaz.
• Requisitos no funcionales de usabilidad, accesibilidad o seguridad.

34.6 Qué aporta el prototipo al caso de uso

El prototipo también puede mejorar el caso de uso. Al visualizar el flujo, pueden aparecer preguntas o problemas que no estaban claros en el texto.

Por ejemplo:

• Falta un dato para completar la reserva.
• Un mensaje de error no explica cómo continuar.
• Hay demasiados pasos para una tarea frecuente.
• Una regla de negocio necesita mostrarse antes de confirmar.
• Un flujo alternativo no estaba documentado.

34.7 Prototipos de baja fidelidad

Los prototipos de baja fidelidad son bocetos simples. Pueden hacerse en papel, pizarra o herramientas básicas. Sirven para discutir estructura, pasos y contenido sin distraerse con colores, tipografías o detalles visuales finales.

Son útiles en etapas tempranas, cuando todavía se está validando el flujo del caso de uso.

34.8 Prototipos de alta fidelidad

Los prototipos de alta fidelidad se parecen más al producto final. Pueden incluir estilos visuales, componentes reales, interacción navegable y mayor precisión en textos.

Son útiles cuando el flujo ya está bastante definido y se necesita validar experiencia de usuario, accesibilidad, mensajes, jerarquía visual o presentación de datos.

34.9 Ejemplo: Solicitar turno

Para el caso de uso Solicitar turno, el prototipo podría incluir:

• Pantalla de búsqueda por especialidad, profesional o fecha.
• Lista de horarios disponibles.
• Resumen de la reserva antes de confirmar.
• Mensaje de confirmación.
• Mensaje cuando no hay horarios disponibles.
• Opción para modificar la búsqueda.

Estos elementos surgen directamente del flujo principal, alternativas, datos y mensajes del caso de uso.

34.10 Validación con usuarios

Un prototipo permite validar el caso de uso con usuarios de manera más concreta. Muchas personas comprenden mejor un flujo cuando pueden verlo o interactuar con él.

Durante la validación, conviene observar si el usuario entiende qué hacer, si encuentra la información necesaria, si los mensajes son claros y si el resultado coincide con sus expectativas.

34.11 Prototipos y flujos alternativos

Los prototipos no deben mostrar solo el camino ideal. También conviene representar alternativas importantes, como búsqueda por profesional, cambio de fecha antes de confirmar o cancelación de la operación.

Si una alternativa es importante para el usuario, debería poder verse o simularse en el prototipo.

34.12 Prototipos y excepciones

Los errores también deben considerarse. Un prototipo puede mostrar cómo se informa que no hay horarios disponibles, que un dato es inválido o que una reserva no pudo completarse.

Esto ayuda a validar mensajes de recuperación antes de desarrollar la funcionalidad.

34.13 Prototipos y datos

El prototipo debe mostrar datos representativos. Usar datos realistas ayuda a descubrir problemas de longitud, formato, comprensión y privacidad.

Por ejemplo, mostrar fecha, hora, profesional, sede y código de reserva permite comprobar si la confirmación del turno es clara para el paciente.

34.14 Prototipos y requisitos no funcionales

Algunos requisitos no funcionales pueden explorarse desde el prototipo, especialmente usabilidad, accesibilidad y claridad de mensajes.

Por ejemplo, si el caso de uso debe poder completarse desde un teléfono móvil, el prototipo debe revisarse en una vista móvil. Si debe ser accesible, hay que cuidar contraste, etiquetas, foco y navegación.

34.15 Diferencia entre prototipo y especificación final

Un prototipo puede cambiar. No siempre representa la implementación final. Su función es aprender, validar y comunicar.

El caso de uso debe mantenerse como referencia funcional. Si el prototipo revela cambios en el comportamiento, la especificación del caso de uso debe actualizarse para mantener coherencia.

34.16 Ejemplo de relación

La siguiente tabla muestra cómo se relacionan partes del caso de uso con elementos del prototipo:

34.17 Errores frecuentes

Al relacionar casos de uso y prototipos, suelen aparecer estos errores:

• Diseñar pantallas sin revisar el objetivo del caso de uso.
• Crear prototipos que solo muestran el camino ideal.
• No representar mensajes de error o recuperación.
• Incluir campos que no aparecen en el caso de uso ni en reglas de negocio.
• No actualizar el caso de uso cuando el prototipo cambia el comportamiento.
• Confundir el prototipo con una especificación técnica completa.
• No validar el prototipo con usuarios reales o representantes del negocio.

34.18 Lista de revisión

Antes de cerrar un prototipo relacionado con un caso de uso, conviene revisar:

• ¿El prototipo permite cumplir el objetivo del actor?
• ¿Representa los datos de entrada y salida importantes?
• ¿Incluye mensajes de confirmación, error y advertencia relevantes?
• ¿Considera flujos alternativos importantes?
• ¿Muestra recuperación ante excepciones críticas?
• ¿Respeta reglas de negocio conocidas?
• ¿El caso de uso y el prototipo están actualizados entre sí?

34.19 Qué debes recordar de este tema

• El caso de uso describe comportamiento; el prototipo lo visualiza.
• El prototipo ayuda a validar flujo, datos, mensajes y decisiones.
• Los prototipos pueden ser de baja o alta fidelidad.
• Un prototipo no reemplaza la especificación del caso de uso.
• El caso de uso debe actualizarse si el prototipo revela cambios funcionales.
• También deben prototiparse alternativas y errores importantes.
• La combinación de ambos mejora la comunicación con usuarios y equipo técnico.

34.20 Conclusión

Los casos de uso y los prototipos de interfaz se refuerzan mutuamente. El caso de uso aporta estructura funcional; el prototipo aporta visualización y validación práctica.

Usarlos juntos permite detectar problemas antes de construir, mejorar la experiencia del usuario y mantener coherencia entre comportamiento esperado e interfaz propuesta. En el próximo tema estudiaremos la relación entre casos de uso y modelado de dominio.