Diseo de Interfaz de Usuario para Programadores Captulo 6: Diseando para gente que tiene cosas mejores que hacer

con su vida
Por oel !pols"#

)ncluso sin llevar a cabo el e*perimento! te puedo asegurar con cierta confian(a ue algunos de estos usuario simplemente no llegarn a completar la tarea! o les llevar una cantidad de tiempo e*traordinaria hacerlo. +o uiero decir con esto ue estos usuarios sean estpidos. ,al ve( posean todas las habilidades respecto a usar programas pero estando frente a un programa difcil de usar no estn usando todas las capacidades motoras ni todas las neuronas a su uso. -especto a ue los usuarios no leen los manuales! ellos no tienen el manual. .uede ue no haya un manual. 'i hay uno! el usuario no lo tendr debido a toda una serie de ra(ones l$gicas! estn usando una versi$n de demostraci$n obtenida de tu pgina /eb! estn en casa y el manual est en la oficina0 su departamento de informtica nunca les dio el manual. )ncluso si tienen el manual! francamente! ellos simplemente no van a leerlo a no ser ue esta sea la nica posibilidad. Con muy pocas e*cepciones! los usuarios no tomarn tu manual entre sus bra(os ni lo leern de cabo a rabo antes de empe(ar a usar tu soft/are. "os usuarios generalmente esperan conseguir ya todo hecho y por lo tanto leer el manual ser visto como un desperdicio de tiempo o como distracci$n ue le impide resolver las tareas a reali(ar. )gualmente si estamos leyendo el manual de usuario! 1lvaro -amre( Cerceo 23244536678

Esta ltima lectura habla sobre el diseo de manuales de usuario y de mensajes de error. Cuando diseamos interfaces como programadores debemos tener en cuenta factores como: Que los usuarios nunca tienen el manual a mano y si lo tuvieran jams lo leeran y de hecho los usuarios no leeran nada y si pudieran nunca uerran leerlo! no son hechos pero se debe actuar de forma estricta como si lo fueran por ue con eso se haran los programas de forma ms sencilla y amigable. "a pregunta es significativa #C$mo hacer algo fcil de usar% &n modo para medirlo cuantitativamente es ver el porcentaje de usuarios reales son capaces de completar una tarea en una cantidad de tiempo dada. 'i sientas a un grupo de usuarios medios delante de tu programa y les pides ue completen la tarea! entonces cuanto ms usable sea tu programa! el porcentaje de usuarios ue son capaces de reali(ar una determinada tarea ser mayor.

consider9monos raros ya ue los ue utili(amos una computadora consideran la lectura como un deber. :a ue en ocasiones los manuales no se internacionali(an o sea no vienen escritos en el idioma nativo. 'olo encontrarn respuesta al leer el manual y eso ue lo harn por necesidad! compru9belo y ver ue es cierto! ue es por e*periencia. .or lo tanto esto nos deja en la difcil tarea de disear un soft/are de tal manera ue nuestro error de capa ocho no lea para nada el manual ya ue como se dijo anteriormente es una total p9rdida de tiempo. 'olo hay e*cepciones donde por ejemplo no dominan para nada el programa o sea no saben ue carajos debe hacer por lo tanto se deben dar conocimientos bsicos y generales para ue se cono(ca la funcionalidad. Cuando reali(amos test de usabilidad! los usuarios no leemos ningn mensaje en pantalla. Cuando se abre una ventana de error no lo leern para nada! algo desconcertante para todos como programador! cuanto ms palabras apare(can menos de ue lo vamos a leer. .or lo mismo los programadores han tenido ue reducir palabras en mensajes de error de forma ue sean concisas en lo ue dicen ya ue los usuarios tienen aversi$n a leer y tienden a cometer errores! un ejemplo visto en el te*to es ;uno! donde el dialogo de instalaci$n de <6 palabras de instrucciones lucha contra el de =indo/s haciendo creer ue el de

;uno es ms fcil pero demostrndose con pruebas de usabilidad se encuentra ue los usuarios obvian las instrucciones ya ue creen ue la opci$n ue elijen por defecto sea la correcta. "uego otra blasfemia son los cuadros de te*to ue preguntan si deseas salir de un programa! ponen palabras como si fueran tesis no ueda de otra ue acortarlos! hacerlos para imb9ciles! olvidndose de clausulas metidas entre par9ntesis y por supuesto incluir palabras como por favor ya ue hasta en los programas la cortesa ante todo y por ende la gente se detendr a leer. +o poner palabras de domingo como desea salir>.! gracias por usar>! muchos pensarn si es necesario el cuadro de dilogo ya ue todo mundo saldr del programa pero con esto se tran(a una gran diferencia entre un programa fcil de usar y un programa posible de usar. ,odo tipo de usuarios encontrar y apreciar a uello ue ayude a facilitar su trabajo. ?lgo as como las agarraderas para los discapacitados ue todos las usan. .ara finali(ar! como e*periencia digo ue los mensajes de error deben ser cortos pero ue no sean tediosos adems de ue se debe buscar instruir al usuario de otra manera no convencional! la ctedra de ingeniera de sistemas nos obliga ue aun ue el manual sea corto o en video hacerlo escrito pero vemos ue es totalmente innecesario ya ue es real la situaci$n en la cual con esto 1lvaro -amre( Cerceo 23244536678

en ocasiones se est jugando el 9*ito en implementar el sistema en un lugar @*A .

1lvaro -amre( Cerceo 23244536678