Innovar sin escuchar al usuario puede convertir una buena idea en un problema

Una organización puede enamorarse de una solución antes de comprender el problema. El equipo celebra una función nueva, cumple el cronograma y presenta una interfaz impecable. Después llegan las fricciones: personas que no entienden qué deben hacer, clientes que abandonan el proceso, trabajadores que inventan atajos y usuarios con discapacidad que ni siquiera pueden completar una tarea básica. La idea no era necesariamente mala. El problema fue convertir una hipótesis interna en una respuesta sin escuchar suficientemente a quienes vivirían con ella.

Escuchar al usuario no equivale a preguntarle qué producto quiere y obedecer literalmente. Significa investigar su contexto, observar límites y estrategias reales, contrastar supuestos, probar alternativas y mantener abiertos canales para detectar consecuencias inesperadas. Esa práctica no rebaja la ambición innovadora: evita que la novedad sea útil solo para quienes la diseñaron.

Cuando una buena idea resuelve el problema equivocado

En muchas iniciativas, la definición inicial ya contiene una solución: “necesitamos una aplicación”, “debemos automatizar esta aprobación” o “hay que incorporar inteligencia artificial”. El lenguaje desplaza la pregunta esencial: ¿qué dificultad experimenta la persona, en qué situación y con qué consecuencias? Si la formulación nace desde la tecnología disponible, el presupuesto o la preferencia de la dirección, el proyecto puede optimizar con gran eficiencia algo que el usuario no necesita.

Donald Norman explica en The Design of Everyday Things que los errores atribuidos a las personas suelen revelar problemas de diseño. La visibilidad de las opciones, la relación entre controles y resultados, las restricciones y la retroalimentación ayudan a que una persona comprenda qué puede hacer y qué ocurrió después. Esta lectura cambia la responsabilidad: en vez de calificar al usuario de torpe, distraído o resistente, obliga a examinar las señales que el sistema ofrece y las condiciones en las que se usa.

La edición revisada y ampliada, publicada por Basic Books en 2013 (ISBN 978-0-465-05065-9), también insiste en una idea más amplia: el diseño centrado en las personas es iterativo. Comprender, especificar, producir y evaluar no son casillas que se marcan una vez. Una prueba puede invalidar la formulación inicial y obligar a regresar al problema. Esa vuelta no es un fracaso del proceso; es una forma barata de aprender antes de que la equivocación se vuelva infraestructura, contrato o hábito.

Escuchar no es lo mismo que recopilar opiniones

Una encuesta de satisfacción al final del proyecto puede generar datos, pero llega tarde para influir en decisiones estructurales. Un grupo focal puede ofrecer discursos valiosos, aunque no siempre muestra lo que ocurre durante una tarea real. Una entrevista permite comprender motivaciones y lenguaje; la observación revela interrupciones, dependencias y adaptaciones que la persona quizá ya normalizó. Ningún método aislado representa “la voz del usuario”. Conviene combinar evidencia según la incertidumbre que se quiere reducir.

La norma ISO 9241-210:2019 formula requisitos y recomendaciones para el diseño centrado en las personas a lo largo del ciclo de vida de sistemas interactivos. Su valor no reside en una ceremonia concreta, sino en principios: comprender explícitamente usuarios, tareas y entornos; involucrar a las personas durante el diseño y el desarrollo; orientar y refinar el diseño mediante evaluación; iterar; atender la experiencia completa; e integrar capacidades y perspectivas multidisciplinarias.

La revisión sistemática de Peter Wacnik, Shanna Daly y Aditi Verma sobre diseño participativo describe un enfoque iterativo y flexible con implicación cercana de las partes interesadas, especialmente de quienes serán más afectados. El estudio, publicado en Design Science, también ayuda a poner un límite a la retórica: participación puede significar actividades muy distintas. Invitar a una sesión no garantiza que las personas tengan influencia real sobre el alcance, los criterios de éxito o la decisión final. Por eso conviene registrar no solo quién fue consultado, sino qué cambió como resultado.

La persona promedio no existe

Diseñar para un usuario abstracto suele excluir a quienes se apartan de los supuestos del equipo: alguien con baja visión, una persona mayor, quien usa un teléfono económico, trabaja con mala conectividad, comprende otro idioma o necesita completar el trámite mientras cuida a otra persona. También quedan fuera quienes conocen el proceso desde una posición menos visible: atención al cliente, soporte, operaciones, mantenimiento o comunidades afectadas sin poder de compra.

La accesibilidad no debe aparecer como reparación final. Las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.2 del W3C organizan criterios alrededor de cuatro principios: que el contenido sea perceptible, operable, comprensible y robusto. Aunque una lista de conformidad es necesaria, no sustituye pruebas con personas ni una revisión del recorrido completo. Un formulario puede cumplir varios criterios técnicos y seguir siendo inviable si exige documentos difíciles de obtener, agota el tiempo de sesión o comunica un error sin explicar cómo corregirlo.

La Organización Mundial de la Salud señala que la tecnología de asistencia favorece funcionamiento, independencia, participación educativa, laboral y cívica. Su ficha sobre tecnología de asistencia recuerda que el problema no termina en el dispositivo: también importan acceso, entornos, servicios y políticas. Para un equipo innovador, la lección es concreta: una solución no puede calificarse de inclusiva solo porque funciona en la demostración. Debe ser alcanzable, compatible y sostenible en las condiciones reales de uso.

Seguridad y consecuencias: preguntas que deben entrar temprano

La investigación de usuarios se asocia a menudo con facilidad de uso, pero también permite descubrir daños. Una automatización puede ahorrar pasos a la organización y, al mismo tiempo, eliminar una oportunidad de explicación o recurso para la persona. Una función de personalización puede exigir datos desproporcionados. Una alerta puede reducir un riesgo y crear fatiga si aparece con demasiada frecuencia. Una herramienta de productividad puede trasladar trabajo invisible al cliente o intensificar la vigilancia sobre el empleado.

El Marco de Gestión de Riesgos de IA del NIST propone abordar la confiabilidad durante el diseño, desarrollo, uso y evaluación, no únicamente después del despliegue. Aunque su foco es la inteligencia artificial, su lógica sirve para cualquier innovación con efectos significativos: mapear el contexto y a las partes afectadas, medir riesgos, gobernar responsabilidades y gestionar respuestas. Preguntar por el uso previsto no basta; hay que explorar usos previsibles, abuso, dependencia, fallos, distribución desigual de beneficios y dificultad de abandonar el sistema.

Cómo incorporar al usuario sin convertir el proceso en teatro

El primer paso es definir decisiones que todavía puedan cambiar. Si la arquitectura, el proveedor, el cronograma y los indicadores ya están cerrados, escuchar puede convertirse en una representación: se solicita experiencia, pero solo se aceptan comentarios cosméticos. Antes de convocar a nadie, el equipo debería declarar qué está abierto, qué restricciones son reales, quién decide y cómo comunicará lo aprendido.

Después hay que seleccionar participantes por relación con el problema, no solo por facilidad de reclutamiento. Los clientes más activos pueden conocer bien el producto, pero no representan a quienes abandonaron, fueron rechazados o nunca pudieron empezar. Los superiores pueden describir el proceso formal; el personal de primera línea conoce excepciones y compensaciones. Incluir contrastes suele ser más informativo que buscar una muestra ficticiamente homogénea.

Una práctica útil es convertir cada observación en una cadena trazable: evidencia, interpretación, decisión y límite. “Tres personas no encontraron el botón” es observación; “el botón carece de jerarquía visual” es interpretación; “cambiaremos ubicación y texto y repetiremos la prueba” es decisión. Separar estos niveles evita transformar una anécdota en verdad universal, pero también impide que una preferencia interna se disfrace de hallazgo.

También importa cerrar el circuito con quienes participaron. Explicar qué se modificó, qué no y por qué muestra respeto por su tiempo y permite corregir malentendidos. La participación no entrega a los usuarios toda la responsabilidad del diseño: el equipo conserva el deber de integrar evidencia técnica, viabilidad, seguridad, accesibilidad, estrategia y consecuencias de largo plazo.

Un protocolo breve para la próxima iniciativa

Antes de aprobar una solución, puede realizarse una revisión en seis conversaciones. La primera reúne a quien experimenta el problema; la segunda, a quien ejecuta o sostiene el proceso; la tercera, a alguien que suele quedar fuera; la cuarta, a especialistas en seguridad, privacidad o accesibilidad; la quinta, a quienes responderán cuando algo falle; la sexta confronta al patrocinador con la evidencia y las renuncias necesarias.

Cada conversación debe terminar con una pregunta de decisión: ¿qué supuesto perdió fuerza?, ¿qué daño no habíamos considerado?, ¿qué requisito debe cambiar?, ¿qué podemos probar sin comprometer a toda la organización? El resultado no es una pila de notas, sino una versión mejor delimitada del problema y una lista explícita de condiciones para avanzar.

Finalmente, el lanzamiento debe conservar capacidad de aprendizaje. Esto implica métricas de resultados para la persona, no solo adopción; mecanismos visibles de ayuda y reclamación; seguimiento de grupos afectados; responsables para corregir; y criterios de pausa o retiro. Innovar responsablemente incluye saber detener una idea que ya no sostiene su promesa.

La innovación empieza con una renuncia

Escuchar bien exige renunciar a la comodidad de tener razón desde el inicio. La organización cambia una narrativa heroica —una idea brillante que conquista el mercado— por una disciplina más humilde: formular, observar, contrastar y corregir. Esa humildad no hace lenta la innovación. Reduce la probabilidad de escalar una confusión y concentra recursos en problemas que importan.

Una buena idea no merece protección frente a la realidad; merece una prueba justa. Cuando accesibilidad, seguridad y consecuencias entran desde el comienzo, el usuario deja de ser el destinatario final de una decisión ajena y se convierte en fuente legítima de conocimiento sobre el sistema. La pregunta para la comunidad es esta: ¿qué decisión de un proyecto actual todavía podría cambiar si escucháramos a las personas que cargarán con sus efectos?

Elaborado por Ricardo Gaibor.

Este artículo fue elaborado por Ricardo Gaibor con ayuda de sistemas de inteligencia artificial en tareas de investigación, organización y edición. La selección, interpretación y responsabilidad editorial del contenido corresponden al autor.

Fuentes y lecturas recomendadas

• Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books. ISBN 978-0-465-05065-9. Ficha editorial.
• International Organization for Standardization. (2019). ISO 9241-210:2019 — Human-centred design for interactive systems. https://www.iso.org/standard/77520.html.
• Wacnik, P., Daly, S. R., & Verma, A. (2025). “Participatory design: a systematic review and insights for future practice”. Design Science. https://doi.org/10.1017/dsj.2025.10009.
• World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/.
• World Health Organization. Assistive technology — Fact sheet. https://www.who.int/news-room/fact-sheets/detail/assistive-technology.
• National Institute of Standards and Technology. AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework.