Diseño centrado en las personas: investigar, prototipar y evaluar

Una oficina quiere reducir los abandonos de una solicitud. El equipo propone simplificar el formulario y prepara una versión con menos campos. En una primera prueba, las personas completan más rápido; en el uso cotidiano, quienes necesitan adjuntar documentos siguen abandonando porque el servicio no explica qué archivo sirve ni permite guardar el avance. La primera prueba no era inútil: respondía a una pregunta más estrecha. El problema apareció cuando se confundió una mejora local con evidencia de que el servicio completo funcionaba.

El diseño centrado en las personas organiza preguntas, decisiones y pruebas alrededor de las actividades reales de quienes usarán, mantendrán, administrarán o sufrirán las consecuencias de un sistema. No es una receta lineal en la que se «descubre» al usuario, se diseña una solución y se obtiene una verdad definitiva. Es un ciclo de hipótesis y comprobaciones: comprender contexto, formular requisitos, hacer alternativas visibles, observar tareas, revisar evidencia y decidir qué queda abierto.

El capítulo 338 situó el desempeño en el acoplamiento entre persona y sistema; el 339 trató ajuste físico y exposición; el 340, exigencias cognitivas. Este capítulo aborda cómo convertir ese conocimiento en decisiones de diseño. No desarrolla la mecánica de controles y alarmas del capítulo 341 ni la coordinación de equipos y turnos del 342. Su pregunta es más transversal: ¿qué hace falta saber, construir y comprobar para poder afirmar que una solución responde a personas diversas en contextos definidos?

Conviene separar tres términos. Preferencia es lo que alguien declara que le gusta, elegiría o considera cómodo. Desempeño es lo que hace y logra bajo una tarea, condición y criterio observables. Evidencia es el apoyo disponible para una afirmación, con un método, una muestra, una incertidumbre y un alcance. Una interfaz puede ser preferida y producir errores; una solución poco atractiva puede permitir completar una tarea; una observación correcta en un laboratorio puede no generalizar al hogar. Diseñar bien exige no convertir una de estas cosas en las otras.

343.1. Comprender contexto y diversidad de usuarios#

Investigar empieza por definir qué actividad se quiere mejorar y quién queda afectado. «Usuario» no es sólo quien pulsa un botón o compra un producto. Puede incluir a quien solicita un servicio, a quien lo presta, a quien mantiene una herramienta, a quien autoriza una decisión y a quien soporta una consecuencia sin haber elegido participar. La frontera depende de la pregunta. Si se diseña una cita médica, paciente, acompañante, personal de recepción, intérprete y quien gestiona los datos pueden encontrar barreras distintas.

El contexto reúne objetivos, recursos, reglas, ambiente, tiempo, relaciones y consecuencias. Una persona puede completar una tarea en una demostración tranquila y no durante un turno con interrupciones, un viaje con conectividad limitada o una emergencia. Observar únicamente el escenario previsto produce una descripción del sistema idealizado. Entrevistar únicamente a quienes lograron acceder produce una población seleccionada por el diseño. Investigar contexto significa buscar también intentos fallidos, abandonos, atajos, ayudas informales y casos excepcionales.

Ejemplo construido. Un municipio estudia un formulario para solicitar una prestación. El equipo entrevista a cinco personas que lo completaron en un ordenador del centro cívico. Aprende que el texto es comprensible, pero no descubre que otras personas comparten teléfono, no pueden reunir un documento durante una sola sesión o prefieren atención presencial por miedo a equivocarse. Una investigación ampliada combinaría observación del trámite, entrevistas a quienes abandonaron, revisión de requisitos y pruebas en dispositivos y lugares distintos. No se trata de sumar opiniones sin límite, sino de cubrir mecanismos de acceso relevantes.

La diversidad no es un catálogo de estereotipos. Edad, idioma, movilidad, visión, audición, aprendizaje, experiencia digital, situación económica o responsabilidades de cuidado pueden cambiar la actividad, pero ninguna categoría predice por sí sola la conducta. Una persona puede pertenecer a varios grupos; una capacidad puede fluctuar; una solución accesible para una persona puede introducir una dificultad para otra. Las categorías ayudan a formular hipótesis de exposición y apoyo, no a sustituir preguntas.

La investigación debe hacer explícito quién tiene poder para definir el problema. Un equipo puede llamar «confuso» a un procedimiento que, en realidad, exige aceptar una condición desfavorable. Las personas afectadas pueden preferir una alternativa que el presupuesto no permite; quienes financian pueden valorar una métrica distinta. Registrar desacuerdos evita convertir la decisión institucional en una supuesta necesidad del usuario. La participación no obliga a aceptar toda propuesta, pero obliga a reconocer quién habló, quién quedó fuera y qué razones decidieron.

Los métodos se eligen por la pregunta. Observación contextual ayuda a conocer secuencias, herramientas y adaptaciones; entrevistas permiten explorar objetivos, recuerdos y explicaciones; análisis de registros descubre demoras y abandonos; encuestas comparan respuestas cuando las preguntas y la muestra lo permiten; pruebas de tareas muestran desempeño bajo condiciones preparadas. Ningún método entrega por sí solo necesidades completas. Una persona puede describir una preferencia sin anticipar su conducta y una métrica puede mostrar una dificultad sin explicar qué la produce.

La ética no es una formalidad posterior. Hay que explicar propósito, duración, uso de datos, grabación, compensación, riesgos y posibilidad de retirarse. Una persona que depende del servicio puede sentir que no puede rechazar participar; una entrevista sobre enfermedad o deuda puede exponer información sensible. El consentimiento no convierte cualquier uso en legítimo. La investigación debe minimizar datos, proteger registros y evitar que una observación perjudique el acceso o la relación de quien participa.

Comprender también significa mapear el recorrido completo. Una persona puede encontrar una barrera antes de iniciar, durante la tarea o después de terminar: no saber que el servicio existe, no poder demostrar identidad, no recibir confirmación o no saber cómo corregir un error. El éxito de la pantalla final no demuestra que el proceso sea accesible. La investigación debe describir entradas, transiciones, espera, recuperación y consecuencias, sin confundir el punto donde se mide con el sistema entero.

343.2. Convertir hallazgos en requisitos verificables#

Un hallazgo es una observación o interpretación situada; un requisito es una condición que una solución debe cumplir. Entre ambos hay una decisión. «Las personas se frustran» no es todavía un requisito: falta saber en qué momento, por qué, con qué consecuencia y qué cambio se propone. «La persona debe poder guardar el avance y retomarlo después de una interrupción sin perder los datos ya validados» es más verificable, aunque todavía necesite definir datos, condiciones y prueba.

La conversión debe conservar la evidencia y la incertidumbre. Una nota de investigación puede registrar que tres participantes confundieron dos términos en una tarea concreta. El requisito no debería declarar que toda la población confundirá esos términos; puede exigir una distinción comprobable, una explicación o una prueba con otras personas. La trazabilidad conecta observación, hipótesis, requisito, alternativa, prueba y decisión. Si una decisión se aparta del hallazgo por coste, seguridad o política, esa razón debe quedar visible.

Los requisitos pueden referirse a resultados, restricciones y condiciones de uso. Un servicio puede exigir que una persona complete una solicitud, que el proceso sea interrumpible, que se ofrezca una alternativa no digital o que la información esté disponible en un formato accesible. Un requisito de diseño no debe dictar una solución antes de conocer el problema: «usar un menú de tres botones» es una opción; «permitir elegir entre tres estados sin memorizar códigos» describe una necesidad que puede resolverse de varias maneras.

Conviene escribir cada requisito con criterio y contexto. ¿Quién debe poder hacer qué? ¿Con qué datos, herramienta y apoyo? ¿En qué condiciones normales y excepcionales? ¿Qué resultado cuenta como suficiente? ¿Cómo se comprobará y qué evidencia sería un fracaso? Un criterio puede ser cuantitativo, como completar una tarea en un intervalo definido sin error crítico, o cualitativo, como comprender una consecuencia antes de confirmar. El número no vuelve objetivo un criterio si la tarea o la población están mal definidas.

Ejemplo construido. Un equipo afirma: «El nuevo trámite será fácil». Tras investigar, formula tres requisitos: una persona que no tenga experiencia previa debe identificar el coste total antes de aceptar; debe corregir un dato sin rehacer toda la solicitud; y debe saber qué ocurrirá después de enviarla. Cada requisito exige una tarea y una observación distinta. La preferencia por un lenguaje más breve puede orientar la redacción, pero no sustituye comprobar comprensión y recuperación.

Los requisitos entran en tensión. Más comprobaciones pueden reducir errores y aumentar tiempo; una opción flexible puede complicar la explicación; una política de seguridad puede limitar la recuperación. Hacer visible la tensión permite priorizar según consecuencias, no prometer que una solución maximizará todo. Un requisito de accesibilidad no es un añadido ornamental: puede cambiar estructura, contenido, tiempo y dispositivos compatibles. WCAG 2.2 ofrece criterios comprobables para contenido web, pero el propio W3C advierte que incluso la conformidad más alta no cubre todas las discapacidades, combinaciones o necesidades cognitivas.

La validación del requisito debe ser independiente de la preferencia del equipo. Preguntar «¿te gusta?» responde a una valoración; observar si una persona reconoce el coste y corrige un dato responde a desempeño; comparar resultados antes y después con una muestra pertinente aporta evidencia de cambio. Las tres preguntas pueden coexistir. Una persona puede preferir una versión y no cumplir el requisito, o cumplirlo y preferir otra por razones estéticas.

Los requisitos también deben contemplar no uso y salida. Quien no puede completar un proceso necesita saber cómo pedir ayuda, cambiar de canal o cancelar sin quedar atrapado. Una solución que funciona sólo si nada sale mal no cumple un requisito de servicio completo. El capítulo 340 explicó recuperación cognitiva; aquí se traduce en criterios: conservar estado, mostrar consecuencia, permitir revisión y ofrecer apoyo cuando la ruta normal falla.

Un backlog de requisitos no es evidencia de que el diseño atienda a las personas. Puede contener frases ambiguas, duplicadas o imposibles de probar. Revisarlo implica identificar fuente, responsable, prioridad, dependencia, riesgo y método de comprobación. Las decisiones que no se incorporan también merecen registro: «no se aborda en esta versión» es más honesto que dejar un hallazgo sin dueño.

343.3. Ideación y prototipos con fidelidad adecuada#

Idear es producir alternativas para una necesidad definida, no decorar una solución ya elegida. Un equipo puede generar variantes de flujo, contenido, espacio, herramienta o regla organizativa. La diversidad de ideas no garantiza calidad: cada alternativa debe explicar qué requisito aborda, qué supuesto introduce y qué riesgo permite probar. Incluir a personas usuarias, mantenedoras y responsables puede revelar posibilidades que una disciplina sola no ve, siempre que la participación no sea una votación de popularidad.

Un prototipo hace visible una hipótesis antes de comprometer todos los recursos. Puede ser un boceto, una secuencia de tarjetas, un modelo físico, una simulación, una maqueta de servicio o código ejecutable. Su valor depende de la pregunta. Un dibujo basta para comparar organización espacial; una maqueta manipulable puede ser necesaria para comprobar alcance; un prototipo funcional permite estudiar tiempos, errores o recuperación. La fidelidad adecuada no es la máxima semejanza, sino la suficiente para producir evidencia sobre el riesgo que se quiere reducir.

La apariencia puede engañar. Un prototipo muy pulido induce a tratar decisiones provisionales como definitivas y puede ocultar que datos, permisos o tiempos están simulados. Uno esquemático puede hacer que participantes discutan la estética en vez del flujo. Informar qué está representado, qué está fingido y qué todavía no existe permite interpretar las respuestas. La guía de prototipos del Government Digital Service recomienda usar bocetos para explorar y prototipos más realistas cuando se quieren investigar interacciones concretas; también advierte que un prototipo no es un servicio de producción.

Ejemplo construido. Para una máquina de préstamo en una biblioteca se ensayan tres ideas. Tarjetas de papel permiten comparar el orden de las decisiones; una maqueta a tamaño real permite comprobar si una persona puede colocar el libro y leer la indicación; un prototipo de código permite observar tiempos y mensajes de error. Usar el código desde el principio no mejora automáticamente la investigación: puede hacer costoso cambiar una hipótesis que todavía no se ha examinado.

La fidelidad tiene varias dimensiones: visual, funcional, temporal, física, lingüística, de datos y social. Un prototipo puede parecer completo y no simular una espera, una interrupción, un documento real o una autorización. Puede ser accesible en pantalla y no en el dispositivo que usa la persona. Antes de evaluar hay que decidir qué dimensión es pertinente y qué simplificación puede alterar la conducta. La simplificación es válida cuando se declara y no responde a una pregunta que depende de lo omitido.

Un prototipo también es un instrumento de comunicación interna. Permite que quienes no ejecutan la tarea vean consecuencias y discutan alternativas sobre algo concreto. Pero la reacción del equipo no equivale a la reacción de usuarios. Una persona diseñadora puede completar un flujo porque conoce su intención; quien llega sin esa información puede interpretar otra cosa. Mantener separados los ensayos internos y las pruebas con personas externas evita una falsa sensación de validación.

La ideación debe incluir casos normales y límites. ¿Qué pasa si falta un dato, se corta la conexión, cambia la prioridad, llega una persona con apoyo, el material está dañado o la decisión se deshace? Prototipar excepciones no significa implementar todas desde el comienzo; significa descubrir qué supuestos sostienen la idea. Un prototipo que sólo muestra el camino feliz produce confianza sobre una fracción del sistema.

La selección de una alternativa puede basarse en criterios explícitos: requisitos cubiertos, riesgos críticos, coste de aprender, facilidad de recuperación, accesibilidad, mantenimiento, seguridad y posibilidad de medir. La idea más atractiva o innovadora no es necesariamente la más adecuada. Hacer visible el criterio evita que la discusión se reduzca a autoridad o gusto.

343.4. Evaluación formativa con tareas y observación#

La evaluación formativa ocurre mientras todavía es posible cambiar el diseño. Su objetivo principal es aprender qué funciona, para quién, en qué condiciones y por qué; no emitir una calificación final del usuario. Una sesión bien planteada pide a una persona que intente una tarea relevante y observa qué hace, qué interpreta, dónde se detiene, qué ayuda necesita y qué consecuencia produce. La tarea debe tener una meta comprensible y no revelar la solución que se pretende probar.

Antes de reclutar, se formulan preguntas de investigación. «¿Puede la gente usarlo?» es demasiado amplio. «¿Puede una persona que recibe una factura identificar el importe total y corregir un dato sin perder lo ya escrito?» define acción, contexto y resultado. La guía del Government Digital Service recomienda acordar preguntas, tipos de usuarios y parte del prototipo antes de las sesiones, y usar tareas creíbles, neutrales y suficientemente desafiantes para revelar problemas.

Observar no es vigilar en silencio ni conducir a la respuesta. Las instrucciones deben ser neutrales; las ayudas, registradas; las preguntas, posteriores cuando sea posible. Pedir que la persona piense en voz alta puede revelar interpretaciones, pero también altera el tiempo y la estrategia. Una entrevista al final puede explorar frustración y preferencia; ninguna de las dos sustituye observar el desempeño. Hay que distinguir que alguien diga «esto es fácil» de que complete la tarea sin apoyo y comprenda la consecuencia.

Los indicadores deben corresponder a la pregunta. Tiempo, errores, abandonos, solicitudes de ayuda, recuerdo, éxito, satisfacción y carga percibida no son intercambiables. Un tiempo menor puede deberse a atajo, omisión o conocimiento previo; más tiempo puede reflejar una comprobación cuidadosa. Un promedio puede ocultar que una tarea es imposible para un subgrupo. Registrar eventos y razones ayuda a interpretar el número, no a reemplazarlo con una narración libre.

Ejemplo construido. En una prueba de tres tareas, ocho personas llegan al final. El equipo concluye que el flujo es usable. Las notas muestran que cuatro recibieron una pista del moderador y dos conocían el servicio anterior; las dos restantes abandonaron antes de confirmar. El porcentaje de éxito no era falso, pero respondía a una condición distinta de la que se quería afirmar. Revisar el protocolo, separar ayuda espontánea de ayuda inducida y ampliar la muestra puede cambiar la conclusión.

La evaluación formativa no requiere siempre una gran muestra. Una sesión puede revelar una barrera grave, una ambigüedad o un supuesto equivocado. Pero pocas sesiones no estiman prevalencia ni garantizan que no existan otros problemas. El tamaño y la composición dependen de la pregunta, la heterogeneidad y el coste de equivocarse. Si se necesita cuantificar una tasa o comparar alternativas con precisión, se requieren métodos y muestras apropiados para esa inferencia.

El contexto de la prueba modifica el resultado. Un laboratorio permite controlar condiciones y observar con detalle; una visita al lugar real revela interrupciones, datos, dispositivos y relaciones; una sesión remota puede incluir el entorno habitual y perder información sobre el espacio. Ninguno es automáticamente más auténtico. La elección debe seguir el riesgo. Si el requisito depende de un ruido, un documento físico o un relevo, la prueba debe representarlos o declarar que quedan fuera.

La evaluación debe proteger a las personas. El moderador prueba el diseño, no la inteligencia, memoria o velocidad de quien participa. No se debe avergonzar a alguien por un error que la prueba buscaba descubrir. Grabaciones, documentos y datos personales requieren consentimiento, almacenamiento seguro y eliminación definida. Si una persona necesita intérprete, lector, dispositivo de apoyo o más tiempo, proporcionarlo no «contamina» la prueba: informa sobre las condiciones reales de acceso.

343.5. Accesibilidad, inclusión y límites de la muestra#

La accesibilidad permite que personas con capacidades, dispositivos y circunstancias diversas perciban, entiendan, operen y reciban el resultado de un sistema. No es sinónimo de comodidad general ni se agota en cumplir una lista técnica. WCAG 2.2 ofrece principios y criterios comprobables para contenido web —perceptible, operable, comprensible y robusto—, pero reconoce que no cubre todas las necesidades, combinaciones de discapacidad ni aspectos cognitivos y lingüísticos. La conformidad es evidencia de ciertos requisitos, no garantía de acceso universal.

La inclusión empieza antes de la prueba. El lugar, la convocatoria, el lenguaje, la compensación, el horario, el transporte, la conexión y la posibilidad de llevar una ayuda determinan quién puede participar. Una muestra formada sólo por quienes tienen tiempo, dispositivos, confianza y permiso para acudir puede parecer diversa en una tabla y seguir excluyendo a quienes encuentran la barrera central. Registrar ausencias y abandonos es parte de analizar el reclutamiento.

La muestra no es una miniatura exacta de la población por el simple hecho de tener varias edades o identidades. Debe ser pertinente para el mecanismo estudiado. Si se evalúa lectura, importa incluir distintas necesidades de contraste, ampliación, idioma y comprensión; si se evalúa movilidad, importa la interacción con el espacio y las ayudas; si se evalúa una prestación, importa el acceso a documentos y tiempo. La representatividad es relativa a la afirmación que se quiere hacer.

No conviene «simular» una discapacidad como sustituto de la experiencia de una persona discapacitada. Taparse los ojos durante cinco minutos no reproduce una trayectoria de uso, una tecnología de apoyo, una barrera social o una estrategia de adaptación. Las simulaciones pueden servir para explorar una hipótesis concreta, pero la investigación debe incluir a quienes viven la condición, compensar su participación y evitar pedirles que representen a todo un grupo.

La accesibilidad incluye alternativas y continuidad. Un servicio digital puede ofrecer atención telefónica o presencial; un material audiovisual puede incluir subtítulos y descripción; una prueba puede permitir teclado, lector de pantalla, ampliación, intérprete o tiempo adicional. La alternativa no debe convertirse en una ruta de menor dignidad o de peor resultado. Una persona no debería demostrar más esfuerzo para obtener el mismo derecho.

La inclusión también tiene límites de seguridad y privacidad. No toda persona debe exponerse a una prueba que reproduce trauma o riesgo; una compensación no justifica una sesión insegura; un diseño experimental no debe ocultar que una tarea puede afectar datos o prestaciones reales. Si una prueba no puede incluir una condición importante, se declara la limitación y se buscan otras evidencias, en vez de presentar el resultado como universal.

La diversidad puede producir hallazgos en tensión. Una reducción de texto puede ayudar a quien tiene poco tiempo y perjudicar a quien necesita instrucciones completas; una confirmación adicional puede proteger a una persona y frustrar a quien usa un lector de pantalla si el foco se pierde. No se resuelve promediando preferencias. Hay que volver a los requisitos, ponderar consecuencias y ofrecer opciones cuando sea posible. La accesibilidad es una propiedad del sistema y de su uso, no una etiqueta de un participante.

Los resultados de una muestra deben comunicarse con su alcance: quién participó, qué tarea hizo, con qué versión, qué ayuda recibió, qué no pudo probarse y qué hipótesis sigue abierta. «Nadie tuvo problemas» puede significar que la muestra no encontró la barrera, que el protocolo la ocultó o que la solución funciona en esas condiciones. Una conclusión prudente es más útil que una afirmación universal que el siguiente contexto desmiente.

343.6. Iteración, trazabilidad y criterios de cierre#

Iterar no es repetir una prueba hasta obtener aprobación. Es modificar una hipótesis a partir de evidencia y volver a comprobar el riesgo que motivó el cambio. Una ronda puede revelar que el problema estaba mal definido; otra, que una mejora para una tarea empeora la recuperación; otra, que el requisito depende de una política que el equipo no controla. El ciclo no avanza necesariamente en una sola dirección: a veces vuelve a investigación, descarta una idea o cambia el objetivo.

La trazabilidad conserva el recorrido de una decisión. Para cada requisito conviene poder localizar la observación o razón que lo originó, la alternativa que se eligió, la versión probada, la evidencia obtenida, los defectos conocidos, la decisión y la persona o instancia responsable. Esto no exige documentar cada conversación con el mismo detalle. Exige suficiente información para reconstruir por qué se aceptó un riesgo y qué tendría que cambiar para reabrirlo.

Ejemplo construido. Un servicio decide mantener un paso de confirmación porque evita un error costoso, aunque aumenta treinta segundos el tiempo medio. El registro vincula el requisito de prevenir ese error con tres pruebas, una alternativa de edición y un criterio de recuperación. Después de implantarlo, los abandonos aumentan en un grupo que usa conexión lenta. La trazabilidad no dicta la solución, pero permite ver qué supuesto falló y comparar una versión más ligera sin olvidar el riesgo original.

Los criterios de cierre deben definirse antes de que la presión de entrega los vuelva implícitos. Pueden incluir requisitos críticos cumplidos, tareas representativas completadas, riesgos residuales aceptados por quien tiene autoridad, accesibilidad revisada, datos protegidos, soporte preparado y plan de seguimiento. «A todos les gustó» no es criterio suficiente; «cero errores» puede ser imposible o esconder que nadie probó la excepción. Cerrar significa decidir con incertidumbre declarada, no afirmar perfección.

Hay criterios que obligan a no cerrar. Una barrera que impide ejercer un derecho, un riesgo de daño grave, una imposibilidad de recuperar datos, una condición de uso no representada o una deuda de accesibilidad crítica requieren rediseño, mitigación o una decisión pública explícita. La fecha límite no transforma un fallo crítico en evidencia de suficiencia. Tampoco todo defecto menor debe bloquear indefinidamente: la severidad, probabilidad, reversibilidad y coste de esperar ayudan a priorizar.

Después del lanzamiento, la evaluación continúa. Uso real, reclamaciones, abandonos, solicitudes de ayuda, incidentes y diferencias entre grupos pueden contradecir la prueba inicial. El seguimiento debe distinguir un cambio del producto de un cambio de población, política, dispositivo o contexto. Las métricas no deben incentivar ocultar fallos ni recopilar datos innecesarios. Cuando el sistema produce consecuencias importantes, una vía de reporte y revisión es parte del diseño, no un complemento administrativo.

La iteración también necesita gobernanza. Alguien debe poder aceptar un requisito en conflicto, financiar una corrección, detener una implantación o explicar por qué una alternativa no se adopta. El capítulo 342 tratará autoridad y coordinación con detalle; aquí basta señalar que la evidencia no se convierte sola en decisión. Diseñar centrado en las personas requiere una relación explícita entre hallazgos, poder de cambio y responsabilidad por el resultado.

Una síntesis práctica puede formularse como cinco preguntas que se repiten en cada ronda: ¿qué actividad y qué diversidad estamos describiendo?, ¿qué afirmación queremos comprobar?, ¿qué prototipo hace visible ese riesgo?, ¿qué observación distinguirá preferencia, desempeño y evidencia?, ¿qué decisión y qué incertidumbre quedarán registradas? Responderlas no elimina sorpresas. Hace que una sorpresa pueda producir aprendizaje en lugar de culpa o maquillaje.

El diseño centrado en las personas no promete conocer por adelantado todas las necesidades ni obtener una solución aceptada por cualquiera. Ofrece un método para escuchar sin convertir opiniones en hechos, prototipar sin confundir apariencia con funcionamiento, evaluar sin examinar a la persona y cerrar sin borrar riesgos residuales. Su criterio final no es que el equipo crea haber terminado, sino que las personas puedan realizar la actividad relevante con resultados aceptables, apoyos disponibles y una vía verificable para corregir lo que aún no se sabe.

Preguntas de transferencia#

Cinco participantes prefieren una versión, pero dos no completan la tarea. ¿Cuál resultado debe guiar el cambio?#

Un prototipo se ve igual que el servicio final y nadie encuentra problemas. ¿Está validado?#

Una prueba con diez personas no encuentra errores. ¿Puede afirmarse que nadie tendrá problemas?#

El equipo decide cerrar porque terminó el presupuesto, aunque queda una barrera para recuperar una solicitud. ¿Qué falta?#

Fuentes y lecturas del capítulo#

Las fuentes se utilizan para respaldar principios de diseño centrado en las personas, evaluación de usabilidad y accesibilidad. Los escenarios de la oficina, el municipio, la biblioteca y los servicios son ejemplos construidos; no son estudios de esos lugares.

• International Organization for Standardization. ISO 9241-210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. Requisitos y recomendaciones para actividades de diseño centrado en las personas durante el ciclo de vida de sistemas interactivos; la página oficial indica que la edición fue confirmada en 2025.
• World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. Recomendación técnica con principios, criterios comprobables y niveles de conformidad para contenido web; también declara límites frente a todas las discapacidades y necesidades.
• Government Digital Service, GOV.UK. Making prototypes. Guía pública sobre cuándo y por qué prototipar, diferencias entre boceto y prototipo de código y límites de usar un prototipo como servicio real.
• Government Digital Service, GOV.UK. Using moderated usability testing. Orientación para formular tareas creíbles, observar participantes, reclutar usuarios pertinentes, ofrecer apoyos y proteger datos durante pruebas moderadas.
• Government Digital Service, GOV.UK. Plan a round of user research. Guía para preparar prototipos y sesiones, comprobar accesibilidad del lugar y relacionar cada ronda con preguntas concretas.
• National Institute for Occupational Safety and Health, CDC. Elements of Ergonomics Programs. Referencia para participación de trabajadores, identificación de problemas, implementación y evaluación de intervenciones, trasladada aquí como principio de participación y seguimiento.
• National Institute for Occupational Safety and Health, CDC. Total Worker Health® Frequently Asked Questions. Marco participativo para dar voz a trabajadores y considerar diferencias, condiciones de trabajo y jerarquía de controles; no se usa como sustituto de una evaluación de diseño concreta.
• ISO/IEC. ISO/IEC 25010:2023, Systems and software engineering — Systems and software quality models. Referencia para tratar calidad como un conjunto de características y no como una única puntuación; se usa sólo para apoyar la necesidad de criterios explícitos y no como método completo de investigación de usuarios.

Bibliografía de la parte XXXI · Bibliografía general

Última revisión editorial

3 de octubre de 2026

Cierre de contenidos

3 de octubre de 2026