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

jueves 6 de abril de 2006

¿Metodologías a piñon? Mejor no

¿Alguien piensa que en usabilidad y HCI tenemos buenas técnicas y metodologías? Yo no. Honestamente creo que estamos en pañales, por eso me parece extraño que alguna gente se tome las metodologías actuales tan en serio y las aplique tan a piñon.

La observación

Reconoce Donald Norman que ha estado muy equivocado durante muchos años, y que eso de "primero observar y luego diseñar" que ha estado pregonando durante años, no es nada acertado.

Quizás en un mundo ideal sería perfecto, pero en el mundo real una vez el proyecto se ha decidido es demasiado tarde para cambiarlo, así que ya apenas hay nada que observar. Puesto que no suele haber gente de HCI en los puestos directivos de una organización la observación llega siempre demasiado tarde.

Por ejemplo, cuando alguien en las alturas de Telefónica decidió lanzar el proyecto Noxtrum era ya demasiado tarde para ponerse a observar a la gente con lápiz y papel para saber si el proyecto tenía sentido o no. Había que hacerlo y punto.

Por otro lado la otra pega que pone Norman a la observación inicial es que el proyecto debe estar parado y no iniciarse hasta que la observación termine y determine las "necesidades reales" de los usuarios. ¿Es esto realista? ¿Cómo encaja esta parálisis en un proceso iterativo de desarrollo?

Demoledor.

El test de usuarios

Norman en su artículo también aclara un malentendido corriente con los test de usuarios. Comenta el autor de La psicología de los objetos cotidianos que los test de usuarios son como el proceso de debuggeado de un programa, valen para encontrar los bugs, los problemas a resolver, pero no sirven para averiguar lo que el usuario quiere o puede venirle bien que haga la interfaz. Y aquí da en el clavo.

No hay metodologías para generar buenas ideas

Este es un gran problema de las metodologías de usabilidad y HCI actuales, sirven para encontrar los problemas, pero no para encontrar mejores soluciones. No hablo de una solución a un problema detectado (eso suele ser relativamente fácil), sino plantear un concepto nuevo, una interfaz totalmente diferente, una manera totalmente diferente de enfocar la situación globalmente.

Las técnicas de observación y las entrevistas dan información sobre las necesidades y modelos mentales de la gente, pero eso no te dirá como debe ser la mejor interfaz, como tampoco te lo dirá un test de usuario ni una evaluación heurística.

Hay pocas metodologías de HCI que ayuden a la conceptualización y a nuevas maneras de enfocar la interfaz. La mejor de ellas, en mi opinión, es la metodología de personajes y los escenarios, sin embargo el propio inventor, Alan Cooper, reconoce que está aún poco elaborada y que ojalá escriban un libro para documentarla mejor

Algunas conclusiones

Ciertamente la necesidad de popularizar las técnicas de usabilidad quizás ha hecho que se vendan demasiado técnicas y metodologías que luego tienen poca aplicación práctica en casos concretos o que aportan un beneficio muy dudoso respecto a su coste.

Es verdad que algunas de estas técnicas ayudan mucho a convencer de la importancia de la usabilidad inicialmente. Todos los que hemos hecho test conocemos el fenómeno de conversión masiva a la "religión de la usabilidad" tras presenciar un test de usuarios real. Sin embargo una vez que el equipo está ya convencido de la importancia de la usabilidad y no comete errores de usabilidad graves las técnicas tradicionales se quedan un poco cortas, siempre ayudan, pero no hacen maravillas.

No es muy frecuente que tenga un equipo tan bueno y una web tan libre de errores de usabilidad, así que en general por ahora hay mucho jugo que sacar a las metodologías tradicionales de usabilidad. Sin embargo a veces pasa, hay cosas ya suficientemente buenas.

Las filosofías de desarrollo ágil

Es aquí donde el tema se conecta con las filosofías de desarrollo ágil (prefiero no llamarles metodologías, otro día explicaré por qué) donde es habitual y normal el testeo masivo de nuevas ideas que no se sabe si van a funcionar o no.

Si me invento una nueva interfaz o una nueva funcionalidad, hasta no probarla en real con suficiente gente no sabré si funciona. No hablo de saber si tiene errores concretos de usabilidad (algo que puedo detectar con un heurístico o un test de usuarios), si no de saber si el nuevo concepto globalmente funciona mejor o no. La observación o las entrevistas te dirán si más o menos puede encajar con lo que han dicho o con los objetivos de los usuarios o sus modelos mentales, pero poco más, mucho trabajo para poco resultado. Hay mil cosas que podrían encajar o que no.

Las filosofías de desarrollo ágil dan por supuesto que te vas a equivocar hagas lo que hagas, así que renuncian a la investigación previa porque creen que no te va a dar la solución y prefieren directamente probar las cosas.

Norman se confiesa admirador de estas filosofías ágiles de desarrollo. La verdad es que estoy de acuerdo, creo que a día de hoy, cuando puedes utilizarlas, son la mejor solución para llegar a buenas interfaces.

sábado 4 de marzo de 2006

Los grandes rediseños no son recomendables

Es imposible valorar qué es lo que ha funcionado bien o mal cuando se rediseña una web al completo. Cuando todo cambia es imposible aislar variables y decir qué ha causado qué. Todas las mediciones estarán contaminadas, no sabremos si la sección X es más visitada porque en la nueva versión tiene un link con fuente más grande, porque ha cambiado de situación o porque hemos redactado mejor sus contenidos. Si no sabemos qué es lo que ha pasado no podemos aprender nada ni demostrar nada, todo quedará en especulaciones.

Si no podemos demostrar que han sido determinados cambios concretos que nosotros postulñabamos los determinantes para cierta mejora (aumento de tráfico, de ventas, etc.) separándolos del resto de cambios del gran rediseño, será difícil para los responsables del sitio valorar nuestro trabajo en la mejora de la interfaz. ¿Hay más ventas en la nueva web gracias a la frescura de la nueva imagen que conecta con el público? tal y como argumenta el creativo, o ¿por qué el botón "comprar" tiene mayor contraste y ya no es un texto azul oscuro sobre fondo negro? tal y como argumenta el especialista en usabilidad? Evidentemente esto es una broma exagerada para ilustrar una situación en la que cada uno barre para su casa.

Es más adecuado realizar a diario pequeños cambios en elementos concretos, unas palabras en del texto de un link, la posición de un link, un elemento gráfico, etc. Los efectos positivos, negativos o neutros de los pequeños cambios se pueden medir de manera relativamente fácil. Cuando no está claro el porcentaje de clicks en un link concreto porque hay varios links al mismo contenido y no diponemos de herramientas avanzadas de seguimiento de clicks, se puede recurrir a métodos artesanos como incluir una página oculta con redirección durante unos días. Así podremos medir con exactitud el antes y el después del cambio realizado.

Los grandes rediseños que incluyen cambios en la estructura de carpetas y urls del sitio suponen tirar a la basura años de indexación en Google y empezar de 0. Aunque hay métodos para indicar a Google las nuevas urls, no siempre funcionan adecuadamente y se toman su tiempo para volve rankear a los niveles iniciales.

Por otro lado los usuarios se molestan con los cambios bruscos de interfaz, no importa que la web claramente mejore, mucha gente se molestará. Los pequeños cambios por el contrario son percibidos positivamente.

Los grandes rediseños solo son buenos cuando realmente la versión anterior era realmente deficiente a todos los niveles y era necesario hacer tabla rasa. El rediseño total tiene sentido especialmente cuando la arquitectura del sitio antiguo bloqueaba la indexación por Google; malas urls, javascript en enlaces, etc.