Twitter y la experiencia de usuario
- Tema: Usabilidad, Web World
- » Se lee en 61 segs

Twitter sin duda ha marcado un punto de inflexión en la historia de Internet, según businessinder en Junio de 2009 Twitter recibió 44,5 millones de usuarios únicos y quien sabe cuántos twitts se escribieron ese mes, en total miles de millones, seguro. Si alguien tiene el dato… no dude en pasármelo.
¿Pero cuál es el secreto del éxito de Twitter? Esta pregunta se ha intentado responder desde muchos puntos de vistas, pero me gustaría aportar mi humilde opinión del por qué triunfa desde el punto de vista de la experiencia de usuario a pesar que su interfaz web tiene ciertas oportunidades de mejora en cuanto a usabilidad se refiere.
Aquí el desglose del por qué:
- Simplicidad de concepto, sólo expresate, és simplemente una plataforma… los usuarios son quienes lo complican con la jerga. Eje. Hashtag, retwitt, etc .
- Es muy personal, no te obliga a nada. Como diría Tim Colling en sulibro “The little book of twitter” – En twitter nunca vas a ser mordido por un vampiro o un zombie – parodiando al célebre juego de Factbook (la UX de esta red social será materia de otro post)
- No hay compromiso, no hay temática, sólo hay ideas, sólo hay tips de información
- El usuario se siente cómodo, las reglas de convivencia las fija el usuario
- Es prácticamente accesible desde cualquier dispositivo o aplicación (plugins y mashups para hartarse)
- La utilidad la pones tu y no la aplicación
- En la medida en que más interactúas te vuelves mucho más dependiente, es adictivo por el tipo y flujo de información
- 140 caracteres es lo máximo que llegamos a leer en un vistazo y aún así hay twitts que no leemos completos… pero entendemos perfectamente de qué va todo.
Seguro hay mil razones más pero de momento estas son las que se me antojan más importantes.
¿Igual debí haber escrito este post en 140 caracteres?
Justamente este fin de semana tuvimos una reflexión interesante en twitter sobre este tema… si queréis echadle un vistazo.
Al la twitpotesis conjunta entre @Fgrau y @jorgemarquez
http://twitter.com/#search?q=twitpotesis
Seguimos en twitter!
@jorgemarquez
Comentarios
Septiembre 22, 2009SIMO, allá vamos!
- Tema: Usabilidad
- » Se lee en 1 segs

El próximos jueves 24 de septiembre, os invito a pasaros por el SIMO estaremos allí David Rodríguez y este servido, conversando sobre la experiencia de usuario en dispositivos móviles. La conferencia se titula:
Mobile 2.0: Experiencia de usuario como clave del éxito.
Os invito a daros una vuelta por allí…
Cuándo: jueves, 24 de septiembre, a las 10:00h.
Dónde: en Ifema, dentro de la feria SIMO (planta 1, sala N-110).
Aquí os dejo la invitación si queréis echarle un vistazo.
One more thing! el que venga y me diga que leyó este post, le regalaré un poster sobre móviles…
cualquier duda ya sabéis dónde encontrar me. También estaremos haciendo un lifestreaming desde twitter @jorgemarquez por si acaso
Nos vemos en el SIMO
Tags:UsabilidadComentarios
Septiembre 14, 2009La variable del aprendizaje en la ejecución de test de usuario
- Tema: Usabilidad
- » Se lee en 121 segs

Durante de la realización de un test sometemos al usuario a una serie de tareas relacionadas, por lo general, con una aplicación o dispositivo en concreto. Pongamos el caso concreto de un web site de venta de billetes de avión. Al menos 2 o 3 de las tareas principales del test estarán enfocadas en el proceso de compra, donde el usuario deberá ejecutar para poder recolectar datos concretos sobre ciertas piezas del proceso. También aplica para los casos en que los usuarios deben de transitar por el HomePage más de 2 veces durante las tareas.
En ese tipo de casos, el usuario pasa por un proceso rápido de aprendizaje el cual lo lleva a realizar la tarea en concreto en un lapso de tiempo “menor” siendo esta una situación atípica, puesto que un usuario regular no tiene por tareas “comprar billetes” , cambiar la dirección y arrepentirse en el último momento. Al final son casuísticas probables, que deben ser sujetas a prueba.
Otro ejemplo, en varios de aplicaciones en dispositivos móviles, he podido observar cómo este fenómeno se repite. Claro está que en temas de movilidad, las opciones ejecución de operativas son limitas y el usuario en vistazo muy rápido puede entender lo básico de la aplicación y su navegación.
Sin embargo, este pequeño efecto de aprendizaje por repetición puede llegar a influir en los resultados del test, sobre todo en la variable tiempo. Esa aquí donde surge la pregunta: ¿Cómo mesurar este efecto?
Para ello se me ocurren 3 opciones:
Reordenamiento de tareas para mitigar este efecto, esta sería la solución rápida
Según la progresión del test tomar en cuenta la variable aprendizaje para aplicarla al factor tiempo. La pregunta es ¿Cómo? En un principio se me ocurre que Realizar el cálculo de la curva de aprendizaje y el tiempo resultante tomarlo como tiempo medio de la tarea en cuestión.
Por ejemplo:
Un usuario tarda 162 segundo en realizar el alta en un site (esta sería la tarea) la sub tarea sería en medio del proceso cambia los datos de tarjeta de crédito por defecto por una nueva tarjeta. En esta última el usuario tarda 85 segundos. Pero el proceso lo completa en 142 segundo. En esta caso vemos claramente que en el segundo intento de alta, pese a la tarea extra lo terminó en menos tiempo.
Otro ejemplo sería someter al usuario a X diferentes tareas siempre partiendo de la Home, a la última tarea el usuario ya habrá reconocido todos los accesos a la información perdiendo el valor real del escaneo visual para localizar una opción dentro del site.
Es aquí donde el valor de curva debe tenerse en cuenta sumándolo al total y resaltándolo como un valor diferencial.
Aquí os dejo la fórmula de cálculo para que saquemos conclusiones
Matemáticos! Ayudar con el con cálculo
¿Qué otra solución veis?
Comentarios
Enero 18, 2009Reflexiones sobre Jailbreak vs Default en el iPhone 3G
- Tema: Usabilidad
- » Se lee en 61 segs

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.
Tags:UsabilidadComentarios
Diciembre 9, 2008Mobile web, la tarea pendiente
- Tema: Usabilidad, Web World
- » Se lee en 61 segs
Hace un par de semanas la gente de Yankee Group, presentó el informe de su investigación sobre web móvil titulado “Best of the Mobile Web”, dicho estudio hacía una evaluación de las principales web móviles del mercado norteamericano, enfocados en 3 sectores: Aerolíneas, Banca y Shopping. El objetivo era generar un pequeño ranking de web móviles y dar algunas pinceladas sobre los principales problemas del sector.
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
- Entender de una vez por todas que la experiencia de usuario es MUY diferente del escritorio al móvil
- 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
- 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
Comentarios
Noviembre 27, 2008Los filtering sliders de Facebook
- Tema: Usabilidad
- » Se lee en 1 segs

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:
- 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?
- 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.
Tags:UsabilidadComentarios
Noviembre 10, 2008Gmail: Problema de interacción elimina mi lista de contactos
- Tema: Usabilidad
- » Se lee en 61 segs
Hoy ha caído un mito, hasta hace poco consideraba a Gmail como uno de los logros más interesantes en materia de interacción, hasta que un planteamiento erróneo de interacción en la gestión de contactos hizo que eliminara a unos cuantos de mi lista, con las implicaciones que eso tiene… a parte de perder el correo, pierdo el contacto del Gtalk porque todo está integrado.
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….
Tags:UsabilidadComentarios
Octubre 22, 2008Etiquetar o categorizar, allí la cuestión
- Tema: Usabilidad
- » Se lee en 1 segs

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:UsabilidadComentarios
Octubre 16, 2008Agile User Experience o Experiencia de usuario Ágil
- Tema: Usabilidad
- » Se lee en 241 segs

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

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”
Comentarios
Octubre 9, 2008Leyes y principios: Hick’s Law
- Tema: Usabilidad
- » Se lee en 61 segs

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:
Tags:UsabilidadComentarios
Seguir mirando »- Usándolo.com es el blog personal de Jorge Márquez, dedicado a conversar sobre usabilidad, diseño web y tecnología.
¡ Sindica el contenido de usandolo.com usando RSS !
Temas
Últimamente
- Twitter y la experiencia de usuario
- SIMO, allá vamos!
- La variable del aprendizaje en la ejecución de test de usuario
- Now Open!
- Simplicidad, síntesis, datos y medios de comunicación
- Reflexiones sobre Jailbreak vs Default en el iPhone 3G
- Mobile web, la tarea pendiente
- Los filtering sliders de Facebook
- Gmail: Problema de interacción elimina mi lista de contactos
- Etiquetar o categorizar, allí la cuestión
Archivos
- Septiembre 2009
- Marzo 2009
- Enero 2009
- Diciembre 2008
- Noviembre 2008
- Octubre 2008
- Septiembre 2008
- Agosto 2008
- Julio 2008
- Junio 2008
- Mayo 2008
- Abril 2008
- Marzo 2008
- Febrero 2008
- Enero 2008
- Diciembre 2007
- Noviembre 2007
- Octubre 2007
- Septiembre 2007
- Agosto 2007
- Julio 2007
- Junio 2007
- Mayo 2007
- Abril 2007
- Marzo 2007
- Febrero 2007
- Enero 2007

