Joel on Software

Joel on Software La Opinión de Joel sobre qué es Software

 

Diseño de Interfaz de Usuario para Programadores
Capítulo 1
Capítulo 2
Capítulo 3
Capítulo 4
Capítulo 5
Capítulo 6
Capítulo 7
Capítulo 8
Capítulo 9

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Diseño de Interfaz de Usuario para Programadores
Capítulo 6: Diseñando para gente que tiene cosas mejores que hacer con su vida


Por Joel Spolsky
Traducido por Raúl Herranz Serrano
26. 4. 2000

Cuando diseñas interfaces de usuario, es una buena idea mantener los siguientes dos principios en mente:

  1. Los usuarios no tienen el manual, y si lo tuvieran, no lo leerían.
  2. De hecho, los usuarios no pueden leer nada, y si pudiesen, no querrían leerlo.
Estos no son, hablando de forma estricta, hechos, pero deberías actuar como si lo fueran, porque esto te permitirá hacer tus programas más sencillos y amigables. Diseñas con estas ideas en mente se conoce como respetar al usuario, lo que significa no tener mucho respeto por el usuario. ¿Confundido? Déjame que te explique.
 
¿Qué significa hacer algo fácil de usar? Un modo de medir esto es ver qué porcentaje de usuarios reales son capaces de completar tareas en una cantidad de tiempo dada. Por ejemplo, supón que la finalidad de tu programa es permitir a la gente convertir fotos tomadas con su cámara digital en un álbum de fotos web. Si sientas a un grupo de usuarios medios delante de tu programa y les pides que completen la tarea, entonces cuanto más usable sea tu programa, el porcentaje de usuarios que son capaces de crear el álbum de fotos web será mayor. Para verlo desde un punto de vista científico, imagina 100 usuarios del mundo real. No tienen por qué estar familiarizados con los ordenadores. Estas personas tendrán muy diferentes talentos, pero algunos de ellos no tienen ningún talento en el área del uso de ordenadores. Algunos se distraerán mientras estén usando el programa. El teléfono suena. ¿QUÉ? El niño llora. ¿QUÉ? Y el gato se dedica a saltar por la mesa jugando con el ratón. ¡NO PUEDO OÍRTE!
 
Ahora, incluso sin llevar a cabo el experimento, te puedo asegurar con cierta confianza que algunos de estos usuario simplemente no llegarán a completar la tarea, o les llevará una cantidad de tiempo extraordinaria hacerlo. No quiero decir con esto que estos usuarios sean estúpidos. Más bien lo contrario, seguramente ellos tendrán una inteligencia superior, o quizá sean grandes atletas, pero en un vis-à-vis con tu programa, no están aplicando todas sus capacidades motoras ni todas sus neuronas a su uso. Únicamente estás consiguiendo captar aproximadamente un 30% de su atención, por lo tanto tendrás que conformarte con un usuario que, desde el interior del ordenador, parecerá que no está jugando con el tablero completo.

Los Usuarios No Leen los Manuales.

En primer lugar, ellos no tienen el manual. Puede que no haya un manual. Si hay uno, el usuario no lo tendrá debido a toda una serie de razones lógicas: están en un avión; están usando una versión de demostración obtenida de tu página web; están en casa y el manual está en la oficina; su departamento de informática nunca les dio el manual. Incluso si tienen el manual, francamente, ellos simplemente no van a leerlo a no ser que esta sea la única posibilidad. Con muy pocas excepciones, los usuarios no tomarán tu manual entre sus brazos ni lo leerán de cabo a rabo antes de empezar a usar tu software. En general, tus usuarios tratarán de conseguir algo hecho, y para ellos, leer el manual será visto como malgastar el tiempo, o como mucho, como una distracción que les impedirá tener sus tareas realizadas.

El mismo hecho de que estés leyendo este libro te coloca en el grupo de élite de gente con grandes capacidades literarias. Si, ya sé que la gente que usa los ordenadores son perfectamente capaces para leer, pero te garantizo que un porcentaje muy alto de ellos encontraran la lectura como un deber. El idioma en el que esté escrito el manual puede que no sea su primer idioma, y posiblemente no puedan leer con perfecta fluidez el texto. ¡Serán niños! Ellos podrán descifrar el texto si realmente se ven en la necesidad, pero puedes estar seguro de que no lo leerán si no está obligados a hacerlo. Los usuarios utilizan técnicas just-in-time (justo a tiempo) para la lectura de los manuales en base a sus necesidades de conocimiento.

Lo realmente importante de todo esto es que no tendrás más remedio que diseñar tu software de un modo tal que no sea necesario la lectura del manual de usuario para poder empezar a utilizarlo. La única excepción a esta regla que se me ocurre es cuando los usuario no tienen ningún conocimiento del dominio -- no entienden qué se supone que el programa debe hacer, pero saben que es mejor aprender a utilizarlo. Un buen ejemplo de esto es el inmensamente popular programa de contabilidad para pequeñas empresas de Intuit, QuickBooks. Muchas de la personas que usan este programa son los propietarios de pequeños negocios, los cuales simplemente no tienen ni idea de los entresijos de la contabilidad. El manual de QuickBooks asume esto y asume que tendrá que enseñar los principios básicos de contabilidad a los usuarios. No hay otra forma de hacerlo. Además, si ya tienes conocimientos de contabilidad, QuickBooks es sencillo de usar sin necesidad de leer el manual.

De hecho, los usuarios no leen nada

Esto puede sonar un poco fuerte, pero verás, cuando realizas tests de usabilidad, que hay unos cuantos usuarios que simplemente no leen las palabras que pones en la pantalla. Si abres una ventana de error del tipo que sea, simplemente no lo leerán. Esto puede ser muy desconcertante para ti como programador, porque tú te imaginas a ti mismo manteniendo un diálogo con el usuario. ¡Eh, usuario! ¡No puedes abrir este fichero, no soportamos su formato! De todas formas, la experiencia muestra que cuantas más palabras aparezcan en tus ventanas de diálogo, menos gente se parará a leerlas.

El hecho de que los usuarios no lean los manuales hace que muchos diseñadores de software asuman que van a tener que educar a los usuarios a través de descripciones a lo largo de todo el programa. Este tipo de comportamiento lo verás por todas partes en distintos programas. En principio, no hay nada malo en actuar así, pero en realidad, la aversión que tiene la gente a la lectura implica que actuar de este modo siempre te meterá en algún problema. Los diseñadores UI experimentados tienen a minimizar al máximo el número de palabras en los diálogos para incrementar el número de posibilidades de que sean leídos. Cuando trabajé en Juno, la gente de UI comprendía este principio y trató de escribir textos cortos, claros y simples. Por desgracia, el CEO de la compañía había sido decano de Inglés en una universidad de la Liga Ivy; él no tenía ningún conocimiento en diseño de Interfaces de Usuario o en ingeniería del software, pero seguramente él pensó que era un buen editor de prosa. Por tanto, vetó el trabajo que habían realizado los diseñadores UI profesionales y añadió una gran cantidad de prosa propia. Un diálogo típico en Juno es como el siguiente:

Compáralo con el diálogo equivalente de Windows:

Por intuición podrías pensar que la versión de Juno, con 80 palabras de instrucciones, podría definirse como "superior" (es decir, más fácil de usar) que la versión de Windows, con 5 palabras de instrucciones. En realidad, cuando haces pruebas de usabilidad encontrarás que

  • los usuarios avanzados obviarán las instrucciones. Asumirán que ya saben usarlo y que no tienen tiempo para leer complejas instrucciones.
  • la mayoría de los nuevos usuarios obviarán las instrucciones. No les gusga leer demasiado y esperarán que la opción por defecto sea la correcta.
  • el resto de los nuevos usuarios, los cuales intentarán, en serio, leer las instrucciones (algunos de ellos sólo lo harán porque están en un test de usabilidad y se sentirán obligados) normalmente se sentirán confundidos por la gran cantidad de palabras y conceptos. Por tanto, incluso aunque confiasen en que podían usar el diálogo cuando este apareció, las instrucciones que han leído consiguen confundirlos más aún.
Claramente, Juno fue "micro-manejada" (micro-managed) más allá de toda razón. Volviendo al punto clave, si tu eres un decano de Inglés en Columbia, entonces estás en una liga literaria completamente diferente al del Joe medio, y deberías ser tremendamente cuidadoso cuando eliges las palabras para los diálogos que a ti te parecen que pueden ayudar. Acórtalos, hazlos para idiotas, simplifícalos, olvídate de las cláusulas complicadas entre paréntesis, y haz tests de usabilidad. Pero no escribas frases que parezcan tesis de una universidad de la Liga Ivy. Incluso añadir las palabras "por favor" al diálogo, lo cual podría parecer que ayuda además de ser cortés, va a hacer que la gente lea más despacio. Cuanto mayor sea el número de palabras más se reducirá, en porcentajes que podrás medir fácilmente, el número de la gente que leerá el texto.
 
Otro punto importante es que mucha gente se intimida por los ordenadores. Probablemente esto ya lo sabes, ¿verdad? Pero no te das cuenta de las implicaciones que esto puede tener. Estaba mirando como una amiga intentaba salir de Juno. Por alguna extraña razón estaba teniendo problemas. Me di cuenta entonces que cuando intentas salir de Juno aparece el siguiente diálogo:
 

Ella estaba pulsando No, y luego se quedaba sorprendida cuando Juno no se cerraba. El hecho de que Juno le estuviese realizando una pregunta le hacía asumir de forma automática que estaba haciendo algo mal. Normalmente, cuando los programas te solicitan confirmar un comando es porqué estás a punto de realizar una acción que no puede deshacerse. Ella tenía asumido que si el ordenador cuestionaba su juicio, entonces el ordenador debía tener la razón, porque, después de todo, los ordenador son ordenadores mientras que ella sólo es humana, por tanto, ella pulsaba "No".

¿Es demasiado pedir a la gente que lea 11 palabras? Bien, aparentemente si. Lo primero, si salir de Juno no tiene efectos de gran impacto, Juno debería dejarte salir sin pedir confirmación, como cualquier otro programa. Pero incluso si estás convencido de que es crucial que la gente confirme salir del programa, podrías haber usado estas dos palabras en vez de las anteriores 11:

Sin el completamente innecesario agradecimiento ni la pregunta "¿estás seguro de que...?", este diálogo parece un poco menos propenso a causar problemas. Los usuarios ciertamente leerán las dos palabras, pensarán "mmmm, ¿quiero?", y pulsarán el botón "Si".

El diálogo de confirmación de salida de Juno puede gustar a unos pocos, podrás pensar, pero ¿acaso es esto tan importante? Todo el mundo finalmente podrá salir del programa. Pero aquí está la diferencia entre un programa que es posible usar frente a un programa que es fácil de usar. Incluso los usuarios avanzados, inteligentes y experimentados apreciarán todo aquello que hagas para facilitar el trabajo para los nuevos usuarios, los distraídos y los que tienen poca experiencia. Las bañeras de los hoteles tienen grandes agarraderas. Estas agarraderas permiten a la gente con discapacidad a salir de la bañera, pero en realidad, todo el mundo las usa. Hacen la vida más fácil incluso para aquellos que físicamente no tienen discapacidades.

En el siguiente capítulo, hablaré un poco acerca del ratón. Exactamente igual que nuestros usuarios no leen/leerán/pueden leer, algunos no son muy buenos usando el ratón, por lo tanto vas a tener que acomodarte a ellos.



> Capítulo 7

Esté articulo apareció originalmente en Inglés con el nombre User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky