Capítulo 6: Diseñar para gente que tiene cosas mejores que hacer con su vida

From The Joel on Software Translation Project

Jump to: navigation, search

Diseño de Interfaz de Usuario para Programadores
Capítulo 5: Consistencia y Otros Duendes

Por Joel Spolsky
26 de Abril de 2000
Traducido originalmente por: Raúl Herranz Serrano
Artículo original


Cuando diseñas interfaces de usuario es una buena idea tener dos princicipios en la cabeza:

  • Los usuarios no tienen el manual, y si lo tuvieran no lo leerian.
  • En realidad, los usuarios no quieren leer nada, y si pudieran, no querrian hacerlo.

Estos no son, estrictamente hablando, hechos, pero debes actuar como si lo fuesen, para que tu programa sea mas fácil e intuitivo. Diseñar con estas ideas en la mente se llama respetar al usuario, lo que significa, no tener mucho respeto por el usuario. ¿Confundido? Déjame explicarte.

¿Que quiere decir que algo sea fácil de usar? Una forma de contabilizarlo es ver la cantidad de personas que pueden completar una tarea en una determinada cantidad de tiempo. Por ejemplo, supón que el objetivo de tu programa es convertir fotos de una cámara digital en un álbum de fotos para la web. Si sientas a un grupo de usuarios promedio con tu programa y les pides que hagan esa tarea, entonces mientras más usable es tu programa, será mayor el porcentaje de usuarios que podrán crear el álbum de fotos para la web.

Para ser cientifico, imagina 100 usuarios del mundo real. Ellos no están familiarizados con los ordenadores. Tienen diferentes habilidades, pero algunos de ellos claramente no tienen capacidad en el área de los ordenadores. Algunos están distraidos mientras intentan usar tu programa. El teléfono está sonando. ¿QUE? El bebé está llorando. ¿QUE? Y el gato saltó al escritorio y está peleando con el ratón. ¡NO PUEDO ESCUCHARTE!.

Ahora, aún sin realizar el experimento, yo puedo decirte con cierta seguridad que algunos de los usuarios simplemente no completarán la tarea, o les llevará una cantidad de tiempo extraordinaria. No quiero decir que sean estúpidos. Más bien lo contrario, son probablemente muy inteligentes, o quizá sean atletas expertos, pero vis-à-vis [frente a frente de] tu programa, no están utilizando todas sus capacidades motrices y células de su cerebro en el uso de tu programa. Sólo estás consiguiendo alrededor del 30% de su atención, así que tienes que trabajar con un usuario que, desde el punto de vista de la máquina, no es del todo muy listo.

Los usuarios no leen el Manual

En principio, en éste momento ellos no tienen el manual. Podría no haber un manual. Si hay uno, el usuario podría no tenerlo, por todo tipo de razones lógicas: Están en un avión, están usando una demo bajada de tu página; están en casa y el manual está en el trabajo; el departamento de informática nunca les dió el manual. Aún si tienen el manual, francamente, no lo leerán a menos que no les quede otro remedio. Con muy pocas excepciones, los usuarios no se arroparán calientitos para leer tu manual completo antes de empezar a usar tu programa. En general, tus usuarios están tratando de llevar a cabo alguna cosa, y ven como una pérdida de tiempo el leer el manual, o como mínimo, una distracción que les impide terminar su tarea.

El hecho de que estés leyendo el libro te pone en una élite de de gente altamente instruida. Si, sé que la gente que usa ordenadores es mayormente capaz de leer, pero te garantizo que la mayor parte piensa que leer es una faena. El lenguaje en el que el manual está escrito podría no ser su lengua materna, y puede que no dominen el lenguaje. ¡Podrían ser niños! Pueden descifrar el manual si tienen que hacerlo, pero no lo leerán si no es estrictamente necesario. Los usuarios leen los manuales sobre la marcha, y sólo cuando necesitan saber algo en concreto.

Como resultado, probablemente no tendrás otra opción que diseñar tu software de tal forma que de entrada no sea necesario un manual. La única excepción que se me ocurre es que los usuarios que no tengan ningún conocimiento del tema, que realmente no puedan entender qué se pretende que haga el programa, pero saben que más les vale aprender. Un gran ejemplo es el inmensamente popular programa de contabilidad para pequeñas empresas QuickBooks, de Intuit. Muchos de los usuarios del programa son propietarios de pequeños negocios que simplemente no tienen idea de qué se trata la contabilidad. El manual de QuickBooks da por echo esto y supone que tendrá que enseñar a la gente los principios básicos de la contabilidad. No hay otra forma de hacerlo. Si sabes contabilidad, QuickBooks es fácil de usar sin el manual.

De hecho, los usuarios no leen nada

Esto puede sonar un poco duro, pero verás, cuando haces pruebas de usabilidad, hay muchos usuarios que no leen lo que pones en la pantalla. Si tu muestras un mensaje de error de cualquier tipo, simplemente no lo leerán. Esto puede ser desconcertante para tí como programador, porque te imaginas a tí mismo como conductor de un diálogo con el usuario. ¡Hey, Usuario! ¡No puedes abrir ese fichero, no soportamos ese formato! Además, la experiencia demuestra que cuantas más palabras pongas en el cuadro de diálogo, menos gente lo leerá.

El hecho de que los usuarios no leen el manual lleva a muchos diseñadores de software a suponer que van a tener que educar a los usuarios describiendo las cosas conforme vayan avanzando. Esto lo ves por todos lados en los programas. Por principio, está bien, pero en la realidad, la aversión de la gente por leer significa que eso casi siempre te meterá en problemas. Los diseñadores expertos de interfaces con el usuario (UI en inglés) intentan literalmente minimizar el número de palabras en los diálogos con el fin de incrementar la probabilidad de que sean leídos.

Cuando trabajé en Juno, la gente de UI entendía este principio e intentaba escribir textos simples, cortos y claros. Tristemente, el CEO (gerente general) de la compañía había estudiado un grado de Lenguaje Inglés en un colegio de la Ivy League; no tenía entrenamiento en diseño de UI o ingeniería de software, pero de seguro pensaba que era un buen editor de prosa. Así que vetaba el estilo que usaban los diseñadores profesionales de UI y le agregaba montones de su propia verborrea. Un diálogo típico de Juno se vé así:

Juno Modem Options English.gif

Traducción: Configure Modem.
Texto: Los módems que Juno encontró en tu computadora se enlistan abajo. Por favor da click en el nombre del módem que desees usar para conectarte a Juno. Si deseas agregar, remover o configurar un módem, da click en el botón 'Administrar Modems'. Si no hay módems en la lista, necesitarás instalar un módem (dando click en el botón 'Administrar módems') o conectándote a Juno a través de la red para que puedas ingresar y/o usar Juno.
Botones: [Administrar módems] [Actualizar lista] [_] Apagar bocina del módem
Botones: [Aceptar] [Cancelar] [Ayuda]

Compara eso con el diálogo equivalente en Windows:

Windows Modem Options English.gif

Traducción: Opciones de teléfono y módem. Pestañas: [Reglas de marcado] [Módems] [Avanzado].
Texto: Están instalados los siguientes módems:
Lista: [Modem] [Conectado a]
Botones: [Agregar] [Quitar] [Propiedades]
Botones: [Aceptar] [Cancelar] [Aplicar] (en gris)

Intuitivamente, podrías suponer que la versión Juno, con 80 palabras de instrucciones, sería "superior" (es decir, más fácil de usar) que la versión Windows, con 5 palabras de instrucciones. En realidad, cuando realizas una prueba de usabilidad en éste tipo de cosa, encontrarás que:

  • Los usuarios avanzados se saltan las instrucciones. Asumen que saben cómo usar las cosas y no tienen tiempo para leer instrucciones complicadas.
  • La mayoría de los usuarios principiantes se saltan las instrucciones. No les gusta leer demasiado y esperan que los valores por defecto serán los apropiados.
  • El resto de los principiantes quienes, ansiosamente, intentan leer las instrucciones (algunos de los cuales sólo las están leyendo porque es una prueba de usabilidad y sienten la obligación) se confunden frecuentemente por el simple número de palabras y conceptos. Así que, aún si tenían la plena confianza de que serían capaces de usar el diálogo cuando apareciera por primera vez, las instrucciones realmente los confundieron aún más.

Ahora bien, Juno obviamente estaba micro-administrado más allá de toda razón. Más en concreto, si eres un graduado en Inglés de la Universidad de Columbia, entonces estás en un nivel totalmente diferente de conocimiento de escritura, de albafetismo, que el Juan promedio, y deberías ser muy cuidadoso acerca del estilo de los diálogos que se ven realmente útiles. Acórtalos, reduce el nivel de sofisticación, simplifícalos, deshazte de frases complicadas entre paréntesis, y prueba su usabilidad. Pero no escribas cosas que se vean como memos de la facultad de Ivy League. Aún el agregar las palabras por favor a un diálogo, lo cual puede parecer útil y cortés, va a retardar a las personas: el montón aumentado de palabrería va a reducir, por un porcentaje significativo, el número de personas que leen el texto.

Otro punto importante es que muchas personas se intimidan con las computadoras. Probablemente ya sabes ésto, ¿Cierto? Pero quizá no te des cuenta de sus implicaciones. Estaba yo viendo a una amiga intentar de salir de Juno. Por alguna razón estaba teniendo un montón de problemas. Noté que cuando intentas salir de Juno, aparece el siguiente diálogo:

BlahBlahBlah English.gif

Traducción: Confirme salida. Gracias por usar Juno. ¿Estás seguro de que deseas salir?
Botones: [Sí] [No]

Ella estaba pulsando No, y luego se sorprendía que no había salido de Juno. El mismo hecho de que Juno estaba cuestionando su acción la hacía suponer inmediatamente que estaba haciendo algo mal. Usualmente, cuando los programas te preguntan que confirmes una orden, es porque estás a punto de hacer algo de lo que podrías arrepentirte. Ella había asumido que si el ordenador estaba cuestionando su juicio, entonces el ordenador debía estar en lo correcto, porque, después de todo, los ordenadores son ordenadores. mientras que ella era simplemente un humano, así que pulsaba No.

¿Es demasiado el pedirle a la gente que lea 11 asquerosas palabras? Bueno, aparentemente sí. En principio, ya que salir de Juno no tiene efectos perjudiciales, Juno debió haber salido sin pedir confirmación, como todo otro programa GUI en existencia. Pero aún si estás convencido de que es crucial que la gente confirme antes de salir, lo puedes hacer en dos palabras en lugar de 11:

Exit Now English.gif

Traducción: Salida. ¿Salir ahora?
Botones: [Sí] [No]

Sin el completamente innecesario "Gracias" y el inspirador de remordimientos "¿Estás seguro?, éste diálogo es mucho menos probable que cause problemas. Los usuarios ciertamente leerán las dos palabras, le dirán "mmm, eh?" al programa, y le darán a la tecla Sí.

Seguro, el diálogo de confirmación de salida de Juno hace tropezar a unos pocos, dirás tú, pero ¿Es eso tan importante? Tarde o temprano todos lograrán salir del programa. Pero aquí yace la diferencia entre un programa que es posible usar contra un programa que es fácil de usar. Aún los usuarios avanzados y experimentados apreciarán las cosas que haces para facilitarles la vida a los usuarios principiantes, inexpertos o distraídos. Las bañeras de los hoteles tienen grandes barras para agarrarse. Están ahí para ayudar a la gente discapacitada, pero todos las usan de todos modos para salir de la bañera. Le hacen la vida más fácil aún para los físicamente aptos.

En el siguiente capítulo, hablaré un poco acerca del ratón. Al igual que los usuarios no desean/no quieren/no pueden leer, algunos no son muy buenos para usar el ratón, así que tienes que tomarlos en cuenta.


<< Capítulo 5: Consistencia y otros duendes

>> Capítulo 7: Diseñar para gente que tiene cosas mejores que hacer con su vida, parte dos

Personal tools