No podré asistir este sábado a la desconferencia, pero si lo hiciera, esto es lo que os contaría [1] (preparaos que es largo…):
Luis escribía en su excelente resumen de @media que no se oyó la palabra usabilidad en ningún momento y concluía que no es necesario hablar de ella porque debe “venir de serie” en cualquier desarrollo. Totalmente de acuerdo. Es más, esto es algo en lo que venía pensando hace tiempo ya, quizás desde que estoy metido en un mega proyecto que ya va para los dos años de mi vida (el proyecto es mayor, pero es lo que yo he estado en él), en una mega empresa.
En septiembre de 2004 me incorporé en las fases de definición en este proyecto enorme de una empresa de seguros muy, muy conocida. Y casi desde el inicio tenía la sensación de que algo no estaba bien cada vez que alguien mencionaba “usabilidad” en reuniones, mails o discusiones. El problema no era que se hablase de ello, sino que se utilizaba como si fuese un elemento más del producto, como una fase de trabajo… estaba al mismo nivel que la programación o el diseño de la lógica de negocio. Se pasaba del “diseño técnico” a la fase de “usabilidad” y luego a la maquetación. No me cuadraba, pero no sabía bien por qué. Ahora, gracias al comentario de Luis, acertadamente sintetizado por Javier (“La usabilidad viene de serie, señores”), lo he podido ver claro. ¡Eso es! Es que no se trata de aplicar una capa de pintura sobre una pared agrietada, es que la pared debe estar construida ya pensando en que no se va a llenar de grietas…
Recuerdo cuando a fines de los 90 tratábamos de convencer a los clientes de que debían pagar el trabajo de un consultor en usabilidad para que todo fuese bien y la incredulidad de muchos cuando decían “pero vamos a ver… ¿me decís que tengo que pagar más por algo que doy por hecho, es decir, que lo que vais a hacerme esté bien diseñado?” Y claro, había que explicarle que sí, que ese buen diseño implicaba varias actividades que no estaban normalmente contempladas en el proceso de diseño de una interfaz, hasta ese momento limitado al aspecto estético, y que por eso le saldría más caro.
Hoy, que ya hemos aprendido algo, no incluimos “usabilidad” como un aparte dentro de las propuestas comerciales. O al menos, no deberíamos hacerlo. Porque la usabilidad se da por descontada. Es lógico que las interfaces tienen que ser simples de usar, ser amigables y cumplir con todas esas características que tan bien enumerábamos en las presentaciones. La diferencia está en hacer un buen producto, no sólo un producto “usable”.
Volviendo al inicio de este texto, decía que aquí, donde consumo mis horas laborales, eso no acaba de entenderse aún. Y es que el equipo donde trabajo se llama “grupo de usabilidad”, y yo, soy el “especialista en usabilidad”. No pocos problemas me trae eso, porque para algunos soy una especie de Torquemada que tirará por tierra sus desarrollos e ideas geniales en las “auditorías” (palabra atemorizante por excelencia) que me encargan y para otros, un simple charlatán pinta-monas que contribuiré a que el proyecto salga más tarde y los programadores demoren más en hacer su trabajo. Y todo, para que al final salga un producto “que hace lo mismo que antes, pero más lento… con lo acostumbrados que estábamos a trabajar con el 3270 y las líneas de código”.
Y aquí es donde yo tengo que explicar que no se trata de complicarle la vida a nadie, que no es que no tengamos nada mejor que hacer ni que queramos retrasar los desarrollos. Sino que pensamos en los nuevos usuarios, que aprenderán más rápido; pensamos en los mantenimientos de las aplicaciones, que podrán ser hechos por cualquiera y no sólo por el programador original; pensamos en que las aplicaciones podrán ser escalables y que un equipo de desarrollo a miles de kilómetros de distancia podrá crear una, siguiendo las guías de estilo que hemos editado, etcétera.
Pero la dichosa palabrita se nos pega a la espalda y es un lastre. “Los de usabilidad”, “es norma de usabilidad”, “lo prohíbe usabilidad”, “usabilidad te va a auditar”… Así, es francamente complicado explicar que no, que lo que hacemos es diseñar buenas aplicaciones, buenos productos. Y que lo necesitan, igual que como necesitan un buen jefe de proyecto o un buen programador. Que el diseño del producto no es solamente un tema de costes y tiempos, sino de personas, de interacción de esas personas. Esa es la clave, la interacción.
Intento explicarles que lo que importa no es que la aplicación sea bonita, sino que funcione. Que los procesos sean lógicos, que los usuarios tengan aplicaciones que les solucionen los problemas, que se comporte como se espera.
Quizás haré como Luis y voy a intentar eliminar la palabra “usabilidad” de mi discurso. Me centraré en la interacción, en los procesos, en los tiempos (o “tempos”) de la aplicación. Y con ello, trataré de demostrarles que el buen diseño no está reñido con los proyectos ágiles.
Creo, sinceramente, que son precisamente las grandes corporaciones como esta, las que más necesitan de un trabajo serio en diseño de interacción, para que la “usabilidad” no siga siendo un añadido, sino algo de serie.
Como decía al principio, hace casi dos años que estoy trabajando en un proyecto en una empresa bastante grande de seguros, dentro del llamado Grupo de Usabilidad. La misión de este equipo de gente es participar en un gran proyecto de renovación de herramientas informáticas propias. Es decir, el software que hace que el negocio funcione.
Normalmente las grandes empresas, como bancos, aseguradoras, telefónicas y otras por el estilo, tienen sus propios departamentos de informática que trabajan haciendo desarrollos a medida de las necesidades. Es cierto que muchas veces se contratan estos trabajos a empresas externas, pero cada vez es más común que el trabajo se haga en casa. Por motivos básicamente prácticos y de confidencialidad.
Una empresa de seguros, por ejemplo, no encuentra en el mercado un paquete de software que pueda cubrir todas sus necesidades, dada la complejidad del negocio y las particularidades de cada empresa. Eso sin entrar en los intrincados vericuetos de la organización misma (estructura de administración, de ventas, de agentes, etc). Todo ello se traduce en mil y una pequeñas aplicaciones que se van creando a medida que se necesitan. Al cabo de unos años, lo que hay es un desorden absolutamente incontrolable y, lo que es peor, imposible de mantener.
Es en ese momento cuando puede surgir la iniciativa de hacerlo todo de nuevo. De recomenzar, pero contando con pautas estándares, siguiendo una metodología bien pensada y utilizando tecnologías comunes. Para que cuando sea necesario hacer algún cambio o mejora en el futuro, no cunda el pánico al darse cuenta de que el informático que “tenía todo el proyecto en su cabeza” se ha ido y nadie es capaz de meter mano en el código.
Ahora, este tipo de proyectos no son moco de pavo. Plantearse algo así en una empresa con miles de empleados y oficinas por medio mundo, es algo gordo. Muy gordo. Significa pensar en un proyecto que puede –y seguramente lo haga- durar algunos años. De ahí que la planificación y definición juegan un papel fundamental.
En el caso que nos ocupa, la empresa tomó la decisión de renovar sus aplicaciones por completo, migrándolas a un entorno web que permitiese una actualización y mantenimiento más sencillo, a la vez que poder asegurar una homogeneidad de estilo. Antes, cada aplicación adolecía de las “creatividades” individuales de los equipos de desarrollo que habían participado en ellas.
Dentro de este macro proyecto –curiosamente- se contempló la necesidad de contar con gente especialista en usabilidad. Ignoro quién tuvo la feliz idea, pero sin duda que fue una inspiración que ha valido la pena (no así el nombre del grupo).
Lo más interesante de todo este trabajo, más allá de estar en una de las corporaciones más grandes de España, ha sido el constatar la necesidad que tienen este tipo de empresas de tener equipos de diseño dentro.
Principalmente, la participación de gente dedicada al diseño de interacción puede asegurar que todo el proyecto tenga coherencia. Que todo lo que se haga sea homogéneo y que “respire” un aire familiar. Da igual cuántos programadores, jefes de proyecto, coordinadores o lo que sea, estén involucrados. El producto final, siempre parecerá hecho por los mismos. Algo que las grandes empresas de software han entendido hace mucho tiempo ya y que no sé porqué en otros mercados recién se está tomando conciencia de su importancia.
¿Se imagina alguien que los programas de Apple se comportasen todos de forma diferente o que tuviesen estilos visuales distintos entre sí? O el mismo Microsoft Office: si Word, Excel y PowerPoint, por ejemplo, usasen distintos botones, una distribución de menús propia de cada uno y los menús tuviesen diversos nombres para las mismas acciones, sería un caos. De hecho, nadie lo compraría. Pero parece ser que cuando se trata de los desarrollos propios de otras empresas, todo eso da lo mismo.
Un equipo de diseño involucrado desde el principio aporta precisamente eso, la tranquilidad de saber que existe un control de calidad y una definición de estilos y procesos que además, no choca con los principios de facilidad de uso y eficiencia. Que la usabilidad va de serie, en definitiva.
Si esto se hubiese tomado en cuenta desde el principio, si el “grupo de usabilidad” no hubiese sido un extra -compuesto además por personal externo-, se habrían evitado discusiones tan peregrinas como el correcto diseño de un formulario o la necesidad o no de tener mensajes de espera en las aplicaciones que hacen consultas complejas a la base de datos. Nadie pone en duda los dictámenes de un departamento de arquitectura de sistemas o el de metodología, porque están incorporados de base. Ya es hora de que el diseño de interacción lo esté también.
Creo que nuestra tarea, la de quienes estamos trabajando en proyectos similares en empresas grandes, debe ser también convencerles de que incorporen en su trabajo diario el Diseño, así con mayúsculas. Que dejen de verlo como el peluquero que se llama para tratar de arreglar a la novia en el último minuto. El diseño debe estar dentro, ser indiscutible, tener un papel fundamental. Que dejen ya de hablar y discutir sobre usabilidad, porque ya llevamos mucho tiempo en lo mismo como para no darnos cuenta de que si no se lleva puesta, no sirve de nada.
Cuando esto suceda en las grandes corporaciones, habremos dado el principal paso para dejar de hablar de ello. Habremos llegado al punto más alto en la curva de aceptación de un nuevo concepto o idea y podremos, por fin, dedicarnos a lo bonito: diseñar y solucionar los problemas de las personas.
[1]Propongo además, de este modo, la participación asíncrona para todos los que -por motivos personales, geográficos o simplemente estomacales- no podamos asistir.
sino porque saben que entonces la aplicación dejará de tener sentido precisamente para esos usuarios que la eligieron por ser simple.
Tengo en casa una 