Artículo original: The User is Always Right
http://doughennig.blogspot.com/2006/03/user-is-always-right.html
Autor: Doug Hennig
Traducido por: Ana María Bisbé York
A veces, nosotros, los desarrolladores de aplicaciones nos tornamos un tanto arrogantes. Creo que todos diseñamos las aplicaciones para que sea lo más fácil de usar posible; pero no siempre lo logramos. Y cuando los usuarios se meten en problemas por algo que han hecho, nuestra primera reacción es culparles:
- Eso estaba escrito en el archivo de ayuda, ¿No lo ha leído?
- No oprima ese botón a no ser que sepa lo que está haciendo.
- ¿Por qué hizo eso?
Me he encontrado culpable de esto mismo recientemente. En Stonefield Query (http://www.stonefieldquery.com) comienza un proyecto nuevo oprimiendo el botón New Project en la barra de herramientas y seleccionando el directorio donde debe ir el archivo proyecto. Los archivos del proyecto son especificados en un archivo llamado SFQuery.INI, el que es creado después de oprimir el botón OK en el cuadro File. Trabaja genial.
Bueno, casi. Un desarrollador reportó un error en su proceso. El dice que no sólo ha seleccionado la carpeta deseada, también ha cambiado el nombre de un archivo a algo como MyProject.INI. Por supuesto, la aplicación está buscando SFQuery.INI, no lo encuentra, y recibe el mensaje de advertencia. Mi reacción (no ante el desarrollador, no soy tan descortés) fue de pensar ¿Por qué el usuario esperaba que trabajara? Yo no podría cambiar el nombre de una DLL de Microsoft World y luego sorprenderme de que dejara de funcionar.
Sin embargo, agregamos algún texto a nuestro archivo de ayuda documentando que nombre del archivo no podía ser cambiado, porque de lo contrario, nadie podría ejecutarlo. De esta forma llegamos a los Axiomas del desarrollo de aplicaciones de Doug.
Axioma # 1: La gente no lee
Otro desarrollador llegó al mismo problema. ¿Será que eran compañeros de habitación en el instituto? Cuando decimos que esto está documentado, replican que no han leído la documentación. ¿Por qué debía? Cuán complejo es oprimir en el botón New, seleccionar una carpeta y oprimir OK?
Entonces, arreglamos el problema al ignorar que el nombre de archivo entrado por el usuario y utilizando solamente la carpeta al crear SFQuery.INI. Fin del asunto.
Tenemos una llamada de un desarrollador, durante la cual apareció el Axioma # 2 de Doug.
Axioma # 2 La gente no es buena para comunicarse
El dijo que la función New nunca trabajó. Me encanta ese nivel de detalles. Veamos, "no trabaja". ¿Significa que ha recibido un mensaje de error? ¿Tengo que usar el Administrador de tarea de Windows para determinar un lazo interminable? ¿El monitor se hizo pedazos y cayeron pedazos de vidrio en su cara? No, el solamente no creó el proyecto. Cuando le preguntamos un poco más, entonces se dio cuenta de que había escrito un nombre de archivo nuevo (el tristemente famoso MyProject.INI); pero cuando verificó en la carpeta, no existía el archivo, sino otro llamado SFQuery.INI
Entonces se hizo la luz. No era culpa del usuario, era culpa mía. ¿Por qué cuando lo que queremos es que el usuario seleccione una carpeta, mostramos el diálogo Archivo. La razón es que queremos que el usuario vea si el proyecto Stonefield Query ya existe en esa carpeta o no. Si ve el SFQuery.INI en la lista de archivos, no lo podría saber que ya lo había hecho. Esta no es una buena razón, sin embargo, hicimos finalmente lo correcto: cambiamos el diálogo por el de Seleccionar carpeta. Ahora no hay confusión en lo que necesita hacer el usuario.
Un segundo ejemplo: un usuario se quejó de que se le habían perdido unos informes. Luego de un trabajo propio de detectives, se dio cuenta de que los había borrado accidentalmente: el pensó modificar el informe; pero oprimió Eliminar, por error. Pero... ¿cómo pudo haber un accidente? Preguntamos al usuario con la típica pregunta ¿Está seguro?, entonces debe seleccionar "Yes" para confirmar la eliminación. Ah; pero es que habíamos olvidado el Axioma # 1. El problema es que Windows tiene tan acostumbrados a los usuarios ha seleccionar "Yes" sin leer los mensajes cada vez que aparece un diálogo, que ya es una costumbre. Existen varias soluciones para esto:
- Reescribir el texto para que "Yes" signifique no eliminar el archivo. Probablemente no es la mejor elección.
- Brindar una función Deshacer para el usuario pueda recuperar el informe eliminado. Nos gustó esta idea; pero sólo funciona si el usuario se da cuenta inmediatamente de lo que ha hecho. No ayudaría al usuario.
- Complicar la selección de la función Eliminar. Justo ahora, el botón Eliminar está detrás del botón Editar. Haciendo una retrospectiva es evidente que se podía pensar que ocurriría un desastre. Puede ser que no deba estar en la barra de herramienta y solamente en el menú, ya que es muy raro decidir eliminar un informe comparado con la creación o modificación.
Conclusión: Necesito dedicar más tiempo a pensar algunas cosas desde la perspectiva de usuarios inexpertos. Y recordar el Axioma # 3:
Axioma # 3 El usuario siempre tiene la razón
No necesariamente en cómo comunican sus ideas (vea Axioma # 2) pero al menos en su intento.
Para ver más ideas sobre este escrito, vea: http://www.codinghorror.com/blog/archives/000550.html.
