En la vorágine mediática en la que TODA fuente de información está disponible, rescatamos un viejo axioma de la comunicación el cual podemos sintetizar así:

La comunicación de una idea es un conjunto de datos los cuales, bajo un tratamiento estructurado, se convierten en información que acciona el estimulo que produce la comunicación

En internet se busca la simplicidad, permitir a un usuario que realice una tarea con éxito y satisfacción y sobre todo que regrese. Para ello sintetizamos los datos de tal manera que la interpretación sea evidente para que el usuario inicie el proceso de comunicación (Emisor-canal-receptor-feedback)

Sin embargo la simplicidad debe estar enfocada desde el punto de vista del aprendizaje, este proceso requiere el desarrollo de hábitos que no son otros que los estándares y los patrones de navegación. Hasta ahora todo los conceptos presentados están más interiorizados, pero he aquí un riesgo en la medida en que existe abuso de síntesis y simplicidad los canales en vez de convertirse en plataformas de comunicación serán repositorio de datos, anulando el valor de la interpretación, cosa que ha permitido la subsistencia de los medios de comunicación “Leo x diario por su línea, forma o fondo”.

La capacidad de interpretar datos en tanto a forma y fondo es lo que diferenciado a los medios online de los medios sociales, pero esa línea se ha perdido, la interpretación del blogger es tan válida para el usuario como la interpretación de un Doctor en periodismo y jefe de prensa de algún diario.

Hemos estado viviendo la era de la síntesis y la interpretación por parte de los medios, hoy que los medios son todo aquel que sea capaz de interpretar datos es cuando llega la hora de marcar diferencias. El punto de inflexión clásico siempre ha sido la inmediatez -Twitter es más rápido que el País- pero qué hay de la veracidad de la noticia. Los usuario hemos llegado a un grado de refinamiento mediático el cual nos ha permitido diferencia un “fake” de un prototipo real.

Por lo tanto, y haciendo uso y abuso de Mcluhan, intuimos que ahora el medio es el hombre, el usuario es el centro de atracción receptor y emisor, el paradigma del feedback, el motor de internet. El hombre que a través de la tecnología ha evolucionado en su instinto de veracidad, su capacidad de síntesis y su preferencia por la simplicidad. Queda mucha reflexión por hacer entorno a esta cuestión, pero quizá esta reflexión sea colectiva, una wiki-reflexión.

Compártelo

Después de unas largas vacaciones blogueras, regresamos para seguir comentando y analizando los aspectos clave de la experiencia de usuario desde varios enfoques.
Luego de algunas reflexiones decidí hacer el famoso Jailbreak iPhone y debo confesar que es una de las experiencias de usuario más frustrante que he experimentado, exagero un poco, pero no se aleja de la realidad.

Ahora un par de preguntas, ¿Qué nos motiva a realizar un Jailbreak? la respuesta es muy clara y evidente: Tener disponible todo lo que Apple no ha puesto en marcha… Sacarle el máximo provecho al gadget más revolucionario del siglo XXI. Sin embargo, no todo es tan maravilloso y os explico por qué:

• No es un método infalible, ejecutar la famosa Piña (QuickPwn) no es un método infalible. Si falla, debes de hacer un hardreset y puede tardar
• Una vez superado el jailbreak, en pantalla solo ves dos iconos nuevos y la pregunta es inminente ¿Y ahora qué hago?
• Comienzas a navegar por el entramado del Cyndia y el Installer, en buscando respuestas a cómo hago para grabar vídeos, cómo cambio el tema, qué instalo… etc… lo pero: Aquí no está esas respuesta
• Finalmente pides ayuda, consigues un listado de aplicaciones para comenzar a ponteciar el dispositivo, instalas pero no ves nada tangible, no hay feedback… las aplicaciones provenientes de vías no oficiales tiene una interacción desastrosa y nada es claro ni intuitivo
• Y lo que considero peor el la percepción que tienes de haber perdido el control del dispositivo y que lo que has hecho no proporciona ningún beneficio claro. Aunque no sea cierto, pero la primera impresión es lo que cuenta
• Por otro lado, la complejidad de los procesos para ejecutar algo necesitas de 2 o 3 paquetes. Añadir una nueva funcionalidad requiere de más de 10 pasos en algunos casos. La AppStore son sólo 3 “click”
• Otro punto en contra es la frustración que produce cuando una aplicación no funciona y no sabes por qué, esto es muy frecuente. En la appstore el grado de frustración es mínimo
• Por último, un iPhone con jailbreak me hace pensar mientras que por defecto todo fluye intuitivamente. No tengo tiempo ni ganas de indagar en 1000 blogs a ver cómo se hacen las cosas. Lo necesito todo fácil y rápido, los usuarios se frustran muy fácilmente

En esta oportunidad me tengo que posicionar del lado de la marca, me gusta lo que me da Apple por defecto, quiero más pero con la misma calidad de Apple y por ello estoy dispuesto a pagar.

Compártelo

Aquí algunos apuntes, “comentados”, de lo que más me llamó la atención del informe:

Existen 2 grandes retos 3 enormes retos en cuanto a diseño web móvil

1. Entender de una vez por todas que la experiencia de usuario es MUY diferente del escritorio al móvil
2. No hay estándares en cuanto las URL, grave problema de findability aquí. Existen más de 10 formas de URL para móviles y muy pocos websites son capaces de discriminar el dispositivo y mostrar de manera transparente la web móvil desde el .com
3. Usabilidad, sobre todo usabilidad. Con la llegada del iPhone esto ha cambiado un poco pero no mucho. Aún se siguen patrones que no ayudan al usuario, aún se ven procesos que no se simplifican, que se muestran igual que en web pero con otra presentación.

Resultados destacados del ranking

• la web del Bank of America y Edmunds las mejores según el ranking, aunque con Edmunds no estoy muy de acuerdo
• American Airlines, la mejor de su categoría
• El premio a la peor se lo lleva Wachovia, esperemos que ahora que pertenece a Wells Fargo cobre un poco más de aliento

En conclusión…

Queda mucho trabajo por hacer, urge ir a la web móvil y más aún con el boom de movilidad que hay en el entorno gracias a la llegada de la “movida touch”, debemos encontrar buenos modelos de negocio, aquí la cultura del banner no funciona, debemos refinar las formas tanto de mantener el negocio móvil online como de brinda una experiencia de usuario plena. Este es el reto para lo próximos años.

No nos dejemos deslumbrar por la belleza de la web 2.0, hay mucho de 2.0 en la web móvil y debemos explotarlo, debemos explotar nuevos mercado como África, aquí hay más móviles conectados que ordenadores. No es fácil, pero tampoco lo es la web 2.0, que aún estamos descubriendo.

Aquí os dejo la presentación de la gente de Yankee Group

Compártelo

Hoy gracias al post de Mashable, 5 things Facebook need to improve right now, descrubrí una función muy interesante en facebook, es todo un unniverso por descubrir. Es una serie de sliders para ajustar la cantidad de “historias” que deseas que se muestren en tu página de inicio. Es decir, tienes la posibilidad de decidir si quieres ver más actulizaciones de fotos, de estatus, de post en wall, etc…
La verdad es que esta forma de visualización me parece muy correcta, te da la oportunidad de poder personalizar con bastante precisión, demasiada quizá.

El problema

Dos en realidad:

1. Muy simple, genera demasiadas dudas, GUI intuitiva pero acción resultante confusa. Por ejemplo: ¿Qué implica mostrar más o menos? ¿Si subo el “volúmen” de los eventos qué implica? Evidentemente veré más eventos, pero cuántos ¿Se mostrarán primero? ¿Qué quiere decir la frecuencia en que recibiré más o menos noticias? ¿Qué no son en tiempo real?
2. El enlace a esta personalización está “escondido” al final de todo el listado de updates y además no se figura en el apartado Configuración del menú recursivo (el de arriba a la derecha)

Eso si, es un ejmeplo muy interesante del uso de sliders en UI.

Compártelo

Explico cómo pasó desde el punto de vista de usuario.

La Tarea
La tarea era muy sencilla, consistía en dar de baja a un contacto en un grupo y añadir uno nuevo

Resultados
El usuario eliminó todos los contactos de la lista, perdiendo los respectivos correos asociado.

Problema detectado
El literal de la acción “Delete Contact” en el contexto de la acción era confuso.
El equipo de Gmail plantea que para eliminar un contacto de un grupo el usuario debe hace click en el botón “Groups” y seleccionar Remove from… “Nombre del grupo”

Solución
Una posible solución sería sustituir el botón “Delete Contact” en el contexto de acciones de grupo y sustituirlo por “Remove from this group” dejando la opción de borrado para el contexto de edición del Contacto. Puesto, que es poco probable que un usuario desee eliminar completamente un contacto en un contexto de edición de Grupos.

Ahora bien, veamos gráficamente lo que hemos estado comentando.

El contexto del usuario

Las opciones de la tarea dentro del contexto. Si quiero eliminar haré click en Delete, no?

La propuesta de interacción del equipo de Gmail, la acción que quiero ejecutar en escondida

La guinda del paste: El dialog box de confirmación

Here’s my two cents…

• Analiza siempre el contexto de las acciones
• Diseña pensado en escenarios y en tareas concretas
• No obligues al usuario a leer nada, ayúdalo a interpretar. Guíalo
• En formato web, dile NO a las ventanas de diálogo o dialog box. Los usuarios las odian, esta ventanas hacen todo menos dialogar
• No tengas miedo en ser explícito a la hora de etiquetar acciones
• Como siempre, simplicidad y sentido común. Pero ante todo, simplicidad

¿Os ha pasado esto alguna vez? Posiblemente si hacemos un test de usuario esto saldría en rojo….

Compártelo

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:

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

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

Compártelo

Ú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:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. 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.

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”

Compártelo

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

1. 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.
2. Innova, cambia paradigmas! utiliza principios como page paradigme o la búsqueda fasetada, crea nuevos conceptos.
3. Haz pruebas con usuarios, ellos son más sabios que tú, siempre
4. Piensa en pequeño para poder hacer algo grande
5. Respeta las leyes o al menos tenlas en cuenta

Más información:

Hick’s Law wikipedia

Compártelo

Veamos un par de ejemplos.

Este fue sacado de la web de la sexta, donde podemos observar que la principal “gracia” que es el volúmen de los textos se pierde, creando confusión. El usuario intentará hacer lectura continua de las palabras que no presenten tamaños diferentes creando fases incoherentes.

Otro ejemplo:

Ahora miremos el caso de Flickr, aunque no es perfecta, se acerca un poco más a las 4 reglas de diseño de tragclouds.

Recomendación: Respetar el principio del componente:

• Palabras o frases con buena separación entre si
• Diferencia de tamaños marcada
• Funciona bien si hay volúmen o un control manual de los tamaños
• Formato de los enlaces, recordar: todo enlace al menos debe invitar a hacer click y no puede confurdirse con un elemento más del diseño
• Clara diferenciación con el resto de elementos de texto en la página
• Que añada valor al usurio, un tagcloud gratuito sin sentido orientado a la folksonomía, no aporta

Compártelo

Últimamente me he topado con está pequeña disyuntiva semántica o que es lo mismo una confusión de términos. Resulta que me invitan a una presentación de servicios titulada “Redes Sociales: marketing 2.0″ Ilusionado de oír nuevas tendencias sobre como introducir tu marca en Facebook, MySpace, etc… y sorpresa, me sueltan un rollo bestial sobre algoritmos de análisis para telecoms que rastrean y encuentran nodos y patrones entre usuarios que se interconectan entre si… vaya chasco, no? Al final interesante, pero no es lo que esperaba. Hace un par de días se repite la misma historia. Y surgen las dudas ¿Qué pasa que no entiende los conceptos?

Por eso quiero hacer una distinción clara y marcada entre todos estos concepto.

Cuando nos referimos a Redes Sociales hablamos sobre el concepto de estructura social donde los individuos se relacionan entre si creando nodos. Sin embargo, hoy en día, cuando se menciona este término lo extrapolamos a Internet automáticamente. Puesto que el renacimiento de este término es reciente y viene acompañado con el cambio de paradigma que ha sufrido Internet, es decir la Web 2.0. En nuestro modelo mental, cuando mencionamos Redes Sociales nos saltan a la cabeza las marca de los servicios Top of Mind como Facebook, Flickr, etc…

Por lo tanto, entendemos que el concepto de Red Social lo asociamos perfectamente con las Redes Sociales en Internet. Por otro lado, la otra acepción del concepto en tanto que válida crea confusión.

Hagamos las distinciones: Si hablamos de Redes Sociales estamos hablando de redes sociales en internet, cuando hablamos de las “otras redes sociales” hablamos del análisis de estructuras sociales, hablamos de sofware y algoritmos de análisis de nodos y patrones a partir de datos de CRM, Listados de llamadas, movimientos bancarios, etc… y en definitiva estamos hablando de un servicio que es el análisis, para su posterior uso como datos para definir estrategias de marketing. Cuando hablamos de marketing en redes sociales, hablamos de SMM (Social media marketing) o de SMO (Social media Optimization).

Como reflexión final creo que es importante hacer diferenciación entre los métodos, las estrategias y los conceptos. El marketing 2.0 es mucho más que redes social, de hecho aún se está inventando. el SMM es una estrategia dentro del plan de marketing y el análisis de datos es una fase del proceso de marketing.

Espero que cuando me vuelvan a invitar a una presentación sobre Redes Sociales: Marketing 2.0 sea sobre Redes Sociales y Marketing 2.0.

Os ha pasado lo mismo?

Compártelo