Llevando un mejor proceso de diseño a su organización

Como diseñadores e investigadores de experiencia de usuario (UX), la queja más común que escuchamos de los usuarios es:

“¿Por qué no piensan en lo que necesito?”

De hecho, muchas organizaciones tienen equipos dedicados a brindar lo que los usuarios y clientes necesitan. Cada vez más desarrolladores de software están ansiosos por trabajar con diseñadores de UX para codificar interfaces que los clientes usarán y comprenderán. El problema es que los proyectos de software complejos pueden atascarse fácilmente en prioridades contrapuestas y confusión sobre qué hacer a continuación.

El resultado es un diseño deficiente que impide la productividad. Por ejemplo, la eficiencia en el cuidado de la salud se ve obstaculizada por los registros médicos electrónicos (EMR). Las quejas sobre estos sistemas de software son legión. El Dr. Steven Ugent, un dermatólogo con sede en Boston y ex alumno de la Facultad de Medicina de Yale, no es una excepción.

Desde 2010, el Dr. Ugent ha utilizado dos sistemas EMR: antes de 2010, terminaba el trabajo puntualmente a las 5:15 todos los días. Desde que él y sus colegas comenzaron a usar EMR, normalmente trabaja de media hora a hora y media más por la noche. “No conozco a ningún médico que esté contento con su sistema de registros médicos. Lo loco es que era mucho más eficiente cuando usaba lápiz y papel”.

Los sistemas EMR son torpes, inflexibles y difíciles de personalizar. Ugent, por ejemplo, no puede incrustar fotos directamente en sus notas gráficas. En su lugar, debe abrir la carpeta con la foto del topo y luego abrir una carpeta diferente para ver el texto. Esta configuración es particularmente engorrosa para los dermatólogos que dependen en gran medida de las fotos cuando tratan a los pacientes.

Ugent resume sucintamente el problema con los EMR:

“Las personas que lo diseñan [el sistema EMR] no entienden mi flujo de trabajo. Si lo hicieran, diseñarían un sistema diferente”.

Los médicos no están solos en su frustración con el software torpe. Consumidores y profesionales de todo el mundo presentan quejas similares:

“¿Por qué no puedo encontrar lo que necesito?”

“¿Por qué lo hacen tan difícil?”

“¿Por qué tengo que crear un inicio de sesión cuando simplemente quiero comprar este producto? Les estoy dando dinero. ¿No es eso suficiente?

Un factor importante que contribuye al software torpe son los procesos de diseño defectuosos. En este artículo, describiremos cuatro problemas del proceso de diseño y explicaremos cómo abordarlos.

1. Complejidad
2. Síndrome del próximo lanzamiento
3. Tiempo insuficiente para iteraciones de diseño
4. Ceder el control a proveedores externos

1. Complejidad

La escala, las múltiples partes interesadas y la necesidad de un código sofisticado se encuentran entre los muchos factores que contribuyen a la complejidad de los grandes proyectos de software.

Sin embargo, a veces se pasan por alto leyes y reglamentos complejos. Por ejemplo, los seguros están fuertemente regulados a nivel estatal, lo que agrega una capa de complejidad para las compañías de seguros que operan en varios estados. Los bancos y cooperativas de crédito están sujetos a regulación, mientras que las empresas de servicios públicos deben cumplir con las leyes ambientales estatales y federales.

Los productos y el software para el cuidado de la salud sujetos a las regulaciones de la FDA ofrecen un desafío aún mayor. El problema no es que las regulaciones no sean razonables. La seguridad es primordial. Los problemas son el tiempo, el presupuesto y la planificación necesaria para cumplir con los requisitos de la FDA.

Como explica Jeff Horvath, Ph.D., consultor de UX con amplia experiencia en atención médica: “Estos requisitos agregan un par de órdenes de magnitud al rigor para escribir protocolos de prueba, configuración de pruebas, recopilación de datos, análisis, controles de calidad y obtener la aprobación para llevar a cabo la investigación en primer lugar”. Por ejemplo, una sola ronda de prueba de usabilidad salta de seis semanas (un marco de tiempo razonable para una prueba de usabilidad estándar) a seis meses. Y eso es con una sola ronda de pruebas de usabilidad . A menudo, se necesitan dos o más rondas de pruebas.

Este nivel de rigor es una llamada de atención para las empresas que recién comienzan a trabajar con la FDA. Más de una vez, Horvath se ha enfrentado a conversaciones difíciles con clientes que no estaban preparados para los plazos extendidos y el presupuesto adicional necesario para cumplir con los requisitos de la FDA. Es duro, pero necesario. "Vale la pena ser minucioso", dice Horvath. En 2018, la FDA aprobó solo el 11 % de las presentaciones previas a la comercialización.

Las demandas de los investigadores, diseñadores y desarrolladores son mayores para el software de atención médica que requiere el cumplimiento de la FDA que para los productos de software tradicionales. Por ejemplo:

• Un investigador de UX solo puede realizar una o dos sesiones de prueba de usabilidad por día en lugar de las cinco o seis sesiones más comunes por día para el software estándar.
• Los diseñadores de UX deben permanecer muy atentos a todos los aspectos de la interacción del usuario con el software. Incluso una interacción confusa podría hacer que un médico cometiera un error que podría poner en peligro la salud de un paciente. Por la misma razón, los diseñadores de UI deben dibujar interfaces que se mantengan fieles a cada interacción.
• Un marco de tiempo más largo para las pruebas de diseño y usabilidad significa que los esfuerzos de codificación del desarrollador deben planificarse cuidadosamente. Los desarrolladores hábiles y bien intencionados a menudo están ansiosos por modificar el código tan pronto como haya nueva información disponible. Si bien este enfoque puede funcionar en organizaciones bien practicadas en iteraciones rápidas, conlleva riesgos al diseñar y codificar sistemas complejos.

No manejar la complejidad puede tener consecuencias fatales, como sucedió cuando Danielle McCray ingresó en el Tallahassee Memorial Hospital cuando estaba a punto de dar a luz. Para aliviar su malestar, los trabajadores de la salud la conectaron a una máquina de analgesia controlada por el paciente, una bomba de infusión programable.

Ocho horas después, McCray fue declarado muerto por una sobredosis de morfina. Un factor importante en esta tragedia fue el diseño defectuoso de la bomba de infusión utilizada para administrar medicamentos. La bomba requirió 27 pasos de programación. El hecho de no abordar tal complejidad mediante el diseño de una interfaz de usuario más intuitiva contribuyó a una muerte innecesaria.

Solución

La solución es reconocer y abordar la complejidad. Este punto suena lógico. Sin embargo, como se explicó anteriormente, las complicadas regulaciones de la FDA a menudo sorprenden a los líderes de las empresas. La negación no funciona. No planificar significa que su organización probablemente caerá en el 89 % de las presentaciones previas a la comercialización que la FDA rechazó en 2018.

Al realizar pruebas de usabilidad, los investigadores de la experiencia del usuario deben seguir tres pasos para gestionar la complejidad asociada con las regulaciones de la FDA:

1. El moderador (la persona que ejecuta la prueba de usabilidad) debe estar muy atento. Por ejemplo, si una resonancia magnética requiere que un técnico siga una secuencia estricta de pasos mientras usa el software asociado, el moderador debe observar cuidadosamente para determinar si el participante sigue las instrucciones al pie de la letra. De lo contrario, la tarea se califica como fallida, lo que significa que tanto el diseño de la interfaz como la documentación asociada requerirán modificaciones;
2. El moderador también debe realizar un seguimiento de las llamadas cercanas. Por ejemplo, un participante podría inicialmente realizar los pasos fuera de orden, descubrir el error y recuperarse siguiendo la secuencia adecuada. La FDA considera que esto es casi un error y el moderador debe informarlo como tal;
3. El moderador también debe evaluar los conocimientos del participante. ¿Cree que ha seguido la secuencia adecuada? ¿Es correcta esta creencia?

2. Síndrome del próximo lanzamiento

Un factor en la falta de reconocimiento de la complejidad es una mentalidad de arreglarlo más tarde que llamamos síndrome del próximo lanzamiento. Los errores de software no son un problema porque "los solucionaremos en la próxima versión". El énfasis en la velocidad sobre la calidad y la seguridad hace que sea muy fácil posponer la solución de los problemas difíciles.

Cualquier persona involucrada en el diseño y desarrollo de productos debe abordar el síndrome del próximo lanzamiento. Dos ejemplos aclaran el punto:

• Descubrimos graves fallas de diseño en el software de seguimiento de atención médica de un cliente. La empresa optó por lanzar el software sin abordar estos problemas. No es sorprendente que los clientes no estuvieran contentos.
• Realizamos pruebas de usabilidad para una gran cooperativa de ahorro y crédito con sede en los EE. UU. Los participantes eran asesores financieros experimentados. Las pruebas revelaron fallas de diseño graves, incluidos íconos de estado confusos, botones con un propósito poco claro y un enlace casi oculto que impedía que los participantes mostraran datos importantes. Recuerde, si el usuario no lo ve, no está allí. Cuando informamos sobre los hallazgos, la respuesta fue: "Lo arreglaremos en la próxima versión". Como era de esperar, la aplicación web no fue bien recibida. Las respuestas de los usuarios incluyeron: "¿Por qué nos pidió que revisáramos la aplicación si no tenía intención de hacer cambios?"

Solución: rechazar la mentalidad de arreglarlo la próxima vez

La solución es abordar los problemas serios de diseño ahora. Suena sencillo. Pero, ¿cómo convencer a los tomadores de decisiones para que cambien la mentalidad arraigada de “arreglarlo más tarde”?

La clave es cambiar la conversación sobre el logro de la entrega del producto hacia el valor creado. Por ejemplo, es probable que los equipos que se toman el tiempo para revisar un diseño basado en la investigación de los usuarios vean mejores reacciones de los clientes y, con el tiempo, una mayor lealtad de los clientes.

Fortalezca el caso mediante el uso de datos cuantitativos para mostrar a los tomadores de decisiones la conexión directa entre la investigación del usuario y el aumento de los ingresos y una experiencia positiva del cliente.

Redefinir el valor es, en efecto, una mejora del proceso porque establece un nuevo conjunto de prioridades que sirven mejor a los clientes y los intereses a largo plazo de su empresa. Como informa McKinsey en The Business Value of Design: “Las empresas del cuartil superior adoptan la experiencia de usuario completa; rompen las barreras internas entre el diseño físico, digital y de servicios”.

3. Tiempo insuficiente para iteraciones de diseño

En relación con el síndrome de la próxima versión, no hay tiempo suficiente para iterar el diseño en función de los resultados de la investigación o los requisitos comerciales cambiantes. “No tenemos tiempo para eso”, es el estribillo común de los desarrolladores y propietarios de productos. Los diseñadores que trabajan en entornos Agile con frecuencia se ven presionados para evitar "retrasar" al equipo de desarrollo.

El desarrollo se acelera y el software se lanza. Todos hemos visto los resultados de aplicaciones telefónicas confusas, software de registros médicos torpes y la interfaz de usuario engorrosa para asesores financieros mencionada anteriormente.

Solución: Pinchos de diseño

Una solución proviene del mundo de la codificación. En su artículo "Fitting Big-Picture UX Into Agile Development", Damon Dimmick ofrece la idea de picos de diseño, "burbujas de tiempo que permiten a los diseñadores centrarse en problemas complejos de UX". Encajan en el marco de Scrum al tomar temporalmente el lugar de un sprint regular.

Los picos de diseño ofrecen varias ventajas:

• Permiten que los equipos de UX se centren en problemas holísticos y eviten atascarse en problemas de diseño granulares que a veces se enfatizan en un solo sprint;
• Ofrecen la oportunidad de explorar preguntas complejas de UX desde un alto nivel. Si es necesario, el equipo de diseño de UX también puede participar en el pensamiento centrado en el diseño en cualquier momento para resolver desafíos de UX más grandes;
• Al adoptar picos de diseño, los equipos de UX pueden aprovechar la misma flexibilidad que los equipos de desarrollo utilizan en el proceso ágil y dedicar el tiempo necesario para centrarse en problemas de diseño que no siempre encajan bien en un sprint de scrum estándar;
• El desarrollo que probablemente no se verá afectado por las decisiones de diseño puede continuar.

Naturalmente, las iteraciones de diseño a menudo afectan ciertas partes del código de un sitio, una aplicación o un producto de software. Por esta razón, durante los picos de diseño, cualquier código que probablemente se verá afectado por el pico de diseño no puede avanzar. Pero, como dice claramente Dimmick, este "retraso" probablemente ahorrará tiempo al evitar la repetición del trabajo. Simplemente no tiene sentido escribir código ahora y luego volver a escribirlo unas semanas después de que el equipo haya acordado un diseño revisado. En resumen, posponer algo de codificación realmente ahorra tiempo y presupuesto.

4. Depender demasiado de los proveedores

Abordar la complejidad, resistir el síndrome del próximo lanzamiento y dar tiempo para la iteración son esenciales para un proceso de diseño eficaz. Para muchas empresas, otra consideración es su relación con los proveedores de software. Estos proveedores juegan un papel importante, incluso crítico, en el desarrollo. Sin embargo, otorgarles demasiada influencia dificulta el control de su propio producto.

Ciertamente, debemos tratar a los colegas y proveedores con respeto y hacer solicitudes razonables. Eso no significa, sin embargo, que sea necesario renunciar a todo el apalancamiento como sucedió durante mi mandato en una gran firma financiera.

Mientras trabajaba en esta firma como diseñador de UX, con frecuencia me encontré con esta dinámica:

Gerente : “Oye, Eric, ¿puedes evaluar este software de reclamos que planeamos comprar? Solo queremos asegurarnos de que funcione según lo previsto”.

Yo : “Claro, te enviaré mis hallazgos preliminares al final de la semana”.

Gerente : "Genial"

La semana que viene:

Gerente : “Gracias por la revisión. Veo que encontró tres problemas graves: dificultad para encontrar el número de un reclamo existente, pantallas con demasiado texto que son difíciles de leer y la dificultad de volver a una pantalla anterior al procesar un nuevo reclamo. Eso es preocupante. ¿Crees que esos problemas obstaculizarán la productividad?

Yo : “Sí, creo que estos problemas aumentarán el estrés y el tiempo de procesamiento en el Centro de Reclamos. Estoy bastante preocupado porque mi trabajo anterior con el equipo de Janet demostró que los representantes del Centro de Reclamos ya están muy estresados”.

Gerente : “Muy bueno saberlo. Acabo de enviar el cheque. Le pediré al proveedor que arregle los problemas antes de que se envíen”.

Yo (gritando por dentro): “¡Noooooooooooooo!”

Este gerente bien intencionado hizo precisamente lo incorrecto. Pidió cambios después de enviar el cheque. No sorprende que el proveedor nunca haya realizado los cambios solicitados. ¿Por qué lo harían? Tenían su dinero.

Este escenario no solo se presentó repetidamente en esa empresa, sino que lo he presenciado a lo largo de mi carrera de UX.

Solución

La solución es clara. Si el producto del proveedor no satisface las necesidades comerciales y del cliente, y los cambios que solicita están dentro del alcance, no pague hasta que el proveedor realice los cambios. Es realmente así de simple.

Conclusión

En este artículo, hemos identificado cuatro barreras comunes para el diseño de calidad y las soluciones correspondientes:

1. Regulaciones y estándares complejos
   La solución es reconocer y abordar la complejidad al diseñar plazos realistas y un presupuesto suficiente para la investigación y el diseño iterativo.
2. Envío de software con errores con la promesa de corregirlos más tarde
   La solución es evitar el síndrome del próximo lanzamiento y abordar los problemas graves ahora. Persuadir a los tomadores de decisiones redefiniendo el significado de valor dentro de su organización.
3. Tiempo insuficiente para iteraciones de diseño.
   La solución es incluir picos de diseño en el proceso de desarrollo ágil. Estas burbujas de tiempo reemplazan temporalmente a un sprint y permiten a los diseñadores concentrarse en problemas complejos de UX.
4. Depender demasiado de los proveedores
   La solución es retener el apalancamiento mediante la retención del pago final hasta que el proveedor realice los cambios solicitados, siempre que estos cambios estén dentro del alcance del proyecto original.

La cuarta solución es sencilla. Si bien los tres primeros no son fáciles, son concretos porque se pueden aplicar directamente a los procesos de diseño existentes. Su implementación no requiere una reorganización masiva ni millones de dólares. Simplemente requiere compromiso para ofrecer una mejor experiencia.