You are on page 1of 5

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 JoeI SpoIskv
TruducIdo por RuúI Herrunz Serruno
z6. q. zooo
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.
z. 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 Lsourios No Leen los Munoules.
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.



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.

EsLé urLIcuIo upurecIó orIgInuImenLe en ¡ngIés con eI nombre User ¡nLerIuce DesIgn Ior
Progrummers CIupLer 6: DesIgnIng Ior PeopIe WIo Huve BeLLer TIIngs To Do WILI TIeIr ¡Ives

¡Eh. no hay nada malo en actuar así. como una distracción que les impedirá tener sus tareas realizadas. y para ellos. y posiblemente no puedan leer con perfecta fluidez el texto. En principio. El manual de QuickBooks asume esto y asume que tendrá que enseñar los principios básicos de contabilidad a los usuarios. Muchas de la personas que usan este programa son los propietarios de pequeños negocios. Esto puede ser muy desconcertante para ti como programador. los usuarios no leen nada. Los usuarios utilizan técnicas just-in-time (justo a tiempo) para la lectura de los manuales en base a sus necesidades de conocimiento. Un buen ejemplo de esto es el inmensamente popular programa de contabilidad para pequeñas empresas de Intuit. Un diálogo típico en Juno es como el siguiente: . 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. el CEO de la compañía había sido decano de Inglés en una universidad de la Liga Ivy. El mismo hecho de que estés leyendo este libro te coloca en el grupo de élite de gente con grandes capacidades literarias. leer el manual será visto como malgastar el tiempo. pero puedes estar seguro de que no lo leerán si no está obligados a hacerlo. simplemente no lo leerán. usuario! ¡No puedes abrir este fichero. pero te garantizo que un porcentaje muy alto de ellos encontraran la lectura como un deber. De hecho. Además. ¡Serán niños! Ellos podrán descifrar el texto si realmente se ven en la necesidad. menos gente se parará a leerlas.no entienden qué se supone que el programa debe hacer. claros y simples. pero seguramente él pensó que era un buen editor de prosa. o como mucho. Esto puede sonar un poco fuerte. la experiencia muestra que cuantas más palabras aparezcan en tus ventanas de diálogo. ya sé que la gente que usa los ordenadores son perfectamente capaces para leer. Por desgracia. 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. El idioma en el que esté escrito el manual puede que no sea su primer idioma. Si. él no tenía ningún conocimiento en diseño de Interfaces de Usuario o en ingeniería del software. que hay unos cuantos usuarios que simplemente no leen las palabras que pones en la pantalla. QuickBooks es sencillo de usar sin necesidad de leer el manual.tratarán de conseguir algo hecho. pero verás. Si abres una ventana de error del tipo que sea. si ya tienes conocimientos de contabilidad. la aversión que tiene la gente a la lectura implica que actuar de este modo siempre te meterá en algún problema. Cuando trabajé en Juno. La única excepción a esta regla que se me ocurre es cuando los usuario no tienen ningún conocimiento del dominio -. pero saben que es mejor aprender a utilizarlo. porque tú te imaginas a ti mismo manteniendo un diálogo con el usuario. no soportamos su formato! De todas formas. Este tipo de comportamiento lo verás por todas partes en distintos programas. Por tanto. QuickBooks. cuando realizas tests de usabilidad. 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. No hay otra forma de hacerlo. la gente de UI comprendía este principio y trató de escribir textos cortos. pero en realidad. vetó el trabajo que habían realizado los diseñadores UI profesionales y añadió una gran cantidad de prosa propia. los cuales simplemente no tienen ni idea de los entresijos de la contabilidad.

No les gusga leer demasiado y esperarán que la opción por defecto sea la correcta. las instrucciones que han leído consiguen confundirlos más aún. con 5 palabras de instrucciones. Juno fue "micro-manejada" (micro-managed) más allá de toda razón. incluso aunque confiasen en que podían usar el diálogo cuando este apareció. Volviendo al punto clave. podría definirse como "superior" (es decir. los cuales intentarán. 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. con 80 palabras de instrucciones.Compáralo con el diálogo equivalente de Windows: Por intuición podrías pensar que la versión de Juno. En realidad. Asumirán que ya saben usarlo y que no tienen tiempo para leer complejas instrucciones. Por tanto. Claramente. y deberías ser tremendamente cuidadoso cuando . el resto de los nuevos usuarios. en serio. si tu eres un decano de Inglés en Columbia. entonces estás en una liga literaria completamente diferente al del Joe medio. cuando haces pruebas de usabilidad encontrarás que • • • los usuarios avanzados obviarán las instrucciones. la mayoría de los nuevos usuarios obviarán las instrucciones. más fácil de usar) que la versión de Windows.

este diálogo parece un poco menos propenso a causar problemas. Normalmente. después de todo. ¿verdad? Pero no te das cuenta de las implicaciones que esto puede tener.. entonces el ordenador debía tener la razón. Probablemente esto ya lo sabes. Pero aquí está la diferencia entre un programa que es posible usar frente a un programa que es fácil de usar. Hacen la vida más fácil incluso para aquellos que físicamente no tienen discapacidades. Pero incluso si estás convencido de que es crucial que la gente confirme salir del programa. va a hacer que la gente lea más despacio. aparentemente si. y haz tests de usabilidad. si salir de Juno no tiene efectos de gran impacto. todo el mundo las usa. Estaba mirando como una amiga intentaba salir de Juno. Los usuarios ciertamente leerán las dos palabras.eliges las palabras para los diálogos que a ti te parecen que pueden ayudar. pero en realidad. hazlos para idiotas. ¿quiero?". Otro punto importante es que mucha gente se intimida por los ordenadores. cuando los programas te solicitan confirmar un comando es porqué estás a punto de realizar una acción que no puede deshacerse. Pero no escribas frases que parezcan tesis de una universidad de la Liga Ivy. Me di cuenta entonces que cuando intentas salir de Juno aparece el siguiente diálogo: Ella estaba pulsando No. olvídate de las cláusulas complicadas entre paréntesis. 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. Ella tenía asumido que si el ordenador cuestionaba su juicio. inteligentes y experimentados apreciarán todo aquello que hagas para facilitar el trabajo para los nuevos usuarios. pensarán "mmmm. y pulsarán el botón "Si". Estas agarraderas permiten a la gente con discapacidad a salir de la bañera. Por alguna extraña razón estaba teniendo problemas. Acórtalos. por tanto. . los ordenador son ordenadores mientras que ella sólo es humana.?". El diálogo de confirmación de salida de Juno puede gustar a unos pocos.. pero ¿acaso es esto tan importante? Todo el mundo finalmente podrá 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. el número de la gente que leerá el texto. Las bañeras de los hoteles tienen grandes agarraderas. simplifícalos. Incluso los usuarios avanzados. Incluso añadir las palabras "por favor" al diálogo. podrás pensar. porque. como cualquier otro programa. ¿Es demasiado pedir a la gente que lea 11 palabras? Bien. los distraídos y los que tienen poca experiencia. en porcentajes que podrás medir fácilmente. Cuanto mayor sea el número de palabras más se reducirá. Lo primero. ella pulsaba "No". Juno debería dejarte salir sin pedir confirmación. lo cual podría parecer que ayuda además de ser cortés.

Joel Spolsky es el fundador de Fog Creek Software. & * " $ ' ( " ' ( . por lo tanto vas a tener que acomodarte a ellos. hablaré un poco acerca del ratón.* #% -. algunos no son muy buenos usando el ratón. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft. una pequeña empresa de software en Nueva York. * * /- . y Juno. Viacom. Exactamente igual que nuestros usuarios no leen/leerán/pueden leer.En el siguiente capítulo. " ## ) * ! " # + ( " " ' $" .