Interfaces plegables

Cada dia nos sorprenden mas y mas con lo delgado que puede ser una pantalla de computadora o de television. Le tecnologia avanza y he aqui una de las ideas que hoy surgen y que el dia de mañana formaran parte del dia a dia.

La fábula del diseñador centrado en el usuario

David Travis escribió una fábula sobre el diseñador centrado en el usuario. Es una historia fácil de leer, entretenida y muy instructiva. Sin llegar a ser un “saber hacer” te da al menos una nocion del “que hacer” en lo referente al diseño de software centrado en el usuario, algo de lo que siempre hablamos en este blog como método a seguir para el desarrollo de interfaces.
A groso modo y sin intención de transcribir el libro los puntos más destacados del desarrollo centrado en el usuario según David Travis son.
“El diseño visual (organización de los componentes visuales para evitar obstrucciones que impidan acceder a las opciones importantes) es solo una parte de la experiencia del usuario con la tecnología“.
“La tecnología es solo una parte de la solución no lo es todo“.
“Hay que centrarse siempre en las personas que van a usar nuestros productos no en el diseño visual o el uso de lo último en tecnología“.
Para ello hay que basar todo desarrollo en tres pilares:
1.- Temprano y continua comprensión de los usuarios y las tareas que realizan. Para ellos muchas herramientas existen pero el autor centra su solución al uso de Personas nosotros en UsiXML usamos un modelo del usuario. Sin importar como se modela el usuario la fuente de información que crea estos usuarios es de vital importancia y esta puede ser a través de:
* investigación de campo con los reales usuarios del sistema para ver lo que hacen y determinar sus características.
* Visitas regulares al cliente para determinar: motivaciones y perfiles de usuario, ambiente de trabajo y rutas prioritarias (tareas criticas que un usuario tiene que hacer lo más pronto y fácil como sea posible, ojo ). A esto yo agregaría, tecnología o modelo de dispositivos con los que se cuenta. Todo esto sigue en línea con lo que se hace en UsiXML.
* Es imposible hacer que todo sea fácil y de simple acceso, hay que dar prioridades a las cosas y es ahí donde la noción de rutas criticas ayuda a encontrar el balance necesario. En el modelo de workflow nosotros introducimos un concepto similar llamado cuellos de botella que permite identificar las etapas donde se requiere mayor atención debido a la falta de usuarios a realizar la tarea que podría estar relacionada con la complejidad de la tarea o la necesidad de más personal.
* Las visitas a los clientes ayudan a determinar las rutas criticas en función de las metas que buscan sus usuarios.
* Modelar los procesos y las tareas es primordial y para ello nada mejor que el modelado de workflow.
2.- Medición empírica del comportamiento del usuario. Hay que estar seguros de que el diseño funciona como la gente lo espera. Considerar la primera impresión de tus usuarios, sus pensamientos, sus quejas, para ello:
* Test de usabilidad. Considerando las ventajas y desventajas que se puede uno topar. La gente no siempre va a querer transmitir lo que esperan ya que ignoran cuales podrían ser los alcances del sistema.
* Pon a pruebas las rutas criticas de tu sistema.
* Que los usuarios mientras trabajan hablen en voz alta para identificar que aspectos de la interfaz son confusos.
* Medir la usabilidad: cuantos usuarios logran completar la tarea con éxito, eficiencia en lograr la tarea normalmente medida en tiempo, satisfacción con el usuario.
3.- Diseño iterativo. Porqué es necesario hacer prueba y error constantes y por ello no podemos estar codificando el sistema real constantemente es que se requiere de basar las iteraciones en prototipos. Diseños que pueden ser mejorados usando software como el que provee UsiXML para hacer prototipos de interfaces.
* Las iteraciones harán que las mejores cosas de los prototipos sean seleccionados como elementos del sistema.
Muchas empresas tienden a decir que la captura y análisis de requerimientos es centrada en el usuario pero no siguen ninguno de los principios del diseño centrado en el usuario. Esto es básicamente por que creen que ellos entienden lo que necesita el cliente. La investigación sobre las necesidades del usuario no es constante ni comienza al principio del proyecto. La investigación de campo se focaliza en lo que la gente piensa y no en lo que hace. Las decisiones sobre qué hacer con un sistema siempre se basan en decisiones del personaje más importante del grupo de desarrollo y no con los usuarios finales.
Vale la pene leer la historia hay mucho que aprender.