Diseñar para la Experiencia es más que Usabilidad o Arquitectura de la Información

Sé el primero en comentar | Escrito por Jorge el 22 de Noviembre de 2008

A continuación, la traducción del artículo publicado en “FEED: The Razorfish Consumer Experience Report / 2008”

Con la traducción y publicación de éste artículo queremos también sentar precedente en lo que sentimos, debiera ser la discusión en torno al Diseño para los medios digitales en Chile y América Latina.

El mercado está dando señales interesantes de cómo siente deben ser las acciones de las grandes marcas en los medios digitales y sin duda nuestra industria y en especial las compañías que vendemos éstos servicios carecemos de una sana de auto-crítica donde muchos se han enquistado en las trincheras de los conceptos de Usabilidad y Arquitectura de la Información sin comprender cuál es el lugar que le corresponden a esas disciplinas que abrazamos el siglo pasado.

Sabes bien que estamos en reinvención constante porque entendemos que ésta es una industria que requiere de proveedores que muten e innoven constantemente.

El desafío del Diseño para los medios digitales es el mismo que han vivido, en su momento otras industrias como la periodística o automotriz; el Diseño debe construir comunicación efectiva y emocional. Los valores de la Usabilidad, la Arquitectura de la Información o la Accesibilidad son, en palabras de Morville “invisibles” y no pueden seguir siendo factor ni argumento de venta o convencimiento a supuestos ignorantes digitales que al escucharnos hablar se alejan cada vez más dejándolos a la merced del Flash indiscriminado y de aquellos que buscan que la web sea la repetición mediática de la TV.

Creemos firmemente que debemos ir en búsqueda de la construcción de una Experiencia de Usuario que está al servicio de la construcción de marcas y generando comunicación. Las disciplinas que nos han ayudado hacer servicios más empáticos con los usuarios no garantizan el invento de puentes de comunicación entre los servicios digitales y sus audiencias. Es el Diseño de las Interfaces e Interacción las que coronan esa búsqueda para construir un diálogo fluido y que conecta emocionalmente al usuario con los sistemas digitales.

Vamos con la traducción del artículo de Razorfish.

Diseñando respuestas y Exploración:
Las nuevas estructuras de construcción

El estilo de vida de un famoso crítico de usabilidad dicta mucho de ser el de una estrella de Rock. Aunque, no hay duda que el Sr. Nielsen se ha impuesto de mala gana en los pedidos de Amazon de cada “Tecnoratus” en el mundo. Todos hemos escuchado acerca de sus principios de orientación en el área de la usabilidad. Sinceramente, ha sido una gran fuente de conocimiento para aquellos que buscaban re-diseñar u optimizar sus sitios webs en la década pasada. La verdad es, sin embargo, que incluso la elaboración de estudios de eye-tracking, mapas de calor y muchas sesiones de diseño interminables basadas en un sitio web actual no proporcionan las respuestas para diseñar una futura experiencia de usuario.

Todos saben que, aquel viejo y cascarrabias experto en usabilidad apreciado por todos posee toda la evidencia que hay disponible -sin embargo- prefiere decirnos cómo configurar estructuras estándares de construcción de páginas en un página web estándar en vez de entregarnos las herramientas para diseñar experiencias de usuarios. Entonces, dejemos a un lado las enseñanzas de Jakob junto al otro material de consulta con el cual contamos y diseñemos basándonos en las necesidades de nuestros clientes - creando una gran experiencia.

Según Jakob: Las personas no se detienen a leer los sitios web; Según esta observación se deber utilizar un estilo editorial diferente y de esta forma convertir la página en una página “escaneable”.

Según nuestra opinión: Hay que dejar a un lado el concepto de diseñar fundamentalmente “páginas” como estructuras de construcción y comenzar a diseñar experiencias.

 

Ni el más novedoso estilo editorial usado y disponible en la Web ayudará a una experiencia diseñada en forma deficiente. Las personas no leen las páginas webs; la mayoría de lo que hay escrito acerca de la Web 2.0 yace inactivo, acumulando polvo digital tal como un enorme e incomodo libro en una lengua que ya nadie habla. La respuesta a esto no está en adoptar un nuevo estilo editorial para la página; sino en dejar de iniciar completamente la actividad de diseño en base a las páginas como el medio para hacerlo.

Proporcionemos información más específica y que persiga un objetivo claro-poniendo a disposición de los clientes respuestas a lo que están buscando. Necesitamos construir esquemas que permitan desarrollar tanto “Storytelling” (narración) como la búsqueda de respuesta. La información que se proporciona -el contenido que busca informar y aquel que se desarrolla en pro de satisfacer una necesidad son, en efecto, el sistema que provees. El sistema debería conducir al usuario a lo largo de la historia y entregar respuestas bajo el contexto de una experiencia de usuario más amplia.

Qué es lo Nuevo?

• Antes de comenzar a diseñar, se debe dejar de utilizar el mapa del sitio y la lista de pantallas; estos artefactos son evidencias de la vieja experiencia. En su lugar, se debe crear una nueva experiencia, la correcta.
• Diseñar la nueva experiencia de usuario como un mapa de interacción. La nueva experiencia debería ser una conversación; una serie de decisiones tomadas por el usuario; una sesión de información narrada interactiva. Comprender que es lo que el cliente necesita y solo diseñar basados en eso.

¿”Qué sucede con el contenido que actualmente se tiene”? Primero, se debe diseñar el contenido que se desea compartir y por otra parte aquel que busca responder a una necesidad en el contexto de la nueva experiencia. Posteriormente, decidir qué contenido existente se puede utilizar según la nueva experiencia.

Lo orgánico puede ser bueno
Experiencias especiales que persigan un objetivo que se ajuste a la innovación constante

Según Jakob: Los sitios web deben enfocarse en la simplicidad- es normal que lo usuarios no se fijen mucho en los detalles.

Según nuestra opinión: Se debe diseñar detalles y servicios simples y elegantes para los clientes, los cuales demuestren una diferencia con respecto a las experiencias digitales de usuarios que ya existen.

Impedir que los usuarios se muevan por todo el sitio web cada vez que necesiten utilizar calculadoras, consultar las preguntas frecuentes, hacer uso de los trip planners o las guías del comprador: estas aplicaciones buscan responder a una necesidad. La experiencia web, la cual se ha desarrollado con un propósito especial perderá mucho de su simple elegancia si se trata de diseñar todo basándote en todo lo demás. Sin duda alguna, el concepto para la nueva experiencia de usuario tendrá nuevos requerimientos de tecnología e interfaz- se debe diseña esta experiencia y construirla dejando a un lado el satisfacer una necesidad inmediata de forma apresurada, y en caso de que las herramientas especiales funcione, entonces, trabajar en incorporarlas dentro de esta nueva experiencia de usuario.

Qué es lo Nuevo?

• Aumentar poco a poco las experiencias digitales del usuario y construirlas de manera que entreguen a los clientes exactamente (y solo) lo que ellos necesitan, no importando las otras experiencias web existentes.
• Cuando sea posible, incluir temas comunes de interacción y navegación a lo largo de las experiencias digitales, cuando sea posible. Hazlo ahora, o cuando tomes la decisión de integrarte, tú decides cuándo.
• No limites la visión de la nueva aplicación adaptándola a tu realidad cuando es tan solo una idea.

Diseñar desde adentro hacia afuera:
Estructuras Semánticas

Según Jakob: Los usuarios son cómodos. No esperes que interactúen para dar sentido a las experiencias de usuarios que pretendes entregar.

Nosotros decimos: Concordamos. el usuario es cómodo. Pero esa no es razón para detenerse. Esta es la razón por la cual se debe diseña un sistema desde adentro hacia afuera: Definir la taxonomía, describer la naturaleza de los objetos del contenido y sus comportamientos.

Diseñar las relaciones entre las varias partes de lo que será finalmente un sistema. No solo confiar en la forma de catalogar del usuario o en algoritmos de búsqueda para proyectar la real importancia de la experiencia.

Utilice un esquema conceptual para cada experiencia. Tenga en cuenta las necesidades del cliente, ya que son descritas por ellos mismos, y proporcionan una guía para orientarse hacia lo más importante en la experiencia. Maneje un lenguaje claro acerca de cómo se describirán los objetos y construya esquemas que ilustren las relaciones entre las partes móviles de la experiencia.

Esto parece ser un ejercicio muy técnico -sin embargo, es correcto definir el contenido, o los datos, así como también las relaciones de una forma muy estructurada.

Utilice estas relaciones para diseñar interfaces que hagan sentir que estos objetos son indispensables. Permita que estas estructuras significativas den como resultado respuestas. No implemente “Tags” que solo produzcan un resultado de búsqueda de “páginas” que se produce al mencionar una palabra/etiqueta específica; utilice las relaciones del contenido para generar interactividad significativa.

Un sistema estructurado de metadatos conecta contenido y aplicaciones de forma que permite a las páginas se “auto-ensamblen”, basándose en la segmentación del usuario, estado del proceso o preferencia, envolviendo el contenido pertinente alrededor del contexto predominante de la experiencia.

Por ejemplo, permitir que el contenido le cuente una historia al usuario acerca de un paquete de vacaciones -y le exponga cosas tales como precios o configuraciones como objetos de contenidos, los cuales puedan ser usados por ellos cuando sean buenos y estén preparados- según el contexto.

Qué es lo Nuevo?

• Construir un lenguaje para el sistema y un modelo relacional para los objetos del contenido usados en una experiencia.
• Relacionar el contenido vía sistemas de metadatos que sean flexibles y fáciles de desarrollar.
• Este muy atento con dar a conocer objetos importantes que entreguen respuestas a los usuarios - no oculte o replique esta información a través de las páginas y espere que ellos sean expuestos de una forma muy clara. El contexto mostrará el sentido al usuario.
• Utilice el sistema de experiencia de auto-ensamblaje para potenciar los usos significativos de la segmentación y personalización.

Adiós por el momento, Jakob.

Primero, estamos ocupados diseñando experiencias.

No cabe duda. Jakob Nielsen ha alcanzado el estatus de Tron gracias a lo que ha hecho a favor del usuario. Dicho lo anterior, se recomienda hacer uso de todo su conocimiento con prudencia. Por lo tanto, no limitemos nuestra visión a efectivos estilos editoriales webs, al uso de botones ordenados correctamente como los de Cancelar y Guardar, y a colocar listas alineadas a la izquierda de los enlace en color azul con distintos tamaños de letras.

Diseñemos experiencias enfocadas en el cliente que comiencen y terminen, bueno, en las necesidades y objetivos de los clientes y, comencemos desde cero, utilizando información e interactivos esquemas de construcción, no estructuras de autoedición.

Descarga el documento original en inglés. (PDF, 2,4 Mb.)

Archivado en: Ayerviernes, Usabilidad, Traducciones

Keep it simple, Stupid

1 Comentario | Escrito por Jorge el 3 de Junio de 2008

La siguiente es la traducción del artículo aparecido en Wired “The brash boys al 37 Signals will tell you: Keep it simple, stupid” sobre el trabajo de David Heinemeier Hansson (DHH) y Jason Fried de la casa de software y diseño de Chicago, 37 Signals.

Basecamp, aplicación 2.0 para la administración de proyectos es la herramienta que usamos en AyerViernes hace mucho. Sabemos y gozamos a diario de la facilidad, claridad y capacidad de crecer con nosotros que ha tenido la herramienta (ya estamos con la cuenta Best Plan) y compartimos la visión de 37 Signals para las aplicaciones de facilidad y simplicidad de las soluciones web-based cuya característica básica es hacer una sola cosa pero hacerla muy bien.

“Lo pequeño es hermoso”, sentencia que debemos al filósofo Ernst Friedrich “Fritz” Schumacher es la base de la visión de DHH como llaman los fieles seguidores del mítico líder de 37 Signals y que compartimos abiertamente en el sentido del tamaño de una compañía como AyerViernes, su localización (en Viña del Mar, no en Santiago) la locura de sus miembros, la visión sobre los nuevos modelos de negocios en los medios digitales, nuestra idea sobre cuántos debemos ser (paramos en 16) y sobre todo la porfiada manía de poner todo en duda, incluso nuestra Metodología.

Nos interesó traducirlo por la discusión que se abrió con Donald Norman sobre cómo diseñar para web, qué hacer para apuntar soluciones web-based que ayuden a los usuarios y sobre todo por la idea de pequeña empresa (son 10) que ayuda a cambiar el mundo digital como modelo estratégico de negocios digitales y que se acerca al planteamiento de la economía de la Larga Cola o Long Tail.

Acá va (si deseas descargarlo, haz click acá).

“Para los 300 desarrolladores de software que repletaban aquella sala de conferencias de Vancouver, David Heinemeier Hansson era más que un programador. El era un visionario, el creador de Ruby on Rails, una plantilla de software que potenciaba un número cada vez mayor de recientes aplicaciones de Internet. Él era una clase de Filósofo-Rey, cuya ética minimalista propuso una nueva forma de pensar acerca de los negocios y el software.

Y él, era una celebridad, con esa apariencia juvenil, una precoz confianza en sí mismo, y fanáticos que invocan su nombre con tanta frecuencia que utilizan sus iniciales como abreviatura: DHH. Cuando Hansson se presentó en el Instituto británico de Columbia para ello, su primera conferencia acerca de Ruby on Rails, la sala se llenó de una clase de emoción envolvente como la que se siente en la apertura de los conciertos de Hannah Montana.

El programa tipificó el discurso de Hansson como una colección de “expresiones efusivas” y “cuentos favoritos provenientes de la tierra de justa indignación”, y él no defraudó. Comenzó felicitando a la naciente comunidad de Ruby on Rails (y, por extensión, a sí mismo), citando una letanía de logros impresionantes: 500.000 descargas de código, 16 libros de cómo hacer, mencionados en Wired y otras publicaciones, y varios premios de la industria - incluyendo, para Hansson, ser nominado como Hacker del Año, otorgado por Google y O’Reilly Media.

Pero no todo el mundo estaba convencido de potencial revolucionario de Rails. Los críticos habían estado diciendo que Rails no era lo suficientemente versátil, que no podía manejar grandes cantidades de tráfico, y que Hansson mismo era arrogante. “Arrogante es generalmente algo que usted dice a alguien como un insulto”, dijo Hansson. “Pero cuando yo realmente busqué el término – Tener un gran sentido de importancia o de las habilidades de si mismo” - pensé, es cierto”.

Entonces, hizo click en la siguiente diapositiva, con letras blancas en un fondo oscuro en donde expuso su respuesta a aquellos pesimistas: “Fuck you”. La multitud estalló en risas y aplausos.

Sigue leyendo »

Archivado en: Ayerviernes, Traducciones