Octubre 22, 2008

Etiquetar o categorizar, allí la cuestión

Tema: Usabilidad
» Se lee en 1 segs

Tag

Inspirado en la disertación propuesta Dmitry en Usabiliy post, empecé a hacer una pequeña reflexión sobre cuándo se debe construir un arquitectura de la información basada en etiquetas (tags) o en categorizar.

Sobre todo porque últimamente me he topado con varias personas que al ver mucho contenido salta directamente a decir “Vamos a etiquetar y hacemos un tagcloud” y me gustaría puntualizar:

Tener un website robusto no significa que el mejor método sea el etiquetado

Existen varios factores que se deben valorar a la hora de apostar por una AI basada en etiquetas. Antes de decidir debemos preguntarnos o considerar varias aspectos, here my two cents:

Tener muchas categorías no implica necesariamente un etiquetado
Valora la eficiencia del sistema de búsqueda
Evalúa y segmenta tu target, suena básico pero no quiere decir que todos lo hagan
Los generadores de contenidos son clave a la hora de decidir. ¿Controlas el contenido o son los usuarios quienes lo generan?
Valora los sistemas híbridos
Rompamos un mito: un tagcloud o una AI basada en etiqueta nos hace tu web 2.0, necesitas un poco más
Pregúntate ¿En realidad necesito tal cantidad de contenidos, puedo simplificar?
Etiquetar en aplicaciones corporativas es una opción a tomar en cuenta, no la descartemos
Si manejas contenido multimedia, pondera altamente el etiquetado
Como siempre, simplicidad y sentido común. Pero ante todo, simplicidad

si me dejo algo, no dudéis en completarlo.

Tags:Usabilidad

Compártelo

4 Comentarios

Octubre 16, 2008

Agile User Experience o Experiencia de usuario Ágil

Tema: Usabilidad
» Se lee en 241 segs

Agile User Experience like speed racer team

Últimamente ha vuelto a la vida el término “Ágil o Agile (áyail en spanglish)” y he sido partícipe de varias interesantes discusiones sobre el desarrollo ágil (Agile development ) y el papel de la usabilidad en desarrollos basados en esta filosofía. Así que vamos a hacer el ejercicio de repasar qué es esto del Agile User Experince o Agile Usability Engineering o como queráis llamarla… en esta oportunidad me centraré en Agile User Experince, porque la experiencia de usuario implica muchas más metodologías que son claves en el proceso de desarrollo de cualquier aplicación y además porque soy de la “escuela de Morvile“, otro día explicaremos esto de la escuela Morvile.

Desde el el principio: ¿Qué es Agile Development? y ¿Cuándo la utilizo?

Por allá en el 2002 Scott Ambler desde los cuarteles de IBM, se le ocurrió que debía desarrollar un “algo” para hacer de los proyectos de desarrollo menos costosos en tiempo — quebradero de cabeza de todos y razón clásica de exclusión de metodologías UCD en desarrollos (Vieja escuela) — En fin, Ambler comenzó a investigar y se topó con los resultados de Kent Beck (Project Leader para Chrysler) quien desarrollo Extreme Programming (XP o dearrollo extremo) que consistía en algo así como pica código a lo bestia con la mayor simplicidad posible y corregir sobre la marcha, es un poco más complejo que eso pero para otro día esto del XP.

Ambler, le llamó la atención este método y decidió crear lo que sería más adelante el Manifiesto sobre el Desarollo Ágil (Agile Manifesto) que no era otra cosa que una filosofía rompedora de paradigmas, una filosofía que se basaría en eliminar de la metodología de desarrollo todo el tiempo invertido en planificar a la perfección y dar más peso esfuerzo a crear con sentido común y con objetivos claros.

Esto hace que los períodos de entrega se hagan mucho más cortos y dinámicos, en si esta filosofía se basa en 4 valores esenciales:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Pues, bajo estos principios se fundamenta el desarrollo ágil, es decir dejemos de planificar hasta el último detalle la perfección no éxiste, para qué perder tanto tiempo en planificación si al finar tenemos que cambiar porque nos hemos dejado cosas en el camino, al final nos gastaremos grandes cantidades de dinero en gestión y mediación con públicos internos y nos olvidamos que hacemos algo para un “Usuario” que es el que nos pagará o recompensará el servicio que le ofrecemos.

Para los gestores de la vieja escuela el planteamiento les debe sonar a “vamos a hacer una aplicación a lo artesanal, a piñón” pues resulta que no es así…. Con un desarrollo ágil nuestro enfoque es darle el acento a los usuario y al proceso de interacción en vez de pensar si monto un Sharepoint o te pongo 2 vignette con Oracle entrepirse, es darle la vuelta a la tortilla, es desarrollar en vez de invertir 4 semanas en un funcional de 260 páginas, que al final el único que se lo lee entero es el que lo escribe y se lo lee entero sólo para corregirlo (3 horas más).

En conclusión esto del Agile es: vamos a simplificar, simplifiquemos todo lo que podamos, corrijamos a medida que lo hacemos. Me gusta mucho una frase que escribió Eduardo Manchón sobre desarrollo ágil hace un par de años:

Cuanto más rápidamente ejecutes, antes descubrirás qué es bueno, qué es malo, qué es suficientemente bueno y podrás hacer mejoras. Rectificar no es fácil, conlleva ser humilde y modesto.

El mensaje es claro, ¡aterricemos! Pero seamos consientes que esta filosofía no es una ley ni un principio y que no se puede aplicar a todos nuestros proyecto, no podemos montar una terminal financiera de esta manera el riesgo es muy alto. Pero si que podemos aplicarla para proyecto menor envergadura. Para ilustrar con mayor claridad esta cuestión me salta a la memoria una frase de Peter Drucker:

Plans are only good intentions unless they immediately degenerate into hard work.

¿Cómo encaja la Experiencia de Usuario en todo este asunto del ágil?

Simple.
Recordemos el primer principio del manifisto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Para satisface al usuario desde el desarrollo sólo puedo hacer una cosa, aplicar UCD (Diseño Centrado en el Usuario o User Centered Design) y es justamente en este punto donde hago un llamado a la Experiencia de usuario, no nos podemos quedar cortos ya que lo hacemos rápido hagámonos bien, pensemos en experiencias y no en la técnica. A veces creo que cuando hablamos de UCD no abarcamos lo suficiente ya os adelantaba que era de la escuela Morvile.

Por lo tanto, y vuelvo a pregunta, ¿Cómo lo hago? para responder Thomas Memmel, de la Universidad de Konstanz en Alemania, recopiló unas tablas comparativas entre metodologías de UCD utilizadas en modelos clásicos y con filosofía Ágil. También, como buen investigador nos introduce un nuevo término Usage Centered Design (Diseño centrado en el uso) con lo cual muestra un enfoque diferente.

Agile UCD

En resume:

Creemos un grupo de trabajo de pocas personas
Reduzcamos los procesos de validación, dejemos esta responsabilidad al usuario final si no loe gusta te lo dirá pero como te lo ha dicho antes puede que no haya problemas
Diseños aplicaciones simples, el usuario te lo agradecerá (1 o 2 funcionalidades a la vez, principio de Pareto total)
Utilicemos prototipado rápido “Paper prototipe”, aunque la mayoría de los clientes no lo ven claro si no está pintado… pero como hemos dicho, esto es para el usuario no para el directivo
Conceptualicemos conjuntamente con el usuario, diseño participativo como método de toma de requerimiento. Pero con usuarios reales
Reflexión y corrección, “Errare humanum est“, no tengamos miedo
Simplicidad, ante todo simplicidad. Ya le he dicho antes pero vale la pena repetirlo
Has pruebas, como siempre
Crea pensado en componentes y modelos, ensambla y prueba. Luego corrige
Aplícalo con conciencia, no pretendas programar una central de trafico aéreo con este modelo. Mide el riesgo y el impacto
Esta filosofía es compatible con el mundo 2.0 en el que vivimos
Innova, reinvéntante, siempre!

Finalmente, considero que hay mucha discusión y polémica en cuanto a estos modelos, pero no hay mejor fórmula para disipar dudas que probarlo.

Por estas razones, la imagen ilustrativa del Speed Racer (AKA Meteoro o Mach GoGoGo) quien con un equipo de 3 personas lograba conquistar el corazón de sus fans (los usuarios) porque la final Speed Racer entendió que su objetivo era ganar carreras rápidamente sin mucho desarrollo y poco a poco ir creando nuevas funcionalidades para su magnífico coche, en los primieros capítulos el coche no daba esos saltos con sólo presionar el botón C. Con la ayuda de Chim-Chim, Sparky y su padre hacían el equipo perfecto… seguro que viajaban sin “funcionales de 500 páginas bajo el brazo”

Tags:agile development, agile user experince, Diseño Web, experiencia de usuario ágil, Usabilidad, user experience, UX, wireframing

Compártelo

¿Quieres Comentarlo?

Octubre 9, 2008

Leyes y principios: Hick’s Law

Tema: Usabilidad
» Se lee en 61 segs

The craoglist y la ley de hick

Retomando un poco los basamentos teóricos que sustentan la argumentación en nuestra profesión, recordemos la Ley de Hick y para qué nos puede llegar a servir si lo sabemos.

Esta ley es muy sencilla de recordar y dice:

El tiempo que una persona se tarda para tomar una decisión es proporcional a la “entropía de decisión” es decir, cantidad y complejidad de alternativas que existen

En pocas palabras podemos medir el tiempo que tarda una persona en acceder a una opción a partir de la cantidad de opciones que se muestra. Este principio no sólo aplica para el menú de navegación sino también a la navegación, incluyendo enlaces, menú, breadcrumb, etc… En sí, cualquier mecanismo que motive el movimiento por un site.

Un ejemplo interesante en el cual se pone en práctica la ley de Hick, lo podremos encontrar en thecraiglist.com, recordemos este site de clasificados donde en la Home obserbamos más de 100 enlaces muy similares unos de otros. Pues aquí, el tiempo aumentará considerablemente, siempre y cuando el objetivo de navegación no esté regido por una necesidad. Este último factor, no se contempla en la fórmula pero juega un papel importante.

Tener en cuenta la ley de Hick no implica crear una gran cantidad de submenús para reducir las opciones y menú largo puede ser más efectivo, puesto que tiempo de subnavegación también cuenta a la hora de la toma de decisión.

Esta ley también afecta a los famosos tag cloud, en la medida que el tag cloud sea más robusto aumentará el tiempo de decisión, es por ello la importancia de destacar considerablemente las opciones que ofrecemos. No olvidemos la ley de Fitts, que aquí juega un papel relevante.

Conclusión

Simplificar! simplificar todo lo que se pueda, no digas cosas que en realidad no quieres decir, para qué tener una sección o una categoría que sabes que está condenada a muerte.
Innova, cambia paradigmas! utiliza principios como page paradigme o la búsqueda fasetada, crea nuevos conceptos.
Haz pruebas con usuarios, ellos son más sabios que tú, siempre
Piensa en pequeño para poder hacer algo grande
Respeta las leyes o al menos tenlas en cuenta

Más información:

Hick’s Law wikipedia

Tags:Usabilidad

Compártelo

1 Comentario