Capítulo 2: Calcular lo que esperan

From The Joel on Software Translation Project

Jump to: navigation, search

Diseño de Interfaz de Usuario para Programadores
Capítulo 2: Calcular lo que esperan

Por Joel Spolsky
11 de Abril de 2000
Traducido originalmente por: Angel García Cuartero
Editado por JM
Artículo original


Cuando un nuevo usuario se pone a usar un programa, no viene como una hoja en blanco. Tiene ciertas espectativas de cómo cree que el programa va a funcionar. Si ha utilizado una aplicación parecida, pensará que ésta nueva va a funcionar como la otra. Si ha usado cualquier software anteriormente, pensará que tu software se atiene a ciertas convenciones comunes. Puede que intuyan inteligentemente cómo va a funcionar el IU. Esto es lo que se conoce como modelo de usuario: es la comprensión mental de lo que el programa está haciendo para él.

El programa también tiene un "modelo mental", sólo que está codificado en bits y será ejecutado de manera fiel por la CPU. Esto es lo que se conoce como modelo de programa y es La Ley. Tal como hemos aprendido en el Capítulo Uno, si el modelo de programa corresponde al modelo de usuario, tu interfaz de usuario tendrá éxito.

Echemos un vistazo a un ejemplo. En Microsoft Word (y en la mayoría de procesadores de texto), cuando metes una imagen en tu documento, la imagen realmente queda empotrada en el mismo fichero que el propio documento. Puedes crear la imagen, arrastrarla al documento, luego borrar el fichero de la imagen original, pero la imagen permanecerá en el documento.

Bien, pues HTML no te deja hacer esto. Los documentos HTML deben almacenar sus imágenes en un fichero separado. Si tomamos un usuario habituado a procesadores de texto, que no sabe nada de HTML, y lo sentamos enfrente de un bonito editor HTML tipo WYSIWYG como FrontPage, casi seguro pensará que la imagen va a ser almacenada en el fichero. Llamemos a esto inercia del modelo de usuario, si os parece.

Así que tenemos un desgraciado conflicto entre el modelo de usuario (la imagen se empotra en el documento) y el modelo de programa (la imagen debe estar en un fichero separado), y por ello, el IU seguro que causará problemas.

Si estás diseñando un programa como FrontPage, acabas de encontrar tu primer problema de IU. No puedes cambiar HTML. Algo tiene que haber que alinee el modelo de programa con el modelo de usuario.

Tienes dos opciones. Puedes intentar cambiar el modelo de usuario. Esto resulta extraordinariamente difícil. Puedes explicar cosas en el manual, pero todo el mundo sabe que los usuarios no leen los manuales, y probablemente no tendrían por qué hacerlo. Puedes mostrar una pequeña ventana de diálogo explicando que el fichero de la imagen no va a ser incluido, pero esto tiene 2 problemas: es molesto para los usuarios avanzados y de todas maneras, los usuarios no leen cuadros de diálogo (hablaremos de esto en el Capítulo Seis).

Así que si la montaña no va a Mahoma... tu mejor elección casi siempre va a ser cambiar el modelo de programa, no el modelo de usuario. Quizás cuando inserten la imagen en el documento, puedas hacer una copia de la imagen en un subdirectorio por debajo del fichero del documento, de manera que al menos puedas casar la idea del usuario de que la imagen ha sido copiada (y el original puede ser borrado de manera segura).

¿Cómo sé cuál es el modelo de usuario?

Esto resulta bastante fácil. ¡Pregúntaselo a ellos! Elige al azar a cinco personas de tu oficina, o amigos, o familia, y diles lo que hace el programa en términos generales ("Es un programa para hacer páginas web"). Luego descríbeles la situación: "Tienes una página en la que estás trabajando, y un fichero con una imagen que se llama Imagen.JPG. Insertas la imagen en tu página web". Entonces hazles algunas preguntas para probar e intenta averiguar su modelo de usuario. "¿Dónde ha ido la imagen? Si borras Imagen.JPG, ¿la página web será todavía capaz de mostrar la imagen?"

Un amigo mío esta trabajando en una aplicación de un álbum de fotos. Después de insertar las fotos, la aplicación muestra un montón de miniaturas: pequeñas muestras de cada imagen. Bien, generar estas pequeñas miniaturas toma mucho tiempo, especialmente si tienes un montón de imágenes, así que lo que él quiere es almacenar estas miniaturas en el disco duro en algún sitio de modo que sólo tengan que ser generadas una vez. Hay muchas maneras para hacer esto. Se pueden almacenar en un fichero enorme llamado Miniaturas. Se pueden guardar en ficheros separados, en un subdirectorio llamado Miniaturas. Se puede marcar los ficheros como ocultos desde el sistema operativo, de modo que los usuarios no los vean. Mi amigo eligió una de las maneras de hacerlo en lo que él pensó que era lo que más le compensaba: guardó una miniatura de cada imagen imagen.JPG en un nuevo fichero llamado imagen_t.JPG en el mismo directorio. Si hacías un álbum con 30 imágenes, cuando acababas tenías 60 ficheros en el directorio, incluyendo las miniaturas.

Podríamos discutir durantes semanas acerca de los méritos y deméritos de los diversos modos de almacenar las imágenes, pero lo cierto es que hay una manera mucho más científica de hacerlo. Pregunta a un montón de usuarios dónde creen que se van a almacenar las miniaturas. Por supuesto, muchos de ellos dirán que no lo saben o que no les importa, o que no han pensado en ello, pero si preguntas a mucha gente, comenzarás a ver cierta clase de consenso. La elección popular es el mejor modelo de usuario, y depende de ti hacer que el modelo del programa se ajuste a él.

Después, tienes que poner a prueba tus teorías. Construye un modelo o prototipo de tu interfaz de usuario y mándales tareas a la gente. Según van trabajando con las tareas, pregúntales qué creen que está pasando. Tu objetivo es calcular qué es lo que esperan. Si la tarea es "inserta un imagen", y ves que están intentando arrastrar una imagen al programa, te darás cuenta de que será mejor incluir soporte para arrastrar y soltar. Si van al menú Insertar, verás que será mejor tener una opción para Imagen en ese menú. Si van a la barra de herramientas de Fuentes y reemplazan las palabras "Times New Roman" con las palabras "Insertar Imagen", acabas de encontrar una reliquia que no conoce todavía los entornos gráficos y que espera encontrarse un intérprete de línea de comandos.

¿Cuántos usuarios necesitas para probar con ellos tu interfaz? El instinto dice que "cuántos más, mejor", y tiene sentido para experimentos científicos. Pero ese instinto está equivocado. Casi todo el mundo que se gana la vida haciendo pruebas de usabilidad parece creer que cinco o seis usuarios bastan. Después de eso, se empiezan a ver los mismos resultados una y otra vez, y añadir más usuarios es una pérdida de tiempo.

No te hace falta un laboratorio formal de usabilidad, y ni tampoco traer usuarios "de la calle" -- puedes hacer pruebas de "todo a cien" en las que simplemente te coges al primero que pase por allí y le pides que haga una pequeña prueba. Asegúrate de que no lo echas todo a perder diciéndole cómo hacer las cosas. Pídele que "piense en alto" e interrógales haciendo preguntas abiertas para intentar descubrir su modelo mental.

Si tu modelo de programa no es trivial, probablemente no es el modelo del usuario

Cuando tenía 6 años y mi padre trajo a casa una de las primeras calculadoras de bolsillo, una HP-35, intentó convencerme de que tenía un ordenador dentro. No creí que fuera posible. Todos los ordenadores en Star Trek era del tamaño de una habitación y tenían unas enormes unidades de cinta. Pensé que debía haber algún tipo de correlación inteligente entre las teclas del teclado y los elementos individuales de la pantalla que hacía que aquello produjera resultados matemáticamente correctos. (Eh, tenía 6 años).

Una regla buena regla general es la de que los modelos de usuario no son muy complejos. Cuando la gente tiene que pensar cómo va a funcionar un programa, intentan pensar en cosas simples, más que en cosas complicadas.

Siéntate en un Macintosh. Abre dos hojas Excel y un fichero Word. Casi todo usuario novato creería que las ventanas son independientes. Parecen independientes:


Excel, antes de hacer clic


El modelo de usuario dice que al pulsar en la Hoja 1, eso traerá al frente dicha ventana. Lo que en realidad ocurre es que la Hoja 2 viene al frente, un sorpresa frustrante para casi todo el mundo:


Excel, después de hacer clic


Resulta que el modelo de programa de Microsoft Excel dice que "hay unas hojas invisibles, una para cada aplicación, y las ventanas están 'pegadas' a ellas. Cuando traes Excel a primer plano, todas las ventanas de Excel se moverán al frente también".

Vaaaaaaaaaaaaaale. Hojas invisibles. ¿Qué posibilidades hay de que el modelo de usuario incluya el concepto de hojas invisibles? Probablemente cero. Así que los nuevos usuarios se verán sorprendidos por este comportamiento.

Otro ejemplo del mundo de Microsoft Windows es la combinación de teclas Alt+Tab que cambia a la "siguiente" ventana. La mayoría de los usuarios probablemente asumirá que simplemente rota entre todas las ventanas disponibles. Si tienes las ventanas A, B y C, con A activa, Alt+Tab debería llevarte a B. Alt+Tab de nuevo te llevaría a C. En realidad, lo que ocurre es que el segundo Alt+Tab te lleva de vuelta a A. La única manera de ir a C es mantener pulsada Alt y pulsar Tab dos veces. Es una bonita manera de alternar entre dos aplicaciones, pero casi nadie se lo imagina, porque es un modelo ligeramente más complicado que el modelo de rotar-entre-todas-las-ventanas-disponibles.

Ya es suficientemente duro hacer que el modelo de programa se ajuste al modelo de usuario cuando los modelos son simples. Cuando un modelo se vuelve complejo, es incluso más difícil, así que elige el modelo más simple posible.

<< Capítulo 1: Controlar Tu Entorno Te Hace Feliz

>> Capítulo 3: Decisiones


The Joel on Software Translation Project - Español

Personal tools