Archivo de Categoría «Arquitectura de Información»

Breve reseña del concepto Experiencia de Usuario

Arquitectura de Información, Diseño de Interacción, Diseño de Interfaces, Experiencia de Usuario, Usabilidad

Comencemos por lo primero: ¿qué es Experiencia de Usuario? Aunque se puede definir desde diferentes perspectivas, podemos decir que se trata de un enfoque en el diseño de productos —en gran medida digitales, aunque no restringido a ellos— que se basa en la investigación de las necesidades y comportamiento de los usuarios para crear productos que, a la vez de ser funcionales, generan satisfacción en sus usuarios.

El concepto de Experiencia de Usuario —o User Experience, en inglés—, es relativamente nuevo. Digo relativamente, porque su uso extendido se observa recién desde los últimos 10 años.

El término, sin embargo, tiene una historia más extensa. Ya a mediados de los ’90 Donald Norman, mencionaba la «Experiencia de Usuario» y la describía como la forma en que

(…) cover some of the critical aspects of human interface research and application.

cubrimos algunas de los aspectos críticos de la investigación y aplicación de la interfaz humana.

What You See, Some of What’s in the Future, And How We Go About Doing It, Don Norman, Jim Miller, Austin Henderson

Esto como parte de los debates de CHI ’95 y en relación a su trabajo en Apple.

Otro hito relevante es la publicación en 2002 de «The elements of user experience» —Los elementos de la experiencia de usuario—, de Jesse James Garrett, que ordena la serie de disciplinas que se relacionan con la experiencia de usuario y lo visualiza en un conocido diagrama (PDF).

elements-of-user-experience

Pero no fue sino en 2005 cuando el concepto de User Experience comienza a tomar vuelo por sí mismo. El contexto era el rebote luego del desastre de las «.com» y la emergencia de la llamada «Web 2.0».

De hecho, en 2005 Garrett acuña el concepto de «Ajax», parte central de la web 2.0 y Adaptive Path —de la que Garrett es co-fundador— organiza la primera UX Week. De ahí en adelante, la UX fue mainstream.

IMG_1312

UX week de 2005, foto © Jared Spool

Quizá la señal más potente de lo que el concepto UX traía a la industria, fue el reconocimiento de la Usability Professionals Association —UPA—, una de las organizaciones profesionales con un perfil más académico, que en 2012, luego de una extensa y compleja discusión extensa, cambia su nombre a User Experience Professionals Association, UXPA.

Esto fue polémico y causó la irritación de las otras asociaciones y disciplinas profesionales, que acusaron a la UXPA de oportunismo, de monopolizar un concepto que incluía también a los profesionales de la Arquitectura de Información o el Diseño de Interacción.

Hubo reacciones indignadas de notables miembros de la comunidad, como Louis Rosenfeld, con su respuesta a la «Carta abierta a la comunidad de Experiencia de Usuario», con que Rich Gunther, Presidente de UPA a la fecha, anunciaba el cambio a UXPA.

Pero el concepto continuó extendiéndose, al punto que hoy es un concepto establecido y parte de la descripción laboral de muchos profesionales y equipos.

Al día de hoy, ya es un nombre establecido, difundido y, hasta cierto punto, comprendido por practicantes y clientes.

La pregunta de rigor es: ¿por qué «User Experience» se impuso por sobre las etiquetas previamente existentes? Creo que son dos las razones principales:

  • La facilidad de comprender un proceso más completo, en el que convergen diferentes disciplinas, con un concepto unificador;
  • Desde una perspectiva comercial, la facilidad de comunicar un concepto claro, con resultados concretos.

Un proceso unificado

Hasta antes de asimilar masivamente el concepto de UX, hablábamos de usabilidad, arquitectura de información, diseño de interacción, diseño de interfaces, diseño visual, etc. Si bien existen diferencias entre las diferentes disciplinas, el tener una visión unificada del resultado, y una cierta visión sobre el proceso, tiene ventajas. Ha contribuido a entender que cada disciplina aporta al resultado, y que el resultado es mucho más que sólo la suma de las disciplinas.

Un término fácil de comunicar

Hasta antes de que se acuñara y se asimilara la UX como concepto, abundaban los nombres para describir procesos y resultados similares. Pero la confusión para los clientes era grande. Y el esfuerzo para intentar explicar lo que proponías a un cliente, era mayor.

De hecho, las etiquetas para las descripciones laborales reflejaban esa confusión: podías ser un Arquitecto de Información, Experto en Usabilidad o Diseñador de Interacciones, pero en la práctica hacías lo mismo, o cosas muy similares. O las hacías todas en diferentes momentos.

En suma, el concepto de Experiencia de Usuario ha venido a resolver un clásico problema de significante y significado, en el que teníamos un contenido —las disciplinas, métodos y procesos—, pero no había un denominador que facilitara su comunicación.

UX ha facilitado eso. Claro, ahora surgen otros problemas, como la de-significación del concepto —ya se quejaba de ello Norman en 2007 en una entrevista con Peter Merholz— o la trivialización de la práctica, pero esas son otras batallas.

Nuevos aires en la web semántica: schema.org

Arquitectura de Información, Web Semántica

El concepto de web semántica no es nada nuevo, de hecho es tan antiguo como la propia web. Ya en las primeras versiones de HTML (1993), se definen elementos semánticos que permiten establecer relaciones entre recursos o documentos, —el elemento link con el atributo rel, por ejemplo—, así como elementos estructurales que permiten definir una jerarquía interna a cada documento HTML —como los títulos h1 a h6.

Todos sabemos lo que ocurrió luego, en los primeros años de la web: la irrupción masiva de Internet con la guerra de los browsers, nos llevó a la pérdida de muchos de los principios semánticos. Pero la idea siempre ha estado presente.

En 2001 Tim Berners-Lee publicó The Semantic Web, planteando la necesidad de otorgarle una estructura semántica al contenido de la web, que facilitara la relación entre el contenido y mejorara el funcionamiento de los buscadores. La visión de una nueva forma de contenido web, que es significativa para los computadores, liberará una revolución de nuevas posibilidades, pero su despliegue ha tardado en producir suficiente tracción.

En el camino surgieron iniciativas como microformatos, que ante la falta de estándares semánticos, buscaban agregar una capa de significado directo en HTML. Aunque tuvo bastante aceptación en ciertos círculos, nunca tuvo un uso predominante.

Pero la necesidad de darle significado al contenido sigue presente. El problema de fondo es el incentivo: ¿Cuál es el beneficio directo de describir semánticamente contenido para quienes producen esa información? ¿Quién será capaz de valorizar el contenido, su significado y sus relaciones? En otras palabras: ¿Cómo gano con esto?

Pues bien, en el momento en que los grandes actores del mudo del web comienzan a valorar el contenido estructurado y descrito semánticamente, el beneficio potencial comienza a hacerse concreto. Me refiero a Google, Microsoft, Yahoo y Yandex, con el proyecto Schema.org.

Schema.org es un esfuerzo conjunto para generar ontologías de diversos espacios de conocimiento —aunque las llaman esquemas o vocabularios—, que permite a los productores o publicadores de contenido describirlo de modo que los buscadores —en primera instancia— puedan identificarlo con precisión. Esto es precisamente a lo que se refería Berners-Lee en su escrito del 2001.

Lo que busca un proyecto como Schema.org es precisamente producir ese beneficio directo: mayor precisión en las búsquedas, es decir, mejor posicionamiento y relevancia. Gana el buscador entregando un mejor servicio, el usuario al obtener mejores resultados y los publicadores de contenido o servicios al ser encontrados con mayor facilidad.

Las ontologías de Schema.org incluyen un conjunto de vocabularios para tipos como Eventos, Organizaciones, Personas, Productos, etc., que pueden ser integrados al HTML de un sitio mediante microformatos, RDFa o JSON. El conjunto de esquemas está en crecimiento y hay colaboración de múltiples participantes, en lo que parece ser un proyecto saludable.

Lo dejo hasta acá por ahora, si aún no lo conocen, den una mirada a Schema.org.

La documentación en el diseño de experiencias de usuario

Arquitectura de Información, Experiencia de Usuario

Hace unos días escribí acerca de los wireframes y la necesidad de reducir la documentación en los proyectos de UX. Y aunque me concentré en hablar de los wireframes, no se trata de condenarlos al olvido ni de negar su utilidad. De lo que se trata es de optimizar los procesos de trabajo y mejorar la comunicación entre equipos.

El problema es el siguiente: los wireframes documentan un sistema interactivo o de información en un momento determinado. E incluso en un estado determinado.

Un momento porque los wireframes son la foto de una etapa en el desarrollo del sistema. Pero sabemos que los sistemas son dinámicos y evolucionan permanentemente. La documentación que los describe, del mismo modo,  debe ser actualizada o queda obsoleta. Esto es un esfuerzo que, con el dinamismo que se requiere cada vez más, se hace difícil.

Además, los wireframes sólo son capaces de representar un estado de una interfaz a la vez. Pero también sabemos que los sitios y aplicaciones tienen muchos estados diferentes.

Así, los wireframes no son capaces de evolucionar junto a los sistemas que documentan, ni son capaces de representar todos sus estados. Por lo mismo, no siempre son efectivos en su resultado —documentar y comunicar un sistema— o eficientes en su ejecución —considerando el tiempo y esfuerzo que requieren.

Otro aspecto del problema, es que en un proyecto interactúan diferentes equipos, con objetivos y necesidades particulares. La comunicación entre ellos y la forma en que ésta se produce, varían según la relación que tengan los equipos y la naturaleza de los proyectos.

¿Cuáles son las alternativas?

Las opciones son varias, pero existen diferentes escenarios:

  • Escenario 1: si un equipo incluye tanto a investigadores, como a diseñadores de experiencia y a desarrolladores —el escenario ideal—, lo mejor es realizar bocetos rápidos, prototipar, evaluar con usuarios y pasar rápido a desarrollar. Y evaluar con usuarios nuevamente.
  • Escenario 2: si los equipos de diseño de experiencia de usuario (UX) y desarrollo son áreas distintas de la organización, se deberá documentar más. El equipo de desarrollo necesita precisiones; el de UX necesita respaldos de lo que ha definido. Aún así, se pueden documentar muchos aspectos en prototipos complementados con flujos de interacción, y sólo cuando sea necesario, wireframes. Pero el propósito será pasar lo más rápidamente posible a desarrollo.
  • Escenario 3: si el equipo de desarrollo y el de UX corresponden a empresas diferentes colaborando en un mismo proyecto, se hará necesaria documentación más detallada. En este caso, los prototipos documentados y los wireframes serán centrales. Deberán sustentar las definiciones de UX cuando el equipo no esté presente. Y tendrán que ser precisos para facilitar el desarrollo.

Por sobre todas estas consideraciones y escenarios, debemos tener presente que el tiempo disponible para los proyectos es reducido y en muchos casos la competencia y la carrera por el time-to-market son críticos. Con lo cual debemos calibrar todos los aspectos para asegurar un diseño de UX y un desarrollo fluido.

Otra forma de reducir tiempos, costos y esfuerzos, es pasar rápidamente desde el prototipado al desarrollo. En lo posible, prototipar en herramientas lo más cercanas al lenguaje final: HTML, CSS, JavaScript en el caso del web. La idea de generar prototipos detallados, con herramientas especializadas (como Axure, InVision, etc.), que luego deberán ser reconstruidos durante el desarrollo, parece superflua en la mayoría de los casos. Gastar recursos en aprender los trucos de las herramientas de prototipado, que luego serán desechados, no parece una forma eficiente de avanzar.

En conclusión, tenemos muchas herramientas de definición y comunicación a nuestra disposición, sólo debemos saber cuándo usarlas para beneficio de cada proyecto.

Wireframes en una época ágil

Arquitectura de Información, General

Hasta hace algún tiempo, defendía la idea de que era imprescindible crear wireframes para todos los proyectos. Hoy creo que la situación ha cambiado considerablemente.

No se trata de un cambio de opinión respecto del valor de la herramienta en sí misma, sino de una realidad diferente, de condiciones distintas en la industria.

Disponer de semanas o incluso meses para elaborar y documentar wireframes es costoso, requiere de dedicación y de tiempos que no siempre están disponibles. Se justifica cuando los equipos que diseñan y definen la arquitectura de información de un producto son distintos. Se debe comunicar de modo claro qué hacer, entregar instrucciones de cómo construir el sitio o aplicación. Esas instrucciones deben ser precisas, no deben dejar dudas. Este escenario es cada vez menos frecuente.

Cuando el equipo que diseña y el que implementa es el mismo, o son equipos que están muy comunicados, el valor de los wireframes se diluye. Adquiere más valor la comunicación directa.

Los wireframes son tanto una herramienta de comunicación de diseño, así como de política interna. Como herramienta de comunicación, son la representación de un momento de un proyecto. Su rol político tiene que ver con la necesidad de respaldar decisiones, de contar con definiciones que servirán de referencia para contratar la implementación o para controlar su desarrollo.

El problema es que un diseño nunca está cerrado. Se marcan hitos, se cierran ciclos, pero los proyectos no se detienen. Y en estos momentos, el tiempo tiene un valor enorme. Un producto puede perder una oportunidad vital por no salir en el momento adecuado.

¿Qué alternativas hay? Si no vamos a elaborar wireframes, es necesario documentar los aspectos centrales de la arquitectura de información o de las interacciones. Las alternativas son varias, por ejemplo, alguna o una combinación de las siguientes:

  • Bocetos de pantalla de baja resolución. Es decir, dibujos en papel sin mucho detalle de las estructuras principales.
  • Prototipos semifuncionales. Simulaciones interactivas que documentan páginas, flujos e interacciones.
  • Flujos de pantallas. Llamados de diversos modos, se trata de diagramas de pantallas dispuestos en un flujo, que funde un diagrama de interacción con wireframes de diferente resolución.

Estas son sólo las alternativas más comunes. El punto más importante, es que siempre será necesario marcar un hito en que las ideas de diseño se comunican y traspasan a un equipo de desarrolladores. Mientras más cercanos —y mayor confianza tengan— ambos equipos, se requerirá de menos detalle en la documentación.

Retiro de Arquitectura de Información: Las Presentaciones

Arquitectura de Información

Para comenzar a cerrar el tema del retiro de arquitectura de información, les cuento que pueden encontrar las presentaciones en formato PDF en el sitio del Centro de Investigación de la Web (la trinchera de Javier Velasco, el organizador del evento):

New horizons for IA: 2006 Information Architecture Retreat, Programa definitivo y presentaciones.

Retiro de Arquitectura de Información: Último Día

Arquitectura de Información

La vuelta a la realidad luego del retiro fue muy agitada y no tuve tiempo de publicar las fotos que me quedaban del último día con las presentaciones finales. La sesión comenzó con Peter Morville y su presentación Emerging Strategies for Information Architecture. Le siguió Felipe Vera con su Modelo de Construcción de Bibliotecas Digitales, y nos enteramos de que esta idea, que viene gestando desde hace ya un tiempo, se convertirá en libro.

Luego presentó el dueño de casa, gestor y organizador del evento, Javier Velasco. Siguiendo, Peter Merholz revisó una presentación preparada para IDEA 2006.

Para finalizar, Ricardo Baeza-Yates, a quien tenía ganas de escuchar desde hace tiempo, realizó un presentación muy interesante sobre el trabajo que realizan con Yahoo! Research.

DSCN3773

Peter Morville inicia su presentación.

DSCN3774

Peter Morville durante la presentación, que fue naturalmente una de las más esperadas.

DSCN3778

Peter finaliza su presentación.

DSCN3780

Felipe Vera comienza la presentación de su modelo de bibliotecas digitales.

DSCN3782

La pirámide de Felipe Vera.

DSCN3786

Javier Velasco inicia su presentación.

DSCN3787

Javier habla sobre el nuevo medio que es internet.

DSCN3792

Peter Merholz presentando. Peter Morville, en primer plano, escucha atento.

DSCN3794

Merholz habla sobre IDA 2006, en primer plano Ilka y Patricia.

DSCN3796

La presentación de Peter Merholz se basó en la necesidad de considerar la arquitectura de información como una disciplina no sólo centrada en el web, sino que debe extenderse a los espacios físicos que afectan a la información y su uso.

DSCN3801

Comienza la presentación de Baeza-Yates.

DSCN3802

Baeza-Yates presenta y los asistentes observan atentos.

DSCN3805

La presentación de Baeza-Yates fue muy ilustrativa sobre la forma en que los datos de las búsquedas se utilizan para mejorar los resultados y refinar el sistema.

DSCN3806

Ricardo muestra un gráfico con los nodos de un análisis de búsqueda.

DSCN3810

Baeza-Yates muestra un modelo para el diseño web.

Retiro de Arquitectura de Información: Más Sorpresas desde Brasil

Arquitectura de Información

Luego de un breve descanso y las fotografías en la plaza de Santa Cruz, continuaron las presentaciones. Era el turno de Ilka Porto y Bruno Pinheiro. Los chicos de Globo mostraron como caso de estudio el proceso de rediseño de la portada de Globo.com. Pudimos ver varias etapas intermedias y comentaron el proceso de evaluación de las alternativas que generaron y las razones de la opción elegida. Tal vez lo más interesante fue haber visto los resultados que el cambio generó en términos de aumento de visitas y clicks en la portada.

Luego, Marcelo Gluz y Patricia Fontes, también de Globo, presentaron algo que capturó la atención de todos: un proyecto en desarrollo para crear comunidades en torno a fotografías, 8p.com.br. Con referentes como Fotolog y Flickr, la diferencia en este espacio es la posibilidad de crear grupos de usuarios y personalización.

DSCN3732

Ilka preparándose para la presentación. Sentados están Jorge Barahona y Juan Carlos Camus.

DSCN3734

Ilka y Javier Velasco.

DSCN3736

Ilka y Bruno junto a Javier, haciendo ajustes técnicos.

DSCN3740

Nadie dijo que iniciar una presentación fuera fácil.

DSCN3745

Finalmente, Ilka puede comenzar a presentar.

DSCN3748

Ilka presenta la portada orginal de Globo.com desde la que se inició el rediseño.

DSCN3749

El menú original en Globo.com estaba desorganizado y contenía muchos vínculos escondidos.

DSCN3752

Ilka y Bruno presentaron las versiones intermedias durante el proceso de rediseño.

DSCN3756

Marcelo y Patricia comienzan la presentación de 8P

DSCN3762

Marcelo presenta los objetivos del proyecto.

DSCN3763

Patricia habla sobre las características principales de 8P.

Retiro de Arquitectura de Información: Un Descanso

Arquitectura de Información

El sábado había sido una jornada interesante pero agotadora en el retiro de arquitectura de información. Antes de continuar era necesario un descanso. Aprovechamos de tomar algunas fotos del grupo completo en la plaza de Santa Cruz, frente al hotel.

DSCN3722

En el pasillo, todos agotados tomamos un break luego de una serie de presentaciones.

DSCN3723

Preparándonos para bajar a tomar las fotos del grupo completo.

DSCN3724

En la plaza de Santa Cruz, frente al hotel, todos se preparan para las fotos.

DSCN3725

Algunos llegan más lento que otros 🙂

DSCN3726

Nos turnamos para aparecer todos en las fotos. Es el momento de Jorge Barahona, Felipe Vera y Javier Velasco para fotografiar al grupo.

DSCN3727

El grupo casi completo del retiro.

DSCN3728

Todos tomando posiciones para las fotos.

DSCN3729

Hey, en esta foto aparezco yo. Normalmente no salgo nunca en las fotos, esto es una novedad. Estoy segundo de derecha a izquierda.

DSCN3731

Ahora con Jorge y Javier (abajo a la derecha).

Retiro de Arquitectura de Información

Arquitectura de Información

Hoy se inicia el retiro de Arquitectura de Información en Chile. Esto promete estar muy entretenido, es poco común que se congregue tanta gente interesante por estos lados del mundo. En un rato más comienzo a preparar el equipaje para partir por el fin de semana. Tengo muchas expectativas por conocer a la gente que viene al evento desde fuera de Chile y por compartir en un contexto más relajado con los que nos vemos frecuentemente.

Creo que no seré el único que estará posteando en directo desde el hotel donde estaremos reunidos, de todos modos trataré de ir informando sobre el desarrollo del evento.

Para los que no irán al retiro, pero están por estos lares, el lunes y martes se realizará el encuentro En busca del cliente perdido, en el que participarán algunos de los invitados al retiro.