UI/UX & Design — Habilidades

Especificación de flujos de usuario

Convierte una tarea y las capacidades reales de un sistema en un flujo que alguien puede construir — incluidos todos los estados que suelen quedarse sin dibujar.

Entregable

Un documento Markdown, user-flow-specification.md, con la estructura fijada en Salida más abajo. Es la entrada de Especificación de textos de interfaz y la referencia que recorre Revisión de usabilidad.

Entradas obligatorias

La tarea que debe completar la persona usuaria — enunciada como un resultado que reconocería, no como una pantalla que debería ver.
Lo que el sistema puede hacer de verdad en ese camino — las operaciones disponibles, qué exige cada una y qué rechaza.
Un responsable con nombre del comportamiento indefinido — quien decide qué ocurre en un estado que nadie ha especificado.

Si falta cualquiera de las tres, detente y repórtalo. Un flujo dibujado sin las capacidades reales del sistema especifica un producto que no existe.

Entradas opcionales

Pantallas existentes, wireframes o una interfaz construida de la que leer el camino actual
El modelo de permisos: quién puede hacer qué y qué ocurre cuando no puede
Las respuestas de error y de estado que devuelve el sistema, con las condiciones que las disparan
Registros de soporte o analítica que muestren dónde se detienen hoy los intentos
Restricciones de contenido, legales o regulatorias sobre lo que un paso puede pedir o decir
Los dispositivos, métodos de entrada y condiciones de conexión en los que el flujo debe funcionar

Cada entrada opcional que falte pasa a Estados indefinidos. Nunca se convierte en un comportamiento inventado.

Ejecución

1 — Fijar los límites. Registra cada punto de entrada al flujo — de dónde llega la persona y qué sabe ya al llegar — y cada salida: finalización, abandono y expulsión por parte del sistema. Un punto de entrada que no se puede nombrar es un punto de entrada para el que nadie ha diseñado.

2 — Recorrer el camino que funciona. Una línea por pantalla o estado, en orden: qué ve la persona, qué puede hacer ahí, qué hace el sistema en respuesta y qué cambia como resultado. Tómalo solo del material aportado; un paso que nadie describió es un paso que va a la lista de lo que falta.

3 — Marcar los puntos de decisión. Por cada bifurcación: qué se decide ahí, la condición que lo determina y adónde lleva cada resultado. Una bifurcación cuya condición no se aportó se registra como condición desconocida y sigue adelante.

4 — Especificar los estados de cada paso. Vacío, en carga, error, permiso denegado y éxito parcial, paso por paso. Cada uno se especifica o se marca no puede ocurrir con el motivo por el que no puede. Un paso que no lleva ninguno de los cinco no se ha examinado.

5 — Trazar los caminos de vuelta. Volver atrás, recargar, entrar a mitad del flujo desde un enlace, retomar un intento abandonado, volver tras una expiración y ejecutar el flujo dos veces. Registra qué hace el sistema con el trabajo ya empezado.

6 — Nombrar lo indefinido. Cada estado alcanzado en los pasos 2 a 5 sin comportamiento definido, con quién debe decidirlo y qué bloquea. Esta lista es el valor principal del entregable; no la acortes eligiendo un comportamiento.

7 — Registrar de qué depende el flujo. Las operaciones del sistema, los permisos, el contenido y los datos que necesita cada paso, y cuáles de ellos se confirmaron en lugar de suponerse.

Salida

user-flow-specification.md, en este orden:

1. Tarea y fecha — qué tarea completa este flujo y cuándo se especificó
2. Puntos de entrada y salidas — por entrada: de dónde llega la persona y qué sabe; por salida: cómo termina el flujo
3. Pasos — por paso: qué se ve, qué se puede hacer, qué hace el sistema, qué cambia
4. Puntos de decisión — la bifurcación, la condición que la determina y el destino de cada resultado
5. Estados — por paso: vacío, en carga, error, permiso denegado, éxito parcial; cada uno especificado o marcado no puede ocurrir con su motivo
6. Vuelta y reentrada — atrás, recarga, llegada a mitad del flujo, retoma, expiración, repetición
7. Estados indefinidos — el estado, quién debe decidirlo, qué bloquea
8. Dependencias — qué necesita cada paso del sistema, del contenido y de los datos, marcado confirmado o supuesto
9. Información que falta — qué no se pudo especificar y quién puede aportarlo

Validación

La especificación está lista cuando se cumple todo esto:

Cada paso de la sección 3 tiene entrada para los cinco estados de la sección 5
Cada estado de la sección 5 está especificado o marcado no puede ocurrir con un motivo
Cada bifurcación de la sección 4 nombra su condición y un destino por resultado
Cada camino lleva a una salida de la sección 2 o a una entrada de la sección 7
Ningún paso especifica una operación que las capacidades aportadas no incluyen
La sección 7 no está vacía, o declara explícitamente que no queda nada indefinido

Falla la ejecución si a un paso le falta la entrada de algún estado, o si el flujo especifica un comportamiento que nunca se reportó del sistema.

Gestión de fallos

No hay tarea — detente. Informa de que un flujo no tiene nada que secuenciar y de que una lista de pantallas no es una tarea.
Capacidades del sistema desconocidas — especifica el flujo con el material aportado, marca cada paso como sin verificar y lista en la sección 9 qué resolvería confirmarlas. Un flujo apoyado en capacidades supuestas es una propuesta.
Relatos contradictorios de un paso — registra los dos, nombra ambas fuentes y eleva la contradicción a la sección 9 como bloqueante. No la resuelvas eligiendo.
Sin acceso a la interfaz construida — la sección 3 queda solo como reportado. Declara que no se observó nada y que cada estado de la sección 5 es por tanto una especificación y no una descripción.
Material parcial — especifica cada paso que el material sostenga, marca el resto como INCOMPLETO — pendiente de <pregunta> y entrega. La lista de indefinidos es el objetivo del documento, no un defecto suyo.

Descargar .md

Auditoría de sistema de diseño

Inventaría con qué está construida de verdad una interfaz y reporta la distancia entre eso y el sistema que dice documentar.

Entregable

Un documento Markdown, design-system-audit.md, con la estructura fijada en Salida más abajo. Se lee junto a Auditoría de accesibilidad y es la entrada de cualquier consolidación posterior.

Entradas obligatorias

Acceso a aquello con lo que está construida la interfaz — hojas de estilo, código de componentes o los archivos de diseño de los que sale la construcción. Algo de lo que se pueda leer un valor.
El sistema documentado, o la declaración de que no existe — la deriva se reporta contra una referencia, y una referencia que nadie enunció no lo es.
El límite de la auditoría — qué producto, qué superficies y qué rama entran.

Si falta el acceso, detente y repórtalo. Un inventario armado con capturas o de memoria registra impresiones, no valores.

Entradas opcionales

Definiciones de tokens, variables o temas, estén donde estén declaradas
Datos de uso que muestren qué componentes se renderizan y con qué frecuencia
La salida de la construcción o un grafo de dependencias que muestre qué importa qué
Los temas, plataformas y densidades que el sistema debe cubrir
Auditorías anteriores y las decisiones que produjeron
Las personas que mantienen el sistema y lo que ya saben que está mal

Las entradas opcionales ausentes reducen lo que la auditoría puede afirmar, no cómo reporta. Un componente cuyo uso no se puede contar se registra como uso desconocido, nunca como sin usar.

Ejecución

1 — Fijar y registrar el límite. Lista los archivos, directorios y archivos de diseño que se leyeron, y los que estaban dentro del alcance pero no se pudieron alcanzar. Todo lo que viene después es una afirmación sobre esa lista y sobre nada más ancho.

2 — Inventariar los valores. Reúne cada valor de color, tipografía, espaciado y radio que aparezca, con el archivo en el que se encontró. Cuenta los valores distintos de cada eje. La cuenta es el hallazgo: un eje con un solo valor y un eje con muchos son problemas distintos.

3 — Separar tokens de casos sueltos. Por cada valor: definido de forma central y referenciado, escrito a mano donde coincide con un token definido, o escrito a mano donde no coincide con nada. Lo segundo es deriva; lo tercero es una incorporación sin documentar. Registra cada sitio donde se usa.

4 — Inventariar los componentes. Nombre, dónde se define, dónde se usa y cuántos usos tiene. Un componente sin usos está muerto. Uno con un solo uso es candidato a absorberse, y se registra así en lugar de condenarse.

5 — Encontrar los duplicados. Componentes que hacen el mismo trabajo con nombres distintos. Por cada pareja o grupo: qué comparten, qué difiere y qué tendría que conservar de cada uno una fusión. Una diferencia que nadie sabe explicar es en sí misma un hallazgo.

6 — Comparar el sistema construido con el documentado. Tres listas: documentado pero no construido, construido pero no documentado, y presente en ambos pero divergente. Donde divergen, el valor construido es el que recibe la gente y se etiqueta así.

7 — Ordenar las candidaturas de consolidación. Ordénalas por cuántos sitios de uso toca el cambio, según las cuentas de los pasos 3 y 4, y declara qué rompería cada una. No recomiendes una fusión cuyo alcance no se pudo contar.

Salida

design-system-audit.md, en este orden:

1. Alcance y fecha — qué se leyó, qué estaba dentro pero fue inalcanzable, y cuándo
2. Inventario de valores — por eje: los valores encontrados, cuántos son distintos y el archivo del que salió cada uno
3. Tokens y casos sueltos — por valor: token, coincidencia escrita a mano o sin documentar, con cada sitio donde se usa
4. Inventario de componentes — nombre, dónde se define, número de usos o uso desconocido, y en uso, uso único o muerto
5. Duplicados — los componentes que hacen un mismo trabajo, qué difiere, qué debe conservar una fusión
6. Deriva — documentado pero no construido, construido pero no documentado, presente en ambos pero divergente
7. Candidaturas de consolidación — ordenadas por sitios de uso afectados, cada una con lo que rompería
8. Información que falta — qué no se pudo contar ni localizar, y quién puede aportarlo

Validación

La auditoría está lista cuando se cumple todo esto:

Cada hallazgo cita el archivo en el que se encontró
Cada valor de la sección 2 está clasificado en la sección 3
Cada componente de la sección 4 lleva un número de usos o uso desconocido
Un valor o componente sin usos se reporta como muerto, no como infracción
La sección 6 nombra la referencia con la que comparó, o registra que no se aportó ninguna
La sección 1 lista lo que quedó fuera de alcance con la misma claridad que lo leído

Falla la ejecución si aparece un hallazgo sin archivo detrás, o si aparece una cuenta que la lectura del material aportado no produjo.

Gestión de fallos

Sin acceso al código fuente — detente. Informa de que no hay nada que inventariar y de que auditar capturas es revisar apariencias.
Sin sistema documentado — produce las secciones 1 a 5 y 7, y marca la sección 6 como sin referencia aportada. Reporta el sistema construido como la referencia de hecho y nombra a quién tendría que adoptarla.
Los archivos de diseño y la construcción no coinciden — registra ambos valores, nombra ambas fuentes y eleva la divergencia a la sección 8. Etiqueta el valor construido como el que recibe la gente; no los promedies.
El uso no se puede contar — marca el componente como uso desconocido y déjalo fuera de la sección 7. Un componente sin contar nunca se reporta como muerto.
Acceso parcial — audita lo alcanzable, marca el resto como SIN AUDITAR — <motivo> y declara que una superficie sin auditar no es una superficie limpia.

Descargar .md

Auditoría de accesibilidad

Prueba una interfaz contra el nivel de conformidad que debe cumplir y reporta a quién excluye cada fallo y cómo.

Entregable

Un documento Markdown, accessibility-audit.md, con la estructura fijada en Salida más abajo. Se lee junto a Auditoría de sistema de diseño, porque la mayoría de los fallos repetidos se definen una sola vez en un componente compartido.

Entradas obligatorias

Una interfaz que se pueda operar — una construcción en marcha, o el código y el material de diseño si no hay nada que ejecutar, declarando cuál de las dos cosas es.
El nivel de conformidad al que se apunta, y quién lo fijó. Un hallazgo es un fallo solo frente a un criterio enunciado.
Qué entra en el alcance — qué pantallas, flujos y estados se van a examinar.

Si no se fijó el nivel, detente y repórtalo. Auditar contra un listón no enunciado produce una lista de opiniones sobre la que nadie tiene que actuar.

Entradas opcionales

Las combinaciones de navegador, plataforma y tecnología de apoyo que el producto se compromete a soportar
Material de diseño que muestre el orden de foco previsto y el estilo previsto de cada estado
El código de los componentes, para atribuir un fallo a donde se define y no a donde aparece
El contenido más largo y el más corto que la interfaz tiene que cargar
Hallazgos anteriores y qué se hizo con ellos
Cualquier declaración de accesibilidad que la organización ya haya publicado

Las entradas opcionales ausentes limitan la cobertura, no el rigor. Lo que no se examinó se reporta como no examinado; nunca como conforme.

Ejecución

1 — Fijar el alcance, el nivel y el método. Registra las pantallas, flujos y estados dentro del alcance, el nivel al que se apunta, el entorno en el que corrió la auditoría y qué no se va a cubrir. Escribe las exclusiones antes que los hallazgos, para que no se caigan en silencio después.

2 — Operar la interfaz solo con teclado. Alcanza cada control, en un orden que corresponda al significado de la página. Comprueba que el foco se ve allí donde cae, que nada lo atrapa, que lo que se abre se puede cerrar y que existe un mecanismo para saltar los bloques repetidos. Registra cada fallo en el control donde ocurre.

3 — Comprobar estructura y nombres. Encabezados con un anidamiento que describa el contenido, regiones que permitan saltar, cada control con un nombre que diga qué hace, cada campo con su etiqueta y cada mensaje de error asociado al campo que lo provocó.

4 — Comprobar lo que transmite significado sin texto. Alternativas textuales para imágenes, iconos y medios; el contraste del texto y de los componentes de interfaz contra lo que tienen detrás; y todo aquello cuyo significado lo lleva solo el color, la posición o la forma.

5 — Comprobar qué cambia con los ajustes de la persona usuaria. Movimiento reducido, tamaño de texto aumentado, zoom de página, orientación cambiada y colores forzados. Registra qué se redistribuye, qué se corta, qué se solapa y qué desaparece.

6 — Escribir cada hallazgo contra un criterio. Dónde está, qué criterio del nivel objetivo incumple, qué hace la interfaz, a qué persona excluye y cómo, la corrección concreta, y si el fallo está en un componente compartido o en un solo sitio.

7 — Separar lo verificado de lo no verificado. Declara qué comprobaciones se hicieron por inspección, cuáles con herramientas y cuáles necesitan pruebas con tecnología de apoyo que aquí no se realizaron. Una comprobación que no se hizo se lista como no hecha, en su propio apartado, nunca dentro de un resultado conforme.

Salida

accessibility-audit.md, en este orden:

1. Alcance, nivel y fecha — qué se auditó, contra qué nivel, en qué entorno y qué quedó excluido
2. Método — qué se comprobó por inspección, qué con herramientas y qué no cubrió ninguna de las dos
3. Hallazgos — por hallazgo: ubicación, criterio, qué falla, a quién excluye y cómo, corrección, y si es compartido o local
4. Cobertura por área — teclado y foco, estructura y nombres, contenido no textual y contraste, formularios y errores, ajustes de la persona usuaria: qué se examinó en cada una y qué no
5. Conforme con condiciones — comprobaciones que solo se sostienen en el entorno probado, cada una con su condición nombrada
6. Sin verificar — las comprobaciones que exigen pruebas con tecnología de apoyo que no se realizaron, y qué resolvería cada una
7. Orden de trabajo — hallazgos ordenados por a quién excluyen y por si la exclusión bloquea la tarea o la entorpece
8. Información que falta — qué impidió una comprobación y quién puede desbloquearla

Validación

El informe está listo cuando se cumple todo esto:

Cada hallazgo nombra una ubicación, un criterio del nivel objetivo y una corrección
Cada hallazgo nombra a la persona que excluye y cómo, no solo la regla que incumple
La sección 2 distingue lo inspeccionado de lo comprobado con herramientas y de lo no cubierto
Ninguna comprobación se reporta como conforme si la sección 2 no la muestra como realizada
Cada comprobación que exige tecnología de apoyo aparece en la sección 6, tenga el aspecto que tenga
La sección 7 ordena los hallazgos por exclusión y no por facilidad de arreglo

Falla la ejecución si un hallazgo no cita criterio, o si se reporta un resultado con tecnología de apoyo cuando esas pruebas no se realizaron.

Gestión de fallos

Sin nivel de conformidad — detente. Informa de que los hallazgos necesitan un listón enunciado y nombra a quién lo fija.
Sin construcción operable — audita el código y el material de diseño, marca cada hallazgo como sin verificar en uso y lista en la sección 6 qué resolvería operar la interfaz.
Sin tecnología de apoyo disponible — resuelve lo que la inspección y las herramientas puedan resolver, lista el resto con nombre en la sección 6 y nunca presentes un resultado de inspección como resultado de lector de pantalla.
Relatos contradictorios del comportamiento previsto — registra los dos con sus fuentes, audita el comportamiento construido porque es el que encuentra la persona usuaria, y eleva la contradicción a la sección 8.
Acceso parcial — audita lo alcanzable, marca el resto como SIN AUDITAR — <motivo> y declara con claridad que una pantalla sin auditar no es una pantalla conforme.

Descargar .md

Especificación de textos de interfaz

Escribe cada cadena que necesita una interfaz — incluidas las de los estados que salen mal — con la clave, el contexto y la mecánica que lleva cada una.

Entregable

Un documento Markdown, ui-copy-specification.md, con la estructura fijada en Salida más abajo. Toma la salida de Especificación de flujos de usuario y es la entrada tanto de la construcción como de la traducción.

Entradas obligatorias

Un inventario de flujo o de pantallas — los estados que necesitan palabras. Las secciones 3 y 5 de user-flow-specification.md son la forma esperada.
Las restricciones de voz del producto — cómo se dirige a quien lee, cuánta formalidad tiene, qué términos debe usar y cuáles no.
Los idiomas en los que se publicarán las cadenas, o la declaración de que solo se prevé uno.

Si falta el inventario, detente y repórtalo. Escribir textos sin una lista de estados produce cadenas para las pantallas que funcionan y silencio para las que fallan.

Entradas opcionales

Restricciones de maquetación que imponen un presupuesto de caracteres a una cadena concreta
Las respuestas de estado y de error que devuelve el sistema, con las condiciones que las disparan
El catálogo de cadenas existente y el esquema de claves que usa
Terminología ya decidida, con quién la decidió
Redacción que debe aparecer literal por motivos legales o regulatorios
Lo que escucha malinterpretar quien atiende las peticiones de soporte

Cuando no se aporta un presupuesto de caracteres, la cadena se escribe corta y se marca presupuesto desconocido. Un presupuesto nunca se inventa, porque quien construye a partir de la especificación lee cualquier cifra como una restricción.

Ejecución

1 — Enumerar los estados que necesitan palabras. Del inventario: cada pantalla y cada estado vacío, en carga, de error, de permiso denegado y de éxito parcial que haya en ella. Un estado que el inventario no define no recibe cadena; va a la lista de lo que falta.

2 — Dar una clave a cada cadena. Estable, estructurada por el sitio donde vive la cadena e independiente de las palabras, para que reescribir no deje huérfana una traducción. Registra a qué estado pertenece cada clave.

3 — Escribir el mobiliario. Títulos, rótulos de sección, etiquetas de campo, textos de ayuda, botones y confirmaciones. Un botón nombra la acción que ejecuta en lugar de concordar con la frase de encima, para que siga teniendo sentido para quien llega a él solo.

4 — Escribir los estados vacíos y de carga. Qué habrá aquí, qué lo trae y qué puede hacer mientras tanto quien lee. Un estado vacío que solo informa de que está vacío desperdicia el único momento en que se busca una instrucción.

5 — Escribir los errores. Qué ha pasado, qué puede hacer a continuación quien lee y a quién preguntar cuando no puede hacer nada. Asocia cada mensaje a la condición o respuesta que lo dispara, y deja fuera del mensaje las causas internas sobre las que nadie puede actuar.

6 — Registrar la mecánica de cada cadena. Las variables y qué las rellena, las formas de plural necesarias, el presupuesto de caracteres cuando la maquetación lo impone, y si la cadena admite recorte o no debe recortarse.

7 — Señalar lo que romperá la traducción. Cadenas montadas a partir de fragmentos, cadenas cuyo sentido depende del orden de las palabras y cadenas que deben concordar en género o número con una variable. Cada una con la nota que necesita quien traduce para resolverla.

Salida

ui-copy-specification.md, en este orden:

1. Entrada y fecha — a partir de qué inventario se escribieron las cadenas y cuándo
2. Restricciones de voz aplicadas — tratamiento, formalidad, términos obligados, términos prohibidos, cada uno con su fuente
3. Cadenas — por cadena: clave, el estado al que sirve, el texto y el contexto que necesita quien traduce
4. Errores — por mensaje: la condición a la que responde, qué ha pasado y qué puede hacer a continuación quien lee
5. Mecánica — por cadena: variables y su origen, formas de plural, presupuesto de caracteres o presupuesto desconocido, comportamiento ante recorte
6. Riesgos de traducción — cadenas que dependen del orden, el género, el número o el montaje, cada una con la nota que necesita quien traduce
7. Estados sin cadena — estados del inventario cuyo comportamiento es indefinido, listados con quién debe decidirlos
8. Información que falta — qué impidió escribir una cadena y quién puede aportarlo

Validación

La especificación está lista cuando se cumple todo esto:

Cada estado del inventario de entrada tiene una cadena o una entrada en la sección 7
Cada cadena lleva clave, el estado al que sirve y el contexto en el que se lee
Cada mensaje de error nombra qué ha pasado y qué se puede hacer a continuación
Cada cadena con variable declara qué la rellena y las formas de plural que necesita
Un presupuesto de caracteres aparece solo donde lo produjo una restricción de maquetación aportada
No existe ninguna cadena para un estado que el inventario no define

Falla la ejecución si aparece una cadena para un estado indefinido, o si aparece un presupuesto de caracteres que ninguna restricción aportada produjo.

Gestión de fallos

Sin inventario de estados — detente. Informa de que no hay contra qué escribir y de que una lista de pantallas sin estados de fallo produce textos solo para el camino que funciona.
Sin restricciones de voz — escribe con sencillez, registra cada elección hecha como suposición en la sección 2 con su fuente anotada como no aportada, y nombra a quién debe confirmarlas.
Respuestas del sistema desconocidas — escribe los mensajes que define el flujo, marca cada uno como respuesta sin asociar en la sección 4 y lista en la sección 8 qué hace falta para asociarlos.
Terminología en conflicto — registra ambos términos y ambas fuentes, no uses ninguno en las cadenas y eleva el conflicto a la sección 8 como bloqueante.
Inventario parcial — escribe para los estados definidos, marca el resto como INCOMPLETO — pendiente de <estado> y entrega. Una cadena inventada para un estado indefinido fija en su sitio el comportamiento equivocado.

Descargar .md

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.

Descargar .md