# Revisión de usabilidad

Recorre paso a paso una tarea real sobre una interfaz y reporta qué no puede saber o no puede hacer quien la usa — con la evidencia detrás de cada hallazgo.

## Entregable

Un documento Markdown, `usability-review.md`, con la estructura fijada en **Salida** más abajo. Recorre el flujo que describe **Especificación de flujos de usuario**, y sus hallazgos alimentan la siguiente revisión de ese documento.

## Entradas obligatorias

- **Una interfaz que se pueda operar**, en el estado en el que está de verdad y no en el que debería alcanzar.
- **La tarea que la persona usuaria debe completar en ella**, y quién es esa persona.
- **El conjunto de heurísticas contra el que se hace la revisión**, nombrado para que cualquiera pueda contrastar un hallazgo.

Si falta la tarea, detente y repórtalo. Una interfaz revisada sin tarea produce una lista de preferencias; la tarea es lo que convierte una preferencia en un fallo.

## Entradas opcionales

- Grabaciones o notas de personas intentando la tarea
- Registros de soporte y las preguntas que se repiten
- Analítica que muestre dónde se detienen los intentos
- La especificación a partir de la cual se construyó la interfaz
- Los dispositivos, métodos de entrada y condiciones en los que se hace la tarea
- Revisiones anteriores y qué cambió después de ellas

Sin observación esto es una inspección experta, y cada hallazgo lo dice. Una entrada ausente baja lo que un hallazgo puede afirmar; nunca convierte un juicio en una observación.

## Ejecución

**1 — Fijar la tarea, la persona y el punto de partida.** Dónde empieza el intento, qué sabe la persona al llegar, qué cuenta como completar y qué contaría como rendirse. Una revisión que empieza dentro del producto se salta el paso en el que se pierden la mayoría de los intentos.

**2 — Intentar la tarea, un paso cada vez.** En cada paso registra qué muestra la interfaz, qué hay que decidir y qué cuesta esa decisión en atención o en escritura. Registra tanto los pasos que funcionan como los que no.

**3 — En cada paso, preguntar qué no se puede saber.** Dónde se está, qué acaba de pasar, qué pasará si se sigue, si se puede deshacer y si el sistema está haciendo algo. Cada una de estas preguntas sin respuesta en ese paso es un hallazgo.

**4 — Intentar los fallos.** Entrada incorrecta, permiso ausente, conexión perdida, una interrupción y una vuelta. Una tarea es tan usable como sus caminos de fallo, y ahí es donde una interfaz sin revisar abandona a quien la usa.

**5 — Escribir cada hallazgo contra una heurística.** El paso, la heurística que incumple, qué no se puede saber o no se puede hacer, y la evidencia: qué se vio hacer a alguien, o qué se juzgó por inspección. Un hallazgo sin heurística es una preferencia con un párrafo alrededor.

**6 — Fijar la gravedad por impacto, no por irritación.** Cuánta de la gente que hace esta tarea llega a ese paso, si bloquea el final o solo lo ralentiza, si existe una vía alternativa y si se podría encontrar sin que nadie la explique.

**7 — Separar observación de juicio.** Etiqueta cada hallazgo como `observado` o `inspeccionado`. Por cada `inspeccionado`, nombra la observación que lo confirmaría o lo tumbaría. Nunca dejes que un hallazgo de inspección se lea como algo que se vio hacer a la gente.

## Salida

`usability-review.md`, en este orden:

- **1. Tarea, persona y fecha** — qué tarea se revisó, para quién es y dónde empezó el intento
- **2. Método** — inspección u observación, el conjunto de heurísticas usado y las condiciones del intento
- **3. Recorrido** — por paso: qué mostró la interfaz, qué hubo que decidir y qué costó
- **4. Hallazgos** — por hallazgo: paso, heurística, qué no se puede saber o hacer, evidencia, `observado` o `inspeccionado`
- **5. Gravedad** — por hallazgo: quién llega a él, si bloquea o ralentiza, si hay vía alternativa y si se encuentra
- **6. Caminos de fallo** — qué hace la interfaz cuando la tarea sale mal y qué se puede hacer entonces
- **7. Recomendaciones** — por hallazgo: el cambio propuesto y qué no debe romper ese cambio
- **8. Qué lo resolvería** — cada hallazgo `inspeccionado` con la observación que lo confirmaría o lo tumbaría
- **9. Información que falta** — qué no se pudo intentar y quién puede desbloquearlo

## Validación

El informe está listo cuando se cumple todo esto:

- Cada hallazgo nombra un paso de la sección 3 y una heurística del conjunto de la sección 2
- Cada hallazgo está etiquetado como `observado` o `inspeccionado`, y ningún `inspeccionado` se redacta como conducta que se vio tener a la gente
- Cada hallazgo lleva una gravedad con su base registrada
- Cada paso intentado aparece en la sección 3, incluidos los que no dieron hallazgo
- Cada hallazgo `inspeccionado` tiene entrada en la sección 8
- Cada recomendación nombra el hallazgo al que responde

Falla la ejecución si un hallazgo afirma una observación que el método de la sección 2 no sostiene, o si aparece una gravedad sin base registrada.

## Gestión de fallos

- **No hay tarea** — detente. Informa de que no hay nada que recorrer y de que revisar una interfaz sin tarea produce gusto, no hallazgos.
- **Sin observación posible** — haz la revisión por inspección, etiqueta cada hallazgo como `inspeccionado` y lista en la sección 8 la observación que resolvería cada uno.
- **Sin interfaz operable** — revisa solo la especificación y el material de diseño, marca cada hallazgo como `sin intentar` y declara que un paso que nadie recorrió no se ha revisado.
- **Relatos contradictorios del comportamiento previsto** — registra los dos con sus fuentes, revisa el comportamiento construido porque es el que encuentra la persona usuaria, y eleva la contradicción a la sección 9 como bloqueante.
- **Acceso parcial** — revisa los pasos que se puedan intentar, marca el resto como `SIN REVISAR — <motivo>` y declara que un paso sin revisar no es un paso que funcione.