Mostrando entradas con la etiqueta usabilidadad. Mostrar todas las entradas
Mostrando entradas con la etiqueta usabilidadad. Mostrar todas las entradas

martes, enero 22, 2008

Los usuarios y la primera impresión

Repasando la pila de cosas pendientes de leer me he encontrado con un inspiradísimo Larry O'Brien en una frase que es solo lateral en su razonamiento de que se nota más a los programadores muy malos que a los muy buenos
Medir la satisfacción [para medir la calidad de un desarrollo] es un indicador insuficiente, porque la satisfacción tiende a ser un delta de la última experiencia, no un valor absoluto.
Y es curiosísimo, porque tengo exactamente esa percepción tanto en un lado como en el otro, de programador y de usuario: no importa lo que ocurra posteriormente a un error fatal del sistema; el sistema llevará para siempre ese estigma. Da igual que se corrigiese para siempre, en la siguiente versión. Para no ser absolutamente pesimistas, a nivel interno ayuda muchísimo que exista (y se use) un sistema de seguimiento de incidencias, que esté documentado cuándo, dónde y cómo se producía el problema y cuándo (desde que versión) y cómo se solucionó. A nivel externo... ya digo, un estigma :/ Aunque una labor continuada de comunicación, que tal mal se les suele dar a los desarrolladores, puede ayudar bastante...

Es también por el miedo a que la primera impresión no sea buena por lo que muchos programadores se resisten al famoso release early, release often. Pero no publicar versiones también es fuente de mala imagen, de eso los desarrolladores deben de ser conscientes... Y es que es difícil conjugar el causar una buena impresión con publicar pronto. Yo tengo en esto una política que no sé si es la más acertada, pero es la mía: minimizar la funcionalidad de la primera iteración, limitarla a lo esencial, que sea mínima pero bien testeada. Por cierto, que Joel no está de acuerdo con esta estrategia desde el punto de vista estratégico/comercial/ISV... Mucho que discutir desde distintas vertientes, incluido el modelo de negocio y de desarrollo de software, claro :)

Por cierto que este mismo tema, desde el punto de vista estrictamente estético, fue tratado por Jeff Atwood con un ejemplo muy desafortunado, comparando Frets on Fire con Guitar Hero. No puedo ser imparcial en este caso porque estoy enganchado al FoF en el que uno se puede creer que toca con el teclado como Stevie Ray Vaughan con su guitarra en Texas Flood. Aquí, al menos para mi, es el sonido y no la imagen lo importante :)

Los usuarios y "la primera impresión" en barrapunto

jueves, noviembre 30, 2006

Programadores e interfaces de usuario

Hay algunos brillantes, pero en general casi todos los programadores que conozco son(mos) muy malos diseñando interfaces de usuario. Esto tiene varios motivos, creo:

  • El programador tiende a ver la funcionalidad, no el uso.

  • El programador no tiene la formación adecuada (ni el interés(?)) acerca de usabilidad ni diseño. Quizás tampoco la formación adecuada en programación de GUI's

  • El programador, casi por definición es vago. Gastará el mínimo tiempo en el diseño del interfaz


También hay algunos aspectos que dificultan que un interfaz sea armonioso y usable: los continuos cambios de especificaciones, la indefinición de funcionalidad y de diseño:
- Eso... uhmmm... déjalo también configurable
- Ya, ¿pero dónde?
- Ya le encontrarás un hueco...
- Con tantas opciones ¿no será un poco difícil de usar?
- ...
De todos modos lo que a mi me parece adecuado es que el programador programe un interfaz de usuario diseñado por un diseñador conjuntamente con el cliente, o al menos validado por éste. Si no hay más remedio que diseñarlo por lo menos intentar no hacer el diálogo. En ese mismo enlace hay consejos sencillos sobre lo que no hay que hacer. El ejemplo del GUI de wget es espeluznante... :)

La misma entrada en BP