PDF de programación - Diseño: los usuarios al poder (I)

mordecki.com




Artículo




Por Daniel Mordecki
12 de junio de 2001

Artículos relacionados
Segunda parte de este artículo
Los objetivos del diseño
¿Qué es diseñar?

Cuando los que estamos en el negocio de e-business seamos capaces de hacernos una
auto crítica sincera, de las primeras cosas que tendremos que reconocer es que fuimos
absolutamente incapaces de generar una disciplina de diseño focalizada en los usuarios.
Tal vez esa sea la causa para que más del 90% de los sitios Web no sean visitados por
nadie.

Lo que entendemos por diseño

Cuando escribí el artículo "Algunos apuntes sobre diseño", en agosto de
2000, recibí numerosos comentarios. Por un lado, los amigos y
conocidos vinculados al diseño, que criticaron duramente el llamado a
no utilizar a discreción las nuevas tecnologías, el llamado a un diseño
casi Franciscano. Por otro lado, recibí algunos mensajes de aliento y
algún comentario del estilo: "usted me ayudó a decir que no a esa
introducción Flash que mi diseñador le quería poner al sitio. Realmente
yo no me animaba a decirle que no, y su artículo me dio los argumentos
y la fuerza".

Después de mucho
buscar llegué a 2 libros
que recomiendo leer, y
que son la base del
presente artículo: Presos
de la Tecnología, de Alan
Cooper y Usabilidad.
Diseño de sitios Web, de
Jakob Nielsen.

Esa dicotomía en los comentarios, me llevó a tratar de encontrar más información y elaboración sobre
el tema. Como todo en Internet, por cada hoja de información útil, existen mil hojas llenas de lugares
comunes, frases hechas e información absolutamente descartable. Después de mucho buscar llegué a
2 libros que recomiendo leer, y que son la base del presente artículo: Presos de la Tecnología, de Alan
Cooper y Usabilidad. Diseño de sitios Web, de Jakob Nielsen. El primero analiza el problema del
proceso de diseño y el segundo analiza el problema de como analizar el uso de un diseño. Ambos
tienen una premisa en común: en el mundo informático en general y en la Web en particular, los
diseños son en su mayoría pésimos. Y ambos coinciden al tratar de identificar las causas: el usuario
es el principal olvidado.

Diseñar es una actividad que nació mucho antes que la informática y
que se ha dividido en numerosas ramas del saber y de la actividad
profesional. El diseño en informática, no coincide con ninguna de ellas.
No se trata de diseño artístico en ninguna de sus facetas. Tal vez en
algún aspecto secundario el diseño artístico sea importante para el
diseño informático, pero el tronco, el corazón del diseño en informática,
no se trata de diseño artístico. Tampoco es diseño gráfico, ni es diseño
industrial. El diseño informático es el proceso de análisis y creación de la
interacción y la de los sistemas de computación con los seres humanos
que los usan y la experiencia de éstos al utilizarlos. Es el diseño de la
experiencia de la persona que usa el sistema, no es el diseño de la
apariencia del sistema.

El diseño informático es
el proceso de análisis y
creación de la interacción
y la de los sistemas de
computación con los
seres humanos que los
usan y la experiencia de
éstos al utilizarlos.

Cuando escribí el artículo anterior, no conocía esta definición, que me parece mucho más exacta y útil
que la que utilicé anteriormente.

La experiencia de los usuarios

Es muy difícil negar que la experiencia de los usuarios con las computadoras es nefasta. A los
programadores (y yo me cuento con gusto en las huestes de los programadores) nos duele asumir
esta realidad.

Pero que en el mundo moderno muchas tareas los obliguen a utilizar
computadoras, no quiere decir que la tarea sea gratificante. Las
pantallas están llenas de decenas de botones que el 90% de los
usuarios no sabe para que sirven, ni sabe porque están, ni sabe como
sacarlos. Y a medida que los distintos equipos industriales y aparatos
domésticos incorporan microprocesadores, comienzan a comportarse de
la misma forma desagradable y arrogante que se comporta el software.
Así el microondas, el video, el lavarropas, la el despertador y otros
aparatos otrora intuitivos y sencillos se han transformado en verdaderos desafíos. El 90% de los
botones y funciones no se usan para nada. No solo el grupo de los capaces de dejar el video pronto
para grabar un programa es muy pequeño con respecto a los usuarios de videograbadoras, dentro de
ese grupo, los que jamás grabaron un programa equivocado, o un día equivocado, son casi un
conjunto vacío.

Es muy difícil negar que
la experiencia de los
usuarios con las
computadoras es
nefasta.

El cajero automático

¿Conoce usted algún aparato más tosco y arrogante que el cajero automático?

Comencemos por el principio: si yo no tengo cuenta corriente, ¿porqué tengo que contestar cada vez
que lo utilizo la opción entre caja de ahorro y cuenta corriente? Y sin embargo el muy maldito lo
sabe: si yo me equivoco, él se da cuenta, porque conoce perfectamente que yo no tengo cuenta
corriente y me castigará duramente: como en el Juego de la Oca, caí en la casilla roja, que me manda
nuevamente al comienzo. ¿Y su caja de ahorro es en pesos o en dólares?

¿Cuanto dinero quiere retirar? Recuerde que tiene que ser múltiplos de cien. Primero, si tiene que ser
múltiplos de cien, podría por ejemplo, adelantar los dos ceros y no obligarme a poner hasta los
centésimos (y si me equivoco, otra vez casilla roja!!!). Segundo: ¿porqué no me indica cuanto puedo
sacar? el maldito lo sabe, jamás me dejará sacar un centésimo más de lo que tengo, pero no me lo
dice. No me lo dice ni siquiera cuando me informa: "Ha excedido el limite de retiro". Castigo!!! Casilla
roja!!! Vuelva a empezar. El sabe cuanto es, pero se lo guarda.

Nadie pensó en la interacción del usuario con el cajero cuando diseñó el sistema. Nadie se preguntó
porqué esa persona está allí, qué busca, cuáles son sus objetivos, y cómo se siente al interactuar con
el cajero automático.

Tal vez esa sea la causa de que a pesar de la inversión y los años que han pasado, los cajeros sigan
en la mayoría aplastante de los casos, desempeñando la misma y única función que el día que los
introdujeron: retiros, sin haber cumplido la promesa de permitir que las personas realicen la mayoría
de las transacciones fuera de las sucursales.

La alarma del auto

Debe haber pocas situaciones que lo hacen sentir a uno tan tonto como cuando abre la puerta de su
propio auto y comienza a sonar la alarma. Una de estas situaciones que lo hacen sentir a uno aún
más tonto es dejar las llaves dentro del auto y cerrarlo, y sin duda la situación culminante es la
combinación de ambas: la alarma activada y las llaves con el control dentro del auto, y éste cerrado.

La combinación bloqueo automático+alarma con control remoto, en su funcionamiento básico podrían
evitar prácticamente en su totalidad estas situaciones. Cuando se trancan las puertas se prende la
alarma, cuando se destrancan las puertas se apaga la alarma y ambas operaciones se realizan
solamente con las puertas cerradas y con el control remoto de la alarma. Lo desafío a encontrar una
situación en la que la alarma suene por otro motivo que no sea su fin específico, detectar un robo. Es
fácil prever un estacionamiento de supermercado donde no suenen permanentemente las alarmas.

Sin embargo la realidad es muy distinta. Los programadores, como tenemos un microprocesador
disponible, nos empecinamos en agregar "inteligencia" que lo único que hace es comprender

situaciones de borde, que se dan una de cada cien mil veces, y que
tienen como consecuencia inmediata un estacionamiento lleno de
alarmas sonando y una cantidad de conductores humillados.

Si la interacción es oscura, dura, frustrante, agregar funcionalidad hará
que en vez de ignorar el 75% de las funciones, ahora ignore el 85% de
las funciones, pero además que el 15% que se usa, sea aún más
oscuro.

Tal vez, la solución más
acertada que un
programador pueda
proponer es llenar la
alarma de carteles que
digan ¿Está Usted
seguro?

Diseño y Funcionalidad

Está ampliamente difundida la idea de que cuanto más funciones tiene un sistema, más útil será para
los usuarios. Esta afirmación es en esencia falsa y es fácil comprobarlo. Por ejemplo, la mayoría
aplastante de las funciones disponibles en el software de productividad personal (procesadores de
texto, planillas electrónicas, etc.) no solo no son utilizadas por la mayoría de los usuarios. Ni siquiera
sabe que existen. ¿Cuántas personas conoce que sepan que son los estilos de su procesador de texto,
o que alguna vez hayan creado una tabla de contenidos utilizando la función del menú y no a mano?

Otro problema de las funciones es que en muchos casos, agregar funcionalidad no mejora sino que
empeora el problema. Si la interacción es oscura, dura, frustrante, agregar funcionalidad hará que en
vez de ignorar el 75% de las funciones, ahora ignore el 85% de las funciones, pero además que el
15% que se usa, sea aún más oscuro, los botones más chiquitos, los menúes más largos, el área de
la pantalla utilizable más pequeño.

La función Guardar

Analicemos por ejemplo la función "Guardar". Esta función responde a un problema de diseño interno
de la mayoría de las computadoras. Existen dos tipos de memoria: la memoria RAM, de acceso rápido
y volátil, y el almacenamiento en discos, de acceso lento pero persistente. Debido a ésto, desde el
principio de los lenguajes de programación y sistemas operativos, éstos proveen funciones al
programador para trasladar información de un sistema de memoria al otro de modo de poder hacer
que los programas ejecuten eficientemente, y cumplan con la necesidad de guardar la información
almacenada en memoria RAM para que se transforme en información persistente al apagado del
equipo. El corazón de las funciones que manejan internamente esta problemática, tienen desde el
comienzo los mismos nombres que hoy utilizan habitualmente los usuarios: Abrir, Guardar y Cerrar.
(Open, Save or Flush, Close).

Sin embargo, desde el punto de vista del usuario, que in