Es el momento en que tú le vuelves a contar al cliente cual es el problema que hay que resolver. Con suerte es el mismo que él te contó, pero no descartes que sea otro distinto.

Es tan importante esto de contrastar con el cliente si lo que has entendido es lo mismo que él tiene en su cabeza, que si no lo haces bien, puede fastidiarte todo el proyecto cuando menos te lo esperas.

Esta semana comenzamos a ver algunos feedbacks y estamos recibiendo interesantes comentarios sobre la organización y el evento en sí. No sé si es porque la gente es muy buena, pero todos son muy positivos.

Lo más curioso es que todo el mundo destaca aspectos que, al menos a mí me parece, deberían ser básicos y “de serie” en cualquier conferencia o seminario.

Para que nunca se me olviden y por si a alguien le viene bien, los resumo en 3 temas. Algo así como “The 3 golden rules for a successful conference”

1.- Contenido

Hay dos formas de hacerlo: forzando un programa o dejando que lo hagan los ponentes. En la primera, creas un programa de charlas que sea coherente, cubra los aspectos interesantes del tema de la conferencia y buscas gente que pueda hablar sobre ellos.

En la segunda, abres una convocatoria de ponencias y entre todas las recibidas seleccionas las mejores y te tiras horas haciendo encaje de bolillos para crear un programa coherente. Esta es la que escogimos para la Conferencia Rails. Funciona, porque apelas a que la gente cuente lo que mejor sabe y se involucre con sus respectivas ponencias. Pero ojo, a veces es un infierno hacer la selección de temas. En eventos que ya son maduros (que llevan más de alguna edición), puede que no sea lo más recomendable.

2.- Infraestructura

Básico y sencillo. Basta con preocuparse de que las salas sean medianamente cómodas, que no se vendan más inscripciones que sitios disponibles, que haya enchufes en todos lados (o llenas de regletas), que la WiFi funcione y que haya un espacio para juntarse y conversar en los intermedios. Punto. Si a eso le añades café y algo de picar, mucho mejor. En Suecia vi que además, metían carritos con fruta dentro de las salas y la gente se cogía una naranja o un plátano para ir comiendo mientras escuchaba la ponencia. Buena idea.

3.- Horarios

Las ponencias o charlas tienen que empezar y acabar a su hora. A rajatabla, si puede ser. Para eso basta con dejar tiempo suficiente entre ellas, de modo que de tiempo al ponente a preparar el material y a la gente a llegar y sentarse. En esta edición, yo estuve como cancerbero en algunas salas, reloj en mano, controlando el tema. Y funcionó. La gente alucinaba con que se respetasen los horarios… yo creo que es que estamos mal acostumbrados, nada más. Pero mira que es fácil.

Y punto. Con estas tres cosas consigues un evento decente, que deje un buen sabor de boca a los asistentes y que tenga posibilidades de continuar en el tiempo. ¿Por qué no se hará más así?

La organización, impecable. Nunca he visto nada así (ya hablaré de ello en otro post).

He tomado unas cuantas notas y voy a compartirlas con vosotros. Vamos con la primera.

La keynote del jueves estuvo a cargo de Brandon Schauer, de Adaptive Path. Habló de Strategic Experience Design: Beyond Customer Satisfaction. Lo que traducido libremente vendría a ser: “Diseño estratégico de experiencia: más allá de la satisfacción del cliente”.

Ideas claves:

1. Las aplicaciones sólo tienen sentido si son “útiles”.
2. Las aplicaciones sobreviven si además son rentables.
3. La empatía con el consumidor.
4. Aquí se trata de tomar decisiones.

Las aplicaciones sólo tienen sentido si son “útiles”

La tecnología nos permite hacer virguerías varias, cosas que se ven preciosas en pantalla, que son tremendamente fáciles de usar… pero si no hay un consumidor o usuario activo detrás de eso, no sirve de nada.

No basta con que sean usables, sino que tiene que haber alguien a quien le sirvan de algo. Un problema bastante frecuente en el mundo del diseño de interacción y diseño visual de interfaces de usuario es la llamada “miopía de usabilidad”: sólo somos capaces de ver si la aplicación es bonita y si es usable, pero hasta allí llegamos. La clave es preguntarse si alguien la necesita o si alguien estará dispuesto a usarla.

Las aplicaciones sobreviven si además son rentables

Un usuario que considera que lo has diseñado le es útil, es un usuario satisfecho. Ahora, eso es algo que hay que medir. Si no puedes medir, no puedes gestionar. Y a tu cliente no le sirve de nada. El famoso ROI, vamos.

La pregunta clave para conocer la satisfacción de un usuario no es si está satisfecho, sino si estaría dispuesto a recomendar el producto a un amigo. Ahí es donde radica la verdadera dimensión del problema.

Un buen punto de partida para trabajar en proyectos de diseño pensando en el ROI, es el artículo Business Case Modeling for Design, de Henning Fischer.

Asegura Schauer que realizar un breve modelo de negocio al inicio del proyecto, ayuda mucho a que todo el equipo esté alineado con los objetivos del proyecto y se mantenga un enfoque común.

La empatía con el consumidor

Para trabajar proyectos que tengan éxito, hay que practicar la empatía con el usuario final. Una vez más, no se trata de la clásica empatía que estamos acostumbrados a pregonar, sino a la empatía que consiste en entender los problemas y necesidades reales de la gente.

Un buen ejemplo es el de Target Pharmacy, la división farmacéutica de las cadenas Target. En Estados Unidos lo normal es que los medicamentos te los vendan en botes estándares que vienen con una etiqueta con tu nombre y la posología. Lo malo es que son todos tan parecidos, que se dan bastantes casos de ingesta accidental de medicamentos en las casas. No es raro que un marido somnoliento se tome la medicina de su mujer por error, por ejemplo.

En Target entendieron el problema; estudiaron a los consumidores y sus hábitos de vida diaria. Descubrieron el problema y lo solucionaron con diseño: crearon nuevos botes de medicamentos con etiquetas más claras, con el nombre del paciente más destacado y con un set de 6 anillas de colores para colocar en el cuello de las botellas. Así, cada miembro de la familia podía tener su propio color y nadie se equivocaría de medicinas. Simple y efectivo. El retorno de inversión fue bestial.

Trabajaron desde el final de la cadena hacia atrás: desde la experiencia real del usuario hacia el negocio.

Aquí se trata de tomar decisiones

Por último, Brandon Schauer incidió en un objetivo básico de los consultores de diseño de producto: ayudar a los clientes a tomar decisiones.

El éxito de un producto radica en diferenciarse. Y para ello, hay que tomar decisiones. Decidir en qué será bueno, qué funcionalidades o aplicaciones son las que otros productos de su tipo no cumplen e ir a por todas con ellas. Hay que saber descubrir las necesidades de los clientes. Muy pocas compañías están alineadas con lo que quieren sus clientes, existe una brecha enorme entre lo que las empresas creen que ofrecen y lo que los clientes perciben.

Esa brecha se cierra creando productos y servicios muy enfocados a soluciones concretas. Citaba por ejemplo a Flickr: un servicio que su fuerte es compartir imágenes. No las edita, no crea libros con ellas, no permite hacer un montón de cosas que otros servicios sí ofrecen, pero es el mejor para compartir imágenes. Punto. Ahí radica el secreto de su éxito.

Otro ejemplo: Lulu.com. Un servicio para autoeditar libros. Sólo sirve para eso, pero detectaron una necesidad de la gente que quería editar sus propios libros y se dedicaron a eso. Funciona y genera negocio.

Textual: “Strategy is about saying no. You can’t do everything. You need to make decisions“.

El mensaje final fue: todo esto es simple de hacer. No requiere grandes esfuerzos ni equipos demasiado especializados. Solamente hay que tenerlo en cuenta y querer hacerlo.

“Mere mortals can do this“.

Pues eso.

 La gente de inUse, la mayor consultora sueca en experiencia de usuario, ha montado una conferencia con una pinta buenísima para mediados de junio. Yo ya tengo mis billetes y reservas hechas.

Son dos días en la Universidad de Malmö, con ponentes de lujo que hablarán sobre casos prácticos, metodologías y experiencias. Viene gente de Yahoo!, Cooper, Frog Design, Avenue A/Razorfish y Adaptive Path. Ahí es nada.

La verdad es que llevaba tiempo buscando una conferencia que fuese interesante y que no me obligase a ir a Estados Unidos para asistir y me llevé una sorpresa más que agradable cuando encontré esta. Y me ha encantado el enfoque: "Design for effect". Se trata básicamente de diseñar pensando en el resultado en términos de negocio. Es decir, conociendo bien lo que se quiere obtener, las necesidades del público al que va orientado y las limitaciones de producción. Un enfoque que todos los que trabajamos en esto –y no estamos colaborando en ONG`s- deberíamos conocer y practicar. Porque, a fin de cuentas, nuestros clientes quieren obtener beneficios con sus productos y nosotros cobrar por nuestro trabajo.

Para ir abriendo el apetito, os cuento que se verán casos como el rediseño del New York Times, Skype y su adaptación a teléfonos móviles o el proceso de diseño de producto del SonyEricsson K880i. En el lado más teórico, la gente de Cooper contará la técnica personas, la de Yahoo! compartirá sus experiencias en cuanto a metodologías y herramientas, Adaptive Path sacará enseñanzas de la interacción juegos y Frog Design se adentrará en el terreno de los productos móviles. Los organizadores, inUse, expondrán sobre Effect-focused interaction design y el uso del modelo Effect Map para comenzar el proceso de diseño. Y esto no es ni la mitad de los temas que se tratarán.

Más:

El programa completo

Los ponentes

Mini brochure del evento (PDF)

¡No lo pienses más! ¡Prueba ahora Presentr, totalmente gratis! (por un tiempo limitado). Disponible en español e inglés.
Un desarrollo rápido de Luis Villa, Ale Muñoz y mio. Pa’ que luego digan que el agile development no sirve…

Luis escribía en su excelente resumen de @media que no se oyó la palabra usabilidad en ningún momento y concluía que no es necesario hablar de ella porque debe “venir de serie” en cualquier desarrollo. Totalmente de acuerdo. Es más, esto es algo en lo que venía pensando hace tiempo ya, quizás desde que estoy metido en un mega proyecto que ya va para los dos años de mi vida (el proyecto es mayor, pero es lo que yo he estado en él), en una mega empresa.

En septiembre de 2004 me incorporé en las fases de definición en este proyecto enorme de una empresa de seguros muy, muy conocida. Y casi desde el inicio tenía la sensación de que algo no estaba bien cada vez que alguien mencionaba “usabilidad” en reuniones, mails o discusiones. El problema no era que se hablase de ello, sino que se utilizaba como si fuese un elemento más del producto, como una fase de trabajo… estaba al mismo nivel que la programación o el diseño de la lógica de negocio. Se pasaba del “diseño técnico” a la fase de “usabilidad” y luego a la maquetación. No me cuadraba, pero no sabía bien por qué. Ahora, gracias al comentario de Luis, acertadamente sintetizado por Javier (“La usabilidad viene de serie, señores”), lo he podido ver claro. ¡Eso es! Es que no se trata de aplicar una capa de pintura sobre una pared agrietada, es que la pared debe estar construida ya pensando en que no se va a llenar de grietas…

Recuerdo cuando a fines de los 90 tratábamos de convencer a los clientes de que debían pagar el trabajo de un consultor en usabilidad para que todo fuese bien y la incredulidad de muchos cuando decían “pero vamos a ver… ¿me decís que tengo que pagar más por algo que doy por hecho, es decir, que lo que vais a hacerme esté bien diseñado?” Y claro, había que explicarle que sí, que ese buen diseño implicaba varias actividades que no estaban normalmente contempladas en el proceso de diseño de una interfaz, hasta ese momento limitado al aspecto estético, y que por eso le saldría más caro.

Hoy, que ya hemos aprendido algo, no incluimos “usabilidad” como un aparte dentro de las propuestas comerciales. O al menos, no deberíamos hacerlo. Porque la usabilidad se da por descontada. Es lógico que las interfaces tienen que ser simples de usar, ser amigables y cumplir con todas esas características que tan bien enumerábamos en las presentaciones. La diferencia está en hacer un buen producto, no sólo un producto “usable”.

Volviendo al inicio de este texto, decía que aquí, donde consumo mis horas laborales, eso no acaba de entenderse aún. Y es que el equipo donde trabajo se llama “grupo de usabilidad”, y yo, soy el “especialista en usabilidad”. No pocos problemas me trae eso, porque para algunos soy una especie de Torquemada que tirará por tierra sus desarrollos e ideas geniales en las “auditorías” (palabra atemorizante por excelencia) que me encargan y para otros, un simple charlatán pinta-monas que contribuiré a que el proyecto salga más tarde y los programadores demoren más en hacer su trabajo. Y todo, para que al final salga un producto “que hace lo mismo que antes, pero más lento… con lo acostumbrados que estábamos a trabajar con el 3270 y las líneas de código”.

Y aquí es donde yo tengo que explicar que no se trata de complicarle la vida a nadie, que no es que no tengamos nada mejor que hacer ni que queramos retrasar los desarrollos. Sino que pensamos en los nuevos usuarios, que aprenderán más rápido; pensamos en los mantenimientos de las aplicaciones, que podrán ser hechos por cualquiera y no sólo por el programador original; pensamos en que las aplicaciones podrán ser escalables y que un equipo de desarrollo a miles de kilómetros de distancia podrá crear una, siguiendo las guías de estilo que hemos editado, etcétera.

Pero la dichosa palabrita se nos pega a la espalda y es un lastre. “Los de usabilidad”, “es norma de usabilidad”, “lo prohíbe usabilidad”, “usabilidad te va a auditar”… Así, es francamente complicado explicar que no, que lo que hacemos es diseñar buenas aplicaciones, buenos productos. Y que lo necesitan, igual que como necesitan un buen jefe de proyecto o un buen programador. Que el diseño del producto no es solamente un tema de costes y tiempos, sino de personas, de interacción de esas personas. Esa es la clave, la interacción.

Intento explicarles que lo que importa no es que la aplicación sea bonita, sino que funcione. Que los procesos sean lógicos, que los usuarios tengan aplicaciones que les solucionen los problemas, que se comporte como se espera.

Quizás haré como Luis y voy a intentar eliminar la palabra “usabilidad” de mi discurso. Me centraré en la interacción, en los procesos, en los tiempos (o “tempos”) de la aplicación. Y con ello, trataré de demostrarles que el buen diseño no está reñido con los proyectos ágiles.

Creo, sinceramente, que son precisamente las grandes corporaciones como esta, las que más necesitan de un trabajo serio en diseño de interacción, para que la “usabilidad” no siga siendo un añadido, sino algo de serie.

Como decía al principio, hace casi dos años que estoy trabajando en un proyecto en una empresa bastante grande de seguros, dentro del llamado Grupo de Usabilidad. La misión de este equipo de gente es participar en un gran proyecto de renovación de herramientas informáticas propias. Es decir, el software que hace que el negocio funcione.

Normalmente las grandes empresas, como bancos, aseguradoras, telefónicas y otras por el estilo, tienen sus propios departamentos de informática que trabajan haciendo desarrollos a medida de las necesidades. Es cierto que muchas veces se contratan estos trabajos a empresas externas, pero cada vez es más común que el trabajo se haga en casa. Por motivos básicamente prácticos y de confidencialidad.

Una empresa de seguros, por ejemplo, no encuentra en el mercado un paquete de software que pueda cubrir todas sus necesidades, dada la complejidad del negocio y las particularidades de cada empresa. Eso sin entrar en los intrincados vericuetos de la organización misma (estructura de administración, de ventas, de agentes, etc). Todo ello se traduce en mil y una pequeñas aplicaciones que se van creando a medida que se necesitan. Al cabo de unos años, lo que hay es un desorden absolutamente incontrolable y, lo que es peor, imposible de mantener.

Es en ese momento cuando puede surgir la iniciativa de hacerlo todo de nuevo. De recomenzar, pero contando con pautas estándares, siguiendo una metodología bien pensada y utilizando tecnologías comunes. Para que cuando sea necesario hacer algún cambio o mejora en el futuro, no cunda el pánico al darse cuenta de que el informático que “tenía todo el proyecto en su cabeza” se ha ido y nadie es capaz de meter mano en el código.

Ahora, este tipo de proyectos no son moco de pavo. Plantearse algo así en una empresa con miles de empleados y oficinas por medio mundo, es algo gordo. Muy gordo. Significa pensar en un proyecto que puede –y seguramente lo haga- durar algunos años. De ahí que la planificación y definición juegan un papel fundamental.

En el caso que nos ocupa, la empresa tomó la decisión de renovar sus aplicaciones por completo, migrándolas a un entorno web que permitiese una actualización y mantenimiento más sencillo, a la vez que poder asegurar una homogeneidad de estilo. Antes, cada aplicación adolecía de las “creatividades” individuales de los equipos de desarrollo que habían participado en ellas.

Dentro de este macro proyecto –curiosamente- se contempló la necesidad de contar con gente especialista en usabilidad. Ignoro quién tuvo la feliz idea, pero sin duda que fue una inspiración que ha valido la pena (no así el nombre del grupo).

Lo más interesante de todo este trabajo, más allá de estar en una de las corporaciones más grandes de España, ha sido el constatar la necesidad que tienen este tipo de empresas de tener equipos de diseño dentro.

Principalmente, la participación de gente dedicada al diseño de interacción puede asegurar que todo el proyecto tenga coherencia. Que todo lo que se haga sea homogéneo y que “respire” un aire familiar. Da igual cuántos programadores, jefes de proyecto, coordinadores o lo que sea, estén involucrados. El producto final, siempre parecerá hecho por los mismos. Algo que las grandes empresas de software han entendido hace mucho tiempo ya y que no sé porqué en otros mercados recién se está tomando conciencia de su importancia.

¿Se imagina alguien que los programas de Apple se comportasen todos de forma diferente o que tuviesen estilos visuales distintos entre sí? O el mismo Microsoft Office: si Word, Excel y PowerPoint, por ejemplo, usasen distintos botones, una distribución de menús propia de cada uno y los menús tuviesen diversos nombres para las mismas acciones, sería un caos. De hecho, nadie lo compraría. Pero parece ser que cuando se trata de los desarrollos propios de otras empresas, todo eso da lo mismo.

Un equipo de diseño involucrado desde el principio aporta precisamente eso, la tranquilidad de saber que existe un control de calidad y una definición de estilos y procesos que además, no choca con los principios de facilidad de uso y eficiencia. Que la usabilidad va de serie, en definitiva.

Si esto se hubiese tomado en cuenta desde el principio, si el “grupo de usabilidad” no hubiese sido un extra -compuesto además por personal externo-, se habrían evitado discusiones tan peregrinas como el correcto diseño de un formulario o la necesidad o no de tener mensajes de espera en las aplicaciones que hacen consultas complejas a la base de datos. Nadie pone en duda los dictámenes de un departamento de arquitectura de sistemas o el de metodología, porque están incorporados de base. Ya es hora de que el diseño de interacción lo esté también.

Creo que nuestra tarea, la de quienes estamos trabajando en proyectos similares en empresas grandes, debe ser también convencerles de que incorporen en su trabajo diario el Diseño, así con mayúsculas. Que dejen de verlo como el peluquero que se llama para tratar de arreglar a la novia en el último minuto. El diseño debe estar dentro, ser indiscutible, tener un papel fundamental. Que dejen ya de hablar y discutir sobre usabilidad, porque ya llevamos mucho tiempo en lo mismo como para no darnos cuenta de que si no se lleva puesta, no sirve de nada.

Cuando esto suceda en las grandes corporaciones, habremos dado el principal paso para dejar de hablar de ello. Habremos llegado al punto más alto en la curva de aceptación de un nuevo concepto o idea y podremos, por fin, dedicarnos a lo bonito: diseñar y solucionar los problemas de las personas.

[1]Propongo además, de este modo, la participación asíncrona para todos los que -por motivos personales, geográficos o simplemente estomacales- no podamos asistir.

Me gusta especialmente porque recoje de manera sencilla tanto las técnicas de representación de información en un wireframe como los problemas que pueden tener (sobre todo de mala interpretación de los clientes) y la forma de aplicarlas correctamente.
El poster se ha presentado en el IA Summit 2005 realizado en marzo en Canadá.

Brown sabe de lo que habla, sino basta mirarse la serie de artículos sobre el tema que lleva publicando desde 2002 en Boxes and Arrows. Toda una colección de 10 textos sobre entregables que revelan hasta los más íntimos secretos de Visio y las mejores enseñanzas de Tufte.

(encontrado vía Guuui.com)

Consiste es estudiar cómo desplaza la vista una serie de voluntarios, sobre un diseño. Más concretamente sobre páginas de periódicos y desarrollos multimedia.

La experiencia es muy interesante, porque aporta datos que son muy difícilmente obtenibles mediante métricas normales en Internet. Se trata no de ver dónde hace clic cada uno, sino de observar realmente dónde posa la vista y durante cuanto tiempo.

Es genial ver cómo ante páginas llenas de texto el “escaneo” visual es realmente eso: un rápido paseo por las primeras palabras de cada párrafo y a otra cosa…

Las conclusiones obtenidas son muy valiosas. Por ejemplo, han descubierto que en páginas web existe una clara tendencia a fijar la vista en zonas concretas, más allá del diseño, tal como lo enseña la siguiente imagen:

El site, que realmente es digno de verse, posee muchos estudios, conclusiones y artículos interesantísimos. Sobre todo porque aporta información que muchos no podemos permitirnos el lujo de investigar (un sistema de eyetracking cuesta lo suyo).Muy recomendable también ver los vídeos de una sesión sobre un periódico digital.
(enviado por Tarda)

El gran valor que tiene es que en un solo documento se reseñan temas, ocurrencias de esos temas (las veces que aparecen en los documentos), relaciones entre ellos y otras características que facilitan la navegación y búsqueda de información. Un topic map es en sí un documento, por lo que puede haber topic map de topic maps. Y eso le da un poder bastante amplio.

Mucha más información en The TAO of Topic Maps.