Los monos y las pistolas

Hay una frase habitual que se suele utilizar cuando queremos referirnos a una situación con mucho riesgo: “es más peligroso que un mono con pistolas”.

Lo cierto es que me gusta, ya que da una idea exacta de lo que pasaría si un simio tuviera un arma cargada, especialmente si decidiera usarla. Nadie sabe a qué dispararía, ni cuántas balas, ni habría posibilidad de predecir sus consecuncias.

Estas navidades le regalaron a mi hijo un juguete compuesto por dos piezas: una especie de cubo en el que cada cara tenía un juego, con música, con piezas, unos muñecos para darles vueltas…; por otra parte, sobre el cubo se pone un juego de alambres de colores, con piezas de plástico que hay que mover de un extremo a otro.

Está claro que nosotros, como adultos, tenemos una idea exacta de cómo hay que jugar, y que las piececitas hay que desplazarlas a lo largo del alambre, y que la estrellita entra en el hueco de la estrellita, y que dándole al botón naranja sonará música.

Sin embargo, mi hijo aporrea el cubo, le da vueltas a una bola que hace ruido, castiga a los muñequitos, y se pone como sombrero los alambres cuando le apetece, o lo castiga sin misericordia.

¿Por qué? Porque no sigue el razonamiento lógico de quien inventó el juguete, ni las normas que todos hemos aprendido a la hora de jugar. A él le gusta golpear el juguete, aunque ignoro la razón, y le gusta volcarlo, y no mete las piezas en su hueco, sino que las agita y luego las aparta.

Si nos paramos a pensar, seguro que encontraremos un paralelismo con los usuarios de las aplicaciones informáticas

Lo que pasa es que son muy parecidos monos con pistolas y a los bebés: impredecibles.

La gente que diseñamos e implementamos sistemas informáticos tenemos en la mente una manera de utilizar los componentes, y un método muy estructurado de navegación a través de las pantallas: primero A, luego B y como resultado C.

Sin embargo, lo primero que aprendí yo cuando trabajé en mi primer proyecto fue que esto no se acerca a la realidad. Los usuarios para los que tenía que diseñar el sistema apenas tenían formación en informática, por lo que todo debía ser fácil, intuitivo y sin margen de error, puesto que se jugaban el tener o no agua para regar los campos.

Hay varias leyes que se cumplen y que es necesario tener en cuenta, tanto a la hora de plantear la solución como en el momento de implementarla y probarla:

- Si algo se puede pulsar, aunque no sea conveniente, el usuario lo pulsará. La funcionalidad más utilizada puede llegar a ser un botón que ponga “No pulsar”.

- Aunque creas que el usuario lee los mensajes de advertencia, tranquilo, nunca lo hará, a no ser que lo destaques en rojo y le provoques un ataque de pánico. Aún en ese caso, no hay nada seguro.

-El botón Aceptar y Siguiente provocan una misteriosa atracción que el usuario no puede rechazar.

- Si quieres que haga A-B-C entonces no le dejes hacer nada más. No son buenos chicos. Tampoco malos, sólo curiosos.

- Una vez le has enseñado a hacer algo, no lo toques. Aunque la pantalla que cambies funcione bien, cualquier error que ocurra será culpa “del nuevo sistema”.

- Puedes hacer la mejor aplicación, pero si no tiene colores e iconos, seguramente no servirá.

- Innovar está muy bien, pero no esperes que los usuarios compartan tu punto de vista. Está muy acostumbrados al güindous, la excel y el güord, así que procura darles cosas parecidas o que no les suponga tener que buscar por toda la pantalla cómo se hace algo.

Seguro que hay más normas generales (podéis aportar las que consideréis oportuno) pero creo que éstas son importantes y bastante generales.

Recordar la metáfora de los monos y la pistola suele ser my útil si queremos evitarnos digustos, problemas e incidencias fantasma.

Esta entrada fue publicada en General, calidad, tecnología, usuarios y etiquetada , , . Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>