Valor de un Design System: el impacto del diseño y la usabilidad en sistemas complejos

Los métodos tradicionales de diseño de software presentan un problema: es completamente posible crear un sistema que no sea útil ni intuitivo pero que cumpla con las pautas de usabilidad. Por lo general, se recopila una lista de nuevas características, actualizaciones funcionales y listas de deseos de componentes de partes interesadas clave y usuarios representativos, y se entrega a un equipo de desarrollo talentoso que hace todo lo posible para coordinar los requisitos y crear un sistema unificado que tendrá sentido para los usuarios.

Así se crea un software con una pésima experiencia de usuario.

En este documento técnico, veremos un enfoque diferente: uno que parte de un conjunto de requisitos basados en las necesidades del usuario (en lugar de listas de deseos) y que involucra a analistas de usabilidad y profesionales del diseño desde el principio para colaborar y crear modelos rápidos y económicos de el sistema definitivo. Dado que este proceso de creación rápida de prototipos “en papel” no requiere código, es tan fácil de modificar como borrar una línea. También brinda la oportunidad de presentar el prototipo a los usuarios y probar tanto las ideas conceptuales generadas durante la recopilación de requisitos como la usabilidad a nivel de pantalla, asegurando que el producto final implementado será utilizable y útil.

Coches, casas y software

Los automóviles existen desde finales del siglo XIX. Comenzaron como carros mecanizados, propulsados por primitivos motores de combustión interna. Según todos los indicios, los primeros coches eran incómodos, poco fiables y peligrosos. Pero hicieron lo que los medios de transporte maduros de la época no podían. Podrían llegar más lejos y más rápido. Y aunque el propietario/operador también necesitaba actuar como su propio mecánico y fabricante de piezas, era suficiente.

Las casas existen desde hace bastante más tiempo que los automóviles. Al principio, protegerse de los elementos fue el factor decisivo a la hora de elegir una casa digna. Si mantenía alejada la lluvia y el viento, era suficiente.

El software, en particular el software empresarial, es el más reciente de los tres. El software es interesante porque no es un objeto físico como un automóvil o una casa y, por lo tanto, no está ligado a una forma o tamaño particular. Sin embargo, al igual que los automóviles y las casas, el software primitivo (y yo diría que casi todo el software actual que requiere interacción humana es software primitivo) se considera aceptable si contiene una lista impresionante de características y funciones. Independientemente de si cualquiera puede usarlo, si el software hace más que la versión anterior (o el software de sus competidores), es suficiente.

Lo que queda claro al seguir la evolución de estos tres es que, inicialmente, los sistemas complejos comienzan su existencia como eventos de ingeniería. Basta con que funcionen. A medida que pasa el tiempo, los sistemas complejos evolucionan desde lo de ingeniería hasta lo personal. Esto es ciertamente cierto para los automóviles y las casas. El software, sin embargo, no ha llegado a ese punto. Como se muestra en la Figura 1, Don Norman se refirió a esta idea en su libro de 1999 The Invisible Computer, aunque hablaba de hardware más que de software (ver Norman, D., 1999: The Invisible Computer).

El software es un producto joven, desde una perspectiva de evolución del producto. Si bien esto puede ser suficiente para explicar en gran medida por qué sigue siendo tan difícil de utilizar, no es motivo para aceptarlo. Cada pieza de software es el resultado de innumerables decisiones bien intencionadas. Fue diseñado para ser exactamente lo que es. Ese es el problema. No todos los productos están bien diseñados.

¿No es suficiente la usabilidad?

Las empresas intentan abordar el problema del diseño deficiente entregando las pantallas problemáticas a profesionales de usabilidad. A través de pruebas rigurosas y el cumplimiento de pautas consagradas, sin duda se puede mejorar la usabilidad general. Sin embargo, cuando se trata de sistemas complejos, mejorar la usabilidad una vez diseñado el sistema es similar a tratar los síntomas en lugar de la enfermedad. Teniendo esto en cuenta, la siguiente sección proporciona la respuesta a la pregunta que inicia esta sección:

La usabilidad no es suficiente

Hay varias formas de abordar el diseño de un nuevo sistema. En el primero, se recopila una lista de nuevas características, actualizaciones funcionales y listas de deseos de componentes de partes interesadas clave y usuarios representativos. Luego, esta lista se entrega a un talentoso equipo de desarrollo que hace todo lo posible para coordinar los requisitos y crear un sistema unificado que tenga sentido para los usuarios. Así es como se crea un software terrible. ¿Por qué? Porque los desarrolladores no son analistas de usabilidad ni diseñadores y se les pide que hagan el trabajo de ambos.

En el segundo, un líder de investigación de usuarios trabaja con partes interesadas clave y usuarios representativos para determinar las necesidades y requisitos de ambos grupos. Esto da como resultado un conjunto de requisitos más apropiado.

Esto es increíblemente poderoso. Por lo general, ni los usuarios ni las partes interesadas son capaces de ver más allá de su lista de deseos inmediatos y la diferencia entre la mejora incremental, brindar a los usuarios lo que quieren, y la innovación (darles a los usuarios lo que necesitan) radica en la obtención de requisitos calificados. Si bien este nuevo sistema se basará en un excelente conjunto de requisitos, cuestiones como el diseño de la pantalla, los modelos de interacción y la visualización de datos (es decir, cuestiones de diseño) todavía están siendo determinadas por roles cuyas competencias centrales no son el diseño.

En el tercero, los líderes de investigación de usuarios y los profesionales del diseño colaboran, recopilando requisitos y creando formas innovadoras de ayudar a los usuarios a medida que completan su trabajo de maneras que nunca soñaron. ¿Suena demasiado utópico? Es cierto y cuando puedes ser parte de ese “proceso de diseño” como parte interesada, usuario o miembro del equipo, es algo hermoso. Los sistemas emergentes de diseño a código, como Indigo.Design también ayudan a facilitar una verdadera colaboración entre el diseño y el desarrollo de UX.

No es raro que los clientes potenciales de una investigación de usuarios descubran que incluso los propios usuarios finales no siempre saben lo que necesitan.

He aquí un ejemplo: en el parqué de muchas empresas financieras, no es raro ver la estación de trabajo de un operador con cuatro monitores montados dos sobre dos, en un solo pedestal, en un ángulo tal que básicamente envuelven la cabeza del operador. En los monitores normalmente verá una combinación compleja de hojas de cálculo, gráficos de líneas y puntos de datos que se desplazan, parpadean y colorean. Se podría suponer que el comerciante no tenía mucho control sobre cómo se mostraban los datos y que simplemente estaban transmitiendo datos de otras fuentes. Pero cuando a un operador de una empresa financiera le preguntaron “¿Quién controla la forma en que se muestran los datos en la pantalla?”, la respuesta del operador fue sorprendente: “Nosotros sí. Tenemos control total de los datos y de cómo se muestran”.

Se podría pensar que diría que le gustaría ver información importante resaltada o incluso algo tan simple como "evitar que estas cosas parpadeen todo el día". Pero cuando le preguntaron a este comerciante qué le ayudaría a facilitar su trabajo, dijo que quería un procesador más rápido porque el que tenía solo podía ejecutar 4 monitores. Con un procesador más rápido podría tener seis”.

Cuando piensas en esa respuesta, te das cuenta de los límites de la perspectiva del usuario. ¿Eso habría mejorado su desempeño? Para los traders más experimentados, probablemente habría resultado en cierto grado de mejora incremental. Pero no es lo que necesitaban.

Investigación de usuarios: comprender lo que necesitan los usuarios

Lo que un usuario necesita queda claro cuando lo observa trabajar. Queda claro cuando les pide que expliquen por qué tomaron una determinada acción o por qué las acciones se tomaron en un orden determinado. La innovación se vuelve posible una vez que se comprende lo que el usuario intenta lograr. Durante una tarea, el comerciante intentaba decidir si comprar o vender un determinado producto financiero. Para hacer esto, estaba interesado en saber cómo se negociaban ciertas monedas entre sí, si las tasas de cambio entre las monedas tenían una tendencia en la dirección deseada a lo largo del tiempo y cómo se compara esto con las tasas de cambio históricas entre las monedas: preocupaciones como como tasa de cambio, tasa de cambio de la tasa de cambio y comparaciones históricas de tasa de cambio. Hay muchas formas de representar esta información. Una forma incluye 6 monitores de hojas de cálculo y gráficos de líneas. O un diseñador podría crear tres formas novedosas de visualizar los datos de la tasa de cambio de un vistazo (porque es en lo que son extraordinariamente buenos). Los usuarios no pueden pensar en estos términos. Francamente, tampoco pueden hacerlo la mayoría de los analistas de usabilidad.

He argumentado que la creación de software más evolucionado es posible mediante la implementación de un proceso de diseño que se basa en la colaboración entre los profesionales de la usabilidad y el diseño. ¿Qué pasaría si también pudiera disminuir el riesgo asociado con el desarrollo de software? Y dado que el riesgo normalmente genera costos, ¿qué pasaría si la experiencia y el diseño del usuario pudieran reducir el costo del desarrollo de software? Antes de analizar los dos modelos más destacados de desarrollo de software, sería útil considerar otra anécdota.

Una historia de dos Harrys... o cómo un resultado final puede no satisfacer las expectativas

Para explicar mejor los desafíos del desarrollo de software, consideremos la experiencia de niños jóvenes que se enamoraron de los libros de Harry Potter y su reacción al verlos en la pantalla grande. Cuando se estrenó la primera de las películas de Harry Potter, estos niños ya habían leído los tres primeros libros y estaban ansiosos por ver la película. Pero sucede algo interesante después de hacer fila, pagar $10 por boleto, comprar refrescos, dulces y palomitas de maíz y ver 90 minutos de las aventuras de Harry Potter. No les gustó.

Cuando se les preguntó por qué no les gustó la mudanza, dijeron que no era lo mismo que el libro. Al parecer, ni el guionista, ni el director ni los actores pudieron igualar la “película” que los chicos habían construido en sus cabezas. Por tanto, la película fue una decepción.

Este es exactamente el problema con los métodos tradicionales de desarrollo de software. La codificación comienza cuando todos los involucrados en el proyecto están de acuerdo en que los documentos de requisitos basados en prosa, que contienen la suma total de los deseos, necesidades y deseos de todos, capturan correctamente dichos deseos, necesidades y anhelos. Esta es la primera de las tres formas en que se puede crear software (descritas anteriormente). Las partes interesadas (y los usuarios) no sólo dependen de los desarrolladores para crear un sistema utilizable, sino que también dependen de los desarrolladores para crear un sistema que coincida con el sistema que ya han creado en sus mentes. Inevitablemente, muchos meses después, cuando se abre el telón y se revela la versión alfa, el equipo lucha por encontrar el sistema que imaginaron. A esto le siguen variantes de "Eso no es lo que esperaba". La única diferencia real entre el ejemplo de mi película y este ejemplo de desarrollo de software es que el padre de los niños solo gastó $40. El proyecto de software gastó más que eso en café.

Los dos principales procesos de diseño de software actuales son Waterfall y Agile. Cada modelo comienza con descripciones en prosa de los requisitos que describen lo que debe hacer el software. Cada uno comienza con un “Potencial de Riesgo” (mi término) de cero. Con esto quiero decir que al comienzo de la fase de desarrollo, todos están confiados y felices. No ha sucedido nada malo y todos creen que comparten una visión común del producto final. Entonces comienza el desarrollo y el riesgo comienza a aumentar. ¿Por qué? Porque se toman decisiones que hacen que la forma final del producto se desvíe de la visión de cada miembro del equipo. ¿Es culpa del equipo de desarrollo? Absolutamente no. Se han visto en la incómoda posición de tener que tomar decisiones de diseño mientras intentan hacer lo que les encanta hacer: codificar. Y así, a medida que pasa el tiempo, el riesgo aumenta cada vez más.

Como se demuestra en las Figuras 2 y 3, esto sucede ya sea que el proyecto siga una metodología en cascada o ágil. La cascada es la más problemática de las dos porque el resultado no está disponible hasta que se completa la compilación. Agile intenta abordar este problema dividiendo la compilación en sprints cortos. Sin embargo, esto solo permite vistas de piezas aisladas de funcionalidad, lo que requiere que el equipo imagine cómo funcionarán dentro del conjunto más amplio.

Ninguno de los procesos permite al equipo ver cómo se verá el sistema final, cómo se comportará o cómo interactuará con otros sistemas y otras funciones hasta que se complete el proceso de desarrollo. En ambos, el costo inicial de desarrollo es alto. Cambiar decisiones de diseño que ya se han implementado en el código es aún más costoso. La probabilidad de que los usuarios acepten un sistema de este tipo es pequeña.

Por otro lado, el proceso de diseño, como se muestra en la Figura 4, coordina las habilidades de los analistas de usabilidad y los profesionales del diseño y aborda este problema.

Además de crear un mejor conjunto de requisitos (que, sin duda, podrían ser el insumo para los métodos Waterfall o Agile), los profesionales de usabilidad y diseño también crean modelos rápidos y económicos del sistema final. A través de una rápida serie de bocetos, esquemas y maquetas de pantalla, el equipo puede proporcionar una visión del sistema completo que permite a todos reunirse, cuestionar y llegar a un acuerdo. Dado que este proceso de creación rápida de prototipos no requiere código, es tan fácil de modificar como borrar una línea. También brinda la oportunidad de presentar el prototipo a los usuarios y probar tanto las ideas conceptuales generadas durante la recopilación de requisitos como la usabilidad a nivel de pantalla. Una vez que se hayan solucionado los errores y todos compartan una comprensión común del producto final, el equipo de desarrollo puede comenzar a trabajar. Y además de los requisitos, también cuentan con diseños que demuestran de forma concreta la forma visual final de esos requisitos. Por lo tanto, el riesgo de desarrollo se minimiza antes de que comience la codificación y se mantiene relativamente constante durante todo el proceso de desarrollo.

Un buen diseño es un proceso iterativo basado en la investigación que descubre y define requisitos. Proporciona una comprensión de lo que los usuarios necesitan lograr, además de lo que quieren. Permite un consenso temprano, modificaciones y pruebas de usuario. Es rápido. Es económico. Es utilizable e intuitivo, hermoso e inspirador. Reduce el riesgo. Proporciona innovación en lugar de mejoras incrementales. Se adapta a los métodos de desarrollo de software existentes. Es escalable y soportable.

El software es un producto infinitamente maleable. Se puede moldear en absolutamente cualquier cosa. No hay necesidad de preocuparse por la disponibilidad de materias primas, la logística de transporte o el soporte de fábrica. Será para lo que fue diseñado. Todo lo que requiere es el deseo y un proceso para hacerlo grandioso.

Recursos

Norman, D. (1999). La computadora invisible: por qué los buenos productos pueden fallar, la computadora personal es tan compleja y los dispositivos de información son la solución. La prensa del MIT.