11 de enero de 2024

Diseño centrado en las personas: resolver el problema correcto

Persona en el centro de un sistema: hogar, otras personas, ideas, ciudad, herramientas y operación.

Diseño centrado en las personas: resolver el problema correcto

Diseñar centrado en las personas suele resumirse con una frase bastante cómoda:

Poner al usuario en el centro.

El problema es que esa frase explica poco.

Podemos entrevistar personas, construir personas, hacer mapas de empatía y tests de usabilidad y aun así terminar diseñando una solución que no responde al problema que realmente tienen.

El Diseño Centrado en las Personas —Human-Centered Design— es una aproximación al diseño que busca desarrollar y mejorar productos y servicios de manera continua a partir de una comprensión profunda de las personas, sus necesidades y los contextos en los que actúan.

Eso implica bastante más que “preguntarle al usuario qué quiere”.

Significa entender cómo vive una situación, identificar qué problema vale la pena resolver, observar el sistema alrededor de ese problema y utilizar evidencia para aprender antes de comprometernos con una solución.

Persona situada dentro de su contexto, necesidades, restricciones y situaciones de uso.

Don Norman sintetiza esta idea en cuatro principios especialmente útiles: enfocarse en las personas, resolver el problema fundamental y no sólo sus síntomas, considerar el sistema completo y probar/refinar continuamente las soluciones.

Esos cuatro principios nos dan una forma bastante más concreta de entender qué significa realmente diseñar centrado en las personas.

Empezar por las personas, no por la solución

Supongamos que un equipo recibe este pedido:

Necesitamos una app para organizar turnos.

La reacción habitual puede ser empezar inmediatamente por funcionalidades: calendario, recordatorios, cancelaciones, disponibilidad o notificaciones.

Pero todavía no sabemos si una aplicación es la respuesta.

Antes necesitamos comprender qué está ocurriendo.

Las preguntas correctas se parecen más a estas:

  • ¿Quiénes son las personas que intentamos ayudar?
  • ¿Cómo influye esta problemática en su rutina?
  • ¿Cómo resuelven su problema actualmente?

Estas preguntas cambian el punto de partida.

En lugar de estudiar solamente qué debería hacer nuestro producto, empezamos a estudiar qué están intentando hacer las personas.

Eso implica observar necesidades, comportamientos, capacidades, limitaciones y contexto.

Entender a una persona aislada tampoco alcanza.

Necesitamos comprender los diferentes contextos en los que ocurre su actividad: qué intenta conseguir, qué restricciones enfrenta, qué otras herramientas utiliza, con quién interactúa y qué sucede antes y después de nuestro producto.

Ahí empiezan a aparecer oportunidades de mejora que difícilmente encontraríamos mirando únicamente una pantalla.

Diseñar para personas no significa diseñar sólo para usuarios

Incluso la palabra usuario puede resultar demasiado estrecha.

Un producto puede afectar a muchas personas que nunca tocan directamente su interfaz.

Pensemos en un sistema para hacer check-in en un aeropuerto.

  • Existe el pasajero.
  • Pero también personal de aeropuerto, agentes, tripulación, operaciones, soporte, acompañantes y sistemas externos.

Optimizar únicamente la interacción de quien está frente a una pantalla puede trasladar el problema hacia otra parte.

Por eso hablar de personas puede ser útil: nos obliga a mirar más allá de quien hace clic.

Resolver el problema correcto

Este probablemente sea el principio más importante.

Los problemas de diseño suelen llegar formulados como soluciones:

  • Necesitamos agregar un buscador.
  • Hay que hacer un dashboard.
  • Necesitamos inteligencia artificial.
  • El formulario tiene que tener menos pasos.

El riesgo es tomar esa formulación como verdadera y empezar inmediatamente a resolverla.

Diseño Centrado en las Personas propone exactamente lo contrario: tratar el problema inicial como una hipótesis y dedicar tiempo a descubrir cuáles son las causas subyacentes antes de diseñar una respuesta.

Las preguntas útiles acá son:

  • ¿Cómo definimos el problema que enfrentan las personas?
  • ¿Cómo sabemos que es el problema correcto?
Diferencia entre síntoma, investigación, causa subyacente y problema real a resolver.

Imaginemos un ecommerce con una tasa de abandono alta.

Podemos recibir un pedido así:

El checkout tiene demasiados pasos.

Reducir pasos parece una solución razonable.

Pero investigamos y descubrimos que gran parte del abandono ocurre porque el costo de envío recién aparece al final.

El problema no era cantidad de pantallas.

Era falta de información.

Podíamos haber diseñado un checkout impecable para resolver el problema equivocado.

Síntoma no es lo mismo que causa

Si una persona abandona, se equivoca, llama a soporte, repite una acción o inventa un workaround, eso es evidencia.

Pero todavía no es necesariamente el problema.

Hay que preguntar por qué ocurre. Y a veces volver a preguntar.

Investigar no consiste solamente en recolectar opiniones.

Consiste en intentar construir una explicación suficientemente buena de lo que está ocurriendo.

La persona forma parte de un sistema

Los problemas interesantes rara vez ocurren aislados.

Una persona utiliza un producto dentro de una organización, un proceso, un conjunto de reglas, otros productos, otras personas, limitaciones técnicas, incentivos, costos y tiempo.

Por eso otra de las preguntas clave es:

  • ¿Quiénes se ven afectados por el problema que queremos resolver?
  • ¿Cómo podemos ofrecer una solución que no altere negativamente otras partes del sistema?
Persona como parte de un ecosistema mayor: actores, procesos, herramientas y dependencias.

Diseñar centrado en una persona no significa ignorar todo lo demás.

Significa entender cómo esa persona participa en un sistema.

Podríamos acelerar muchísimo el checkout para el comprador eliminando controles.

Pero si eso multiplica fraudes, errores de inventario o trabajo manual en operaciones, no resolvimos el problema.

Lo desplazamos.

Mirar el problema de manera holística

Una persona nunca utiliza un producto en condiciones abstractas.

Existe un contexto.

  • Puede tener prisa.
  • Puede estar cansada.
  • Puede utilizar el teléfono con una mano.
  • Puede trabajar con ruido.
  • Puede compartir una computadora.
  • Puede estar aprendiendo.
  • Puede depender de otra persona.
  • Puede utilizar nuestro producto junto con otras herramientas.

Por eso conviene preguntarse:

  • ¿Qué factores son relevantes en el problema que estamos estudiando?
  • ¿Qué aspectos de la relación entre las personas y los sistemas no estamos considerando?

Human-Centered Design no significa acumular datos sobre una persona.

Significa intentar comprender la situación dentro de la que ocurre una actividad.

La unidad de análisis no debería ser siempre la pantalla.

Muchas veces es la actividad.

Diseñar con evidencia, no solamente con empatía

Empatizar con las personas ayuda.

Pero no alcanza.

Un equipo puede sentir mucha empatía y seguir estando equivocado.

Por eso el diseño centrado en las personas necesita evidencia.

  • Observar.
  • Entrevistar.
  • Analizar comportamientos.
  • Prototipar.
  • Probar.
  • Medir.
  • Volver a observar.

Eso introduce una idea importante:

Centrar el diseño en las personas no es una etapa inicial de Research. Es una forma de trabajar durante todo el proceso.

Una persona no valida una solución porque le guste

Diseño Centrado en las Personas no significa:

Le preguntamos al usuario y dijo que le gustaba.

Lo que alguien dice es una fuente de evidencia. No la única.

Podemos combinar:

  • lo que las personas dicen,
  • lo que hacen,
  • lo que pueden hacer,
  • lo que ocurre en el producto,
  • y los resultados que finalmente consiguen.

El trabajo del equipo consiste en interpretar todo eso.

No en convertir cada pedido en una feature.

Diseñar es iterar

Una solución inicial es una hipótesis.

Podemos pensar:

Si cambiamos X, esperamos que Y mejore porque aprendimos Z.

Después podemos construir la representación más barata que permita aprender algo: un sketch, un prototipo, una simulación o una versión funcional limitada.

Y probarla.

Si funciona, avanzamos.

Si no, aprendemos.

Esa lógica permite detectar errores cuando todavía son baratos.

Ciclo de aprendizaje: hipótesis → prototipo → evidencia → aprendizaje → iteración.

Iterar no significa simplemente versión 1, versión 2 y versión 3.

Significa:

hipótesis → evidencia → aprendizaje → nueva hipótesis

Mejorar continuamente, no diseñar una vez

Hay otra idea importante en el planteo original de esta pieza: el Diseño Centrado en las Personas busca mejorar productos y servicios de forma continua.

Esto cambia la manera de pensar el lanzamiento.

Publicar una solución no cierra necesariamente el proceso de diseño.

Nos permite observar qué ocurre cuando una hipótesis entra en contacto con la realidad.

Algunas decisiones funcionarán como esperábamos.

Otras revelarán nuevos problemas.

También cambiarán las personas, el contexto, la tecnología y la organización.

Por eso un producto centrado en las personas no es simplemente un producto que “hizo Research”.

Es un producto cuyo proceso permite seguir aprendiendo.

Centrado en las personas no significa ignorar negocio y tecnología

Si únicamente diseñáramos aquello que las personas desean, podríamos producir soluciones imposibles de construir o sostener.

Una buena solución aparece en la intersección entre tres preguntas:

  • Deseabilidad: ¿responde a una necesidad significativa para las personas?
  • Factibilidad: ¿podemos construirla y operarla con los recursos y capacidades disponibles?
  • Viabilidad: ¿puede sostenerse para la organización?
Intersección entre personas, tecnología y negocio: deseabilidad, factibilidad y viabilidad.

El orden importa.

Si empezamos exclusivamente desde tecnología —“tenemos IA, ¿dónde podemos ponerla?”— estamos buscando un problema para una solución.

Si empezamos exclusivamente desde negocio —“necesitamos aumentar esta métrica”— podemos terminar optimizando algo que genera valor para la organización a costa de quien utiliza el producto.

Human-Centered Design introduce otra pregunta:

¿Qué problema vale la pena resolver para las personas involucradas?

Una solución puede ser usable y seguir siendo insuficiente

El enfoque original de esta pieza también apuntaba a algo importante: mejorar la experiencia no consiste únicamente en hacer una interfaz fácil de utilizar.

Podemos observar una solución a través de dimensiones como utilidad, usabilidad, deseabilidad, encontrabilidad, accesibilidad, credibilidad y valor.

Eso nos recuerda que:

  • Un producto puede ser usable y no ser útil.
  • Puede ser útil y no ser accesible.
  • Puede funcionar técnicamente y no resultar confiable.
  • Puede resolver una tarea y, aun así, no generar suficiente valor para justificar su uso.
Dimensiones de la experiencia: útil, usable, deseable, encontrable, accesible, creíble y valioso.

Esto complementa bien al Diseño Centrado en las Personas: primero necesitamos comprender qué problema vale la pena resolver y luego evaluar si la solución realmente mejora la situación de las personas.

Diseño Centrado en Personas no es lo mismo que Design Thinking

Los términos suelen mezclarse, pero conviene no tratarlos como sinónimos perfectos.

Human-Centered Design describe fundamentalmente una orientación del proceso de diseño hacia las personas, sus actividades, necesidades y contexto.

Design Thinking es una familia más amplia de prácticas para abordar problemas ambiguos mediante investigación, divergencia, convergencia, ideación, prototipado e iteración.

Podemos utilizar Design Thinking como una forma de practicar diseño centrado en las personas.

Pero hacer un workshop con post-its no convierte automáticamente un proceso en Human-Centered Design.

Las cuatro preguntas que conservan el núcleo

Podemos condensar todo el artículo en cuatro grupos de preguntas, y sumar una quinta para cerrar el ciclo:

Personas

  • ¿Quiénes son las personas que intentamos ayudar?
  • ¿Cómo afecta el problema su actividad?
  • ¿Cómo lo resuelven actualmente?

Problema

  • ¿Qué problema estamos intentando resolver?
  • ¿Qué evidencia tenemos de que ése es el problema correcto?

Sistema

  • ¿Quién más se ve afectado?
  • ¿Qué otras partes del sistema podrían cambiar como consecuencia de nuestra solución?

Contexto

  • ¿Qué condiciones influyen sobre la situación?
  • ¿Qué relaciones, restricciones o comportamientos todavía no estamos viendo?

Evidencia

  • ¿Cómo vamos a comprobar que nuestra solución mejora realmente la situación?

No se trata de diseñar para el usuario

Hay una diferencia pequeña en las palabras, pero enorme en la práctica.

Diseñar para alguien puede seguir siendo un proceso unilateral.

El equipo investiga, interpreta, decide y entrega.

Una versión más madura de Human-Centered Design intenta involucrar a las personas a lo largo del proceso, contrastando continuamente nuestras interpretaciones con la realidad.

No todos los proyectos necesitan llegar a un nivel profundo de co-diseño.

Pero el principio es útil:

Cuanto más importante sea una decisión para las personas afectadas, más peligroso es asumir que entendemos sus necesidades sin involucrarlas.

Diseñar centrado en las personas es aprender antes de comprometerse

Human-Centered Design no promete que podamos eliminar la incertidumbre.

Hace algo más útil: nos ayuda a reducirla progresivamente.

Primero intentamos comprender a las personas.

Después cuestionamos el problema.

Observamos el sistema.

Generamos alternativas.

Construimos algo.

Lo ponemos frente a la realidad.

Aprendemos.

Y repetimos.

El objetivo no es seguir un proceso perfecto.

Es evitar enamorarnos demasiado pronto de una solución.

Porque una solución técnicamente brillante puede seguir siendo inútil si resuelve un problema que nadie tenía.

Y una interfaz impecable puede seguir fallando si sólo funciona dentro del escenario que imaginó el equipo.

Diseñar centrado en las personas significa recordar que nuestros productos no existen dentro de Figma.

Existen dentro de sistemas, organizaciones, actividades y vidas que ya estaban ocurriendo antes de que nosotros llegáramos.

El trabajo no empieza preguntando qué podemos diseñar. Empieza entendiendo qué vale la pena resolver.

En síntesis

El Diseño Centrado en las Personas no consiste solamente en escuchar usuarios ni en aplicar un workshop. Es una aproximación al diseño que parte de comprender personas y contextos, cuestionar el problema recibido, mirar el sistema completo y aprender continuamente mediante evidencia e iteración.

Fuentes