Ser y Tiempo

Quisiera hablar del diseño para la experiencia¹ en general, desde la pregunta qué es aquello que debemos que diseñar para cuidar la experiencia dentro de un sistema o servicio.

Ante cualquier proyecto, sabemos que debemos diseñar la forma, tanto estructural como visual y sabemos que debemos diseñar su tiempo, tanto la información como comportamiento; esto, para todo sistema o servicio. Es decir, debemos diseñar su ser y su tiempo, si me permiten esas dos categorías fundamentales que tomo prestadas de Heidegger. Creo que es buena esa división porque definitivamente no dejamos nada afuera y nos permite entender el proceso de diseño desde esta dualidad.

En general, y no sé por qué motivo, en casi todas las instancias de un proyecto, las herramientas y los lenguajes que tenemos a disposición dentro del proceso se centran en definir el ser y muy pocas herramientas y lenguajes nos ayudan a definir el tiempo. Me explico: hacemos diagramas de afinidad² para generar los mapas de navegación, establecemos jerarquías y estructuras, hacemos esquemas y configuraciones de pantalla, etc. pero muy pocas veces nos centramos en los comportamientos y flujos individuales. Este punto es crítico ya que, si nos centramos en la experiencia como fin, es fundamental tener un lenguaje que nos permita diseñar la cadencia de los elementos para la construcción de su demora. No tenemos cabeza de partitura o de flujo; tenemos cabeza de grafos, de nodos y conectivas, cajas y flechas; que sólo nos permiten comprender el tiempo como momentos discretos.

Los Grafos

Pareciera que la metáfora visual de los grafos se ha instalado como una suerte de meme imperialista que sirve para explicar todo; relaciones entre entidades reales o abstractas, mapas conceptuales, esquemas semánticos, sociogramas, gestión de recursos y/o proyectos, redes neuronales, computacionales, hipertextos, etc. Cualquier objeto puede tratarse como nodo y cualquier relación como vínculo. No deja de ser sospechosa una metáfora visual que pueda representar tantas cosas, pero sin duda la simpleza de su gramática es la que le da su fuerza. En resumen, creo que vivimos en el tiempo de las redes y, por lo tanto, pensamos con grafos.

Por ejemplo, el grafo de la figura podría representar la estructura de un hipertexto cualquiera, con nodos y vínculos. Una vez trabajaba en un grafo similar y lo vio un amigo, algo mayor, y me preguntó por qué estaba yo diseñando una bicicleta. Él vió en el grafo una bicileta. Lo que yo llamaba nodos, él llamaba vínculos y vice-versa. Era el choque de dos visiones culturales distintas: para él la sustancia son los fierros y las uniones son las soldaduras; yo, por mi parte, con mi cabeza de hipertexto veía la sustancia en los nodos y las líneas como saltos inmateriales. Si uno mira el marco de bicicleta es porque entiende que los protagonistas son los tubos y las uniones son la forma de construir una estructura ad-hoc.

Para avanzar en una cabeza centrada en la experiencia que cuida la forma en que las personas que usan, activan, recorren nuestros servicios y sistemas, debemos comenzar por mirar la bicicleta, entender los tipos de tubos, sus largos, sus materiales, etc.

Hoy en día esta realidad es cada vez más concreta, ya que los modelos tradicionales basados en “la filosofía nodo” no sirven para proyectos complejos de alta interacción. Es decir, los mapas de navegación son una guía preliminar, pero que no sirve para comenzar a documentar y planear el diseño de experiencia: no hay espacio para “los tubos”, que son demasiados.

A cada n cantidad de nodos, los máximos vínculos posibles serán (n * (n-1))/2, que corresponde a la tercera fila del triángulo de Pascal.  Ésto si los consideramos sólo como conexiones reversibles, pero ocurre en realidad que son el doble: n * (n-1) ya que ir y venir no da lo mismo si seguimos pensando en diseñar experiencias. Éso es comenzar a mirar la bicicleta.

¿Y el Tiempo?

La bicicleta no resuelve el problema fundamental del tiempo, es sólo el primer paso para entender el material con el que está hecha la experiencia en un sistema. Así como las conversaciones, las experiencias tienen un comienzo, un desarrollo y un final. Esta obviedad debe cumplirse y diseñarse pero suele ser pasada por alto la mayoría de las veces. Por eso diseñamos las partituras de interacción: para poder formalizar el modo del diálogo entre la persona y el sistema. Este lenguaje es heredado del llamado service blueprinting que permite dibujar el recorrido de una persona a través de un sistema.

Paritura realizada por Dámaris Sepúlveda para el diseño del servicio de atención primaria de Quilpué. http://blogs.ead.pucv.cl/servicios/

Nótese que esta mirada permite literalmente curvar el sistema en torno de la experiencia del usuario. Acá no importa la complejidad completa del hospital, sino que solamente ilustramos el recorrido de la persona a través de él. Ló único del “sistema” son las capas que nos permiten distinguir qué clases de procesos están involucrados. En el caso de las las partituras de interacción esta situación está simplificada para poder construir un lenguaje más elemental que permita comunicarse tanto al cliente como a los desarrolladores: se trata de un lenguaje que intenta ser transversal a todo el proceso ya que la experiencia, en su sutil delicadeza, es lo más frájil del diseño y lo primero que suele sucumbir al proceso mismo. Este tema da para mucho más porque estamos recién partiendo seriamente con esto.

1. Quiero evitar la polémica del concepto Diseño de Experiencia por tratarse, en términos estrictos, de un error: es imposible, si no pretencioso, diseñar una experiencia para alguien. Lo que hacemos es diseñador las formas y comportamientos de aquellos elementos que indirectamente condicionarán la experiencia del lector o usuario. En inglés también existe esta polémica, pero se ha nombrado Design for Experience o simplemente UX.
2. o Card Sorting

En esta cuarta versión del seminario de Arquitectura de la Información, nuestro amigo Juan Carlos Camus ha sugerido darle el nombre de “viviendo la experiencia del usuario” para generar la discusión en torno a este concepto.

En Chile, el concepto de Arquitectura de la Información nos ha servido como referencia y pretexto para juntarnos y construir una comunidad de interés, ha sido el catalizador de la discusión en torno al diseño de plataformas y servicios web, nos ha servido para elevar el nivel de la discusión y para evangelizar y educar —en lo posible— a las empresas de la necesidad de tomar con seriedad el tema.

Es cierto que la AI y la Experiencia del Usuario son temas distintos¹. En realidad son 2 aproximaciones metodológicas para acceder al mismo problema:

1. Si hablamos de AI, hablamos del “arte y la ciencia de organizar la información para que sea encontrable, administrable y útil²”;  es decir, se refiere a una aproximación fenomenológica que se ocupa del ordenamiento de la materia (en este caso, información; de ahí su parentesco con la Arquitectura).
2. Si habalmos de la experiencia del usuario, nos enfocamos en la destinación del producto, en el “para qué”. Esta es una aproximación existencialista que busca definir las directrices teóricas y prácticas para la construcción de la experiencia. Lo cierto es que no se puede diseñar una experiencia. Lo que sí se puede es disponer las condiciones para que ocurra un “flujo de uso” coreografiado, construído. Esto se logra con el “buen orden” de los elementos que constituyen la experiencia del usuario³.

Es por eso que AI y Diseño de Experiencia son disciplinas hermanas que se ocupan de distintas fases del mismo problema.

Espero que estos temas y discusiones nos acompañen en el seminario, la idea es formalizar lo que realizamos en Chile para fortalecer nuestra discusión y alimentar nuestro espíritu crítico. Debemos dejarnos de ser meros consumidores para darnos cuenta de nuestra verdadera capacidad de reinventar el mundo.

IV Seminario sobre Arquitectura de la
ayúdanos a difundir el seminario

1. Hago esta aclaración a propósito del poco afortunado comentario hecho en relación al nombre y sentido del sentido del seminario, ver post original.
2. prueba buscando en Google: “define: Information Architecture“. Te darás cuenta que es bastante estándar y consistente la definición a lo largo de todas las fuentes.
3. John Dewey escribió en 1934 “Art as Experience”, texto pragmático altamente influyente en esta corriente de pensamiento. Absolutamente necesario para comprender el sentido filosófico del diseño centrado en la experiencia