Sergio Gago

Ahora, en el auge del usuario como centro de los sistemas, vemos por internet cada vez más manuales baratos y gurús de la usabilidad que nos dicen como tenemos que poner nuestros formularios o cómo maquetar el texto. Poniendo reglas generalistas que supuestamente tienen que valer para todos.

Pero el hecho, es que cada sistema, cada aplicación o máquina/aparato tiene unas reglas de usabilidad totalmente distintas. Incluso en aplicaciones y páginas Web, donde la consultora “guay” es la que vende al cliente que sus sistemas cumplen AA, realmente lo único que tienen es una serie de patrones que intentan seguir hasta que se les pone delante el IExplorer 6… Y eso por no hablar de las grandes consultoras, donde por supuesto la usabilidad es en lo último que se piensa.

Pero… si a mi me habían dicho que me leyera unos manuales y aplicara lo que pone en mis diseños… y que hiciera las cosas como para que mi abuelita pudiera navegar por mi sitio Web….

MAL! ¿Por qué vas a diseñar tu sistema apto para que navegue tu abuelita por él si nunca lo va a hacer? Posiblemente, para quitar funcionalidades a tus verdaderos usuarios. Al final lo único que hacemos es ponernos a aplicar estándares y verdades a medias que alguien dijo alguna vez, sin pararnos a pensar si son lo que realmente necesitan los usuarios finales de lo que vamos a crear.

Seguimos quedandonos en el diseño centrado en el sistema, aunque camuflado. Veamos las principales diferencias:

Diseño centrado en el sistema

• ¿Qué es lo más fácil para la plataforma?
• ¿Como puedo llegar al mejor resultado con las herramientas / dinero / tiempo de que dispongo?
• ¿Qué partes encuentro más interesantes para poner más esfuerzo como programador / diseñador / analista / cualquier_otro_rol?

Diseño centrado en el usuario

• ¿Quién es el usuario?
• Su contexto
• Su trabajo
• Sus necesidades
• Sus tareas
• …
• ¿De verdad conozco al usuario?

En general, la mayor diferencia está en la descolocación de términos. En una, un buen trabajo implica un cliente satisfecho y en la otra un cliente satisfecho implica un buen trabajo ¿Adivináis cual aplica a cual?Pero bueno, podemos intentar dar solucinoes a todo esto…

El Dr. Saul Greenberg da algunas pistas…

• No hacer caso de la intuición
• Las entrevistas no son precisas y no se llevan actas correctas ni se llega al “quid” de la cuestión
• El diseñador no llega a conocer al usuario lo suficientemente bien para responderse a todas las preguntas que le surgen durante el proceso, y hace suposiciones.
• En ocasiones el contacto es con intermediarios, o con directivos, y no con el cliente final. Se llega a una relación de “teléfono estropeado”.

Las recomendaciones son, convertir al cliente en un usuario activo y crítico. No un mero receptor de servicios. La metodología de la programación extrema incluye al cliente dentro del equipo de desarrollo (por mucha locura que esto pueda parecer en España, parece funcionar fuera de nuestras fronteras), y un continuo trabajo de prototipado, aumentando la fidelidad del mismo poco a poco (incluso un prototipado “Mago de Oz” en el que una persona simula ser el sistema) y ya… Si realmente solucionamos los problemas de diseño antes de la primera iteración estaremos ahorrando mucho dinero y trabajo, amén de tener un cliente mucho más satisfecho.

Uno de los mayores errores de las grandes consultoras es pensar que lo más importante es un sistema muy seguro y estable, despreciando el diseño. Pero lo cierto es que si el cliente piensa que es “feo” o dificil de usar, pensara que el resto es una auténtica patata, y nuestra aplicación-para-todo, será una aplicación-patata. Y por cierto, esto es aplicable a cualquier campo de la ingeniería y, supongo, arquitectura (algún arquitecto puede corregirme).
En un post posterior hablaré de los prototipos.

Modificado: Me he tomado la libertad de traducir un gráfico de Saul Greenberg que resume bastante bien la evolución de los prototipos y del diseño centrado en el usuario:

(click para ampliar).

Y para terminar, la guinda la puede poner Dilbert.