Will Web For Food

• This post also available in English.

Acabo de releer Re-work de Jason Fried y David Heinemeier. Es un libro muy inspirador. Me encantan las ilustraciones que acompañan al texto. El trabajo de Mike Rohde es impresionante. Me gustan tanto que creo que voy a hacer carteles para mi oficina con ellos.

No estoy de acuerdo con todo lo que cuentan los autores. Pero me encontré con algunas ideas que llevaban tiempo dando vueltas por mi cabeza acerca del trabajo y la vida.

Después de leer este libro, mi mantra para el próximo año será vincularme a proyectos movidos por la pasión. Esto a veces se nos olvida a todos. Estamos obsesionados con los resultados y obtener una idea brillante. Cuando lo importante es “empezar a hacer algo”

¡Que el 2012 sea un gran año para todos!

Por mi experiencia en reuniones de definición de proyecto y por el tipo de documentos que solemos generar en ese proceso, creo que podría ser interesante replantearnos la forma en la que afrontamos los “kickoff“.

El proceso y la documentación suelen resultar farragosos y asimétricos. Asimétrico por que la documentación suele ser concreta en la parte en la que debería ser abstracta, como por ejemplo cuando se definen los campos de formulario de un proceso. Mientras que es abstracta en lo que debería ser concreta, como por ejemplo como deberían ser los objetivos o indicadores a tener en cuenta en los procesos principales del producto.

Esta situación propicia que en algunos casos el proceso de diseño de producto se convierta en un intricado proceso de gestión de expectativas del equipo y el cliente.

Todo este proceso tienen algo que hace que me resulten lejanos a mi forma de trabajo de los últimos tiempos.

Pero no digo que la toma de requisitos sea una fase a evitar, de hecho tener unas pautas de que se espera del proyecto siempre es útil y necesario. Pero creo que no lo enfocamos del todo bien.

Una forma de resolverlo podría ser teniendo una entrevista con el cliente. Algo que sirva para aprender, para conocernos, para entendernos. No en torno a una mesa con un montón de gente de diferentes departamentos, sino una entrevista dialogada en la que entendemos las necesidades, los desafios, el ecosistema en el que vive el proyecto. Estableciendo una relación de dialogo.

¿Y si vamos un poco más allá?

¿Se podría monta como un híbrido de  entrevista y taller de co-creación?. En el que el cliente cuenta lo que necesita, que implica, como lograrlo, o mezclarlo con un focus-group. Detectar necesidades e inquietudes.

Un taller en el que se trabaja con el equipo del cliente sobre las dificultades o desafíos del proyecto.

¿Y si el documento de kickoff es un primer prototipo?. ¿O grabarlo y editar el video y que uno de los entregable sea un clip de video con todo el proceso?

Suena interesante. No sé si podría reducir tiempos del proyecto, pero desde luego haria más sencillas las cosas.

Si tienes un proyecto y crees que esto puede tener alguna utilidad avisame por favor, estaré encantado de jugar en tu equipo.

 In the early days of online data collection there were no reliable methods of obtaining respondents for surveys. By comparison with other modalities, researchers were suddenly faced with a medium where there were no directories, no lists, and no RDD (random digit dialling). There were no simple options for identifying the population and no suitable methods for defining a sample.

The most frequent approaches, in those earliest days of online data collection, were to use advertising tools and client databases (for the small number of clients who had usable lists of customers‚ email addresses). The advertising route consisted of using invitations to surveys implemented via advertising mechanisms such as banner ads and pop-ups.

However, online data collection only took off as a major force when online access panels became widely available. Readers should note that as online access panels have become more central to research they are increasingly being referred to as, simply, online panels, or just panels.

Before the mid-1990s, panels had been fairly rare outside the USA, and they were usually reserved for specific purposes, such as retail audits. In the USA there had been a history of mail (postal) panels and this, to an extent, explained the more rapid development of online access panels in the USA. It has also been suggested that the more conservative nature of European research buyers and providers slowed down the development of online research in Europe.

The development of large scale online access panels became the key to unlocking the use of the internet for quantitative research. However, by adopting the widespread use of online access panels, market research has moved away from the ability to claim that it uses random probability sampling and that it can “scientifically” project its findings onto the wider population‚ a fact and consequence that are covered later in this book.

There is a traditional saying in marketing that buyers tend to want things to be better, cheaper, quicker, but organizations can, at best, only offer two of these at any one time. By accepting the methodological limitations of panels, market research was able to make research both quicker and cheaper.

In “The Hardback of Online and Social Media Research“

La llegada del buen tiempo y la vacaciones es un buen momento para despachar lecturas pendientes.

Mi lista para este verano es la siguiente:

Search Analytics for Your Site de Louis Rosenfeld,  editado por Rosenfeld Media.

Rosenfeld y analíticas. El autor del oso polar ha publicado el mes de julio su ultimo libro. Es un recorrido por el uso de SSA (site search analytics) en un proyecto. El texto se basa en su experiencia impartiendo cursos y tiene un marcado carácter didáctico mostrando procesos de proyectos.

Innovation Games: Creating Breakthrough Products and Services de Luke Hohmann, editado por Addison-Wesley Professional.

Redefinir los procesos con los cuales se lleva a cabo consultoría.  Creo que puede ser útil para ampliar el arsenal metodológico del reseach design a nivel operativo. Si estas involucrado en proyectos de este tipo y creo que puede ser útil.

Las ilustraciones que acompañan al libro no me gustan nada.

The Tiger That Isn’t: Seeing Through a World of Numbers de Michael Blastland y Andrew Dilnot, editado por Profile.

Sobre las estadísticas, que significan y como se deben leer. Tiene buena pinta y la mitad de la gente que me rodea lo recomienda. Complemento para la visualización de datos y dashboards.

Hay ciertas ideas dentro de la profesión que han tenido un gran poder de penetración.

La idea (¿mantra?) de que el diseño de interacción es una cuestión de sentido común, es una de ellas, (además de ser una idea errónea es muy peligrosa). Otra de estas ideas es la que nos convierte a los profesionales en defensores del usuario.

Esto creo que es una estrategia errónea. El usuario se defiende solo. Y si es Usuario/Cliente/Elector del servicio la discusión ni tan siquiera debe ser iniciada porque no tiene sentido. En ciertos casos el usuario puede verse obligado a utilizar un producto, servicio o interfaz que no le gusta, pero en cuento tenga la ocasión lo abandonara en bloque. Es el producto el que tenemos que cuidar para que se adapte al usuario.

¿Porque digo esto? Lo que sustenta que todos los días nos sentemos a trabajar son los proyectos. Estos proyectos tienen detrás un interés económico. En ocasiones el beneficio no proviene directamente  del usuario, pero en casi todos los casos, esta directamente relacionado el binomio Usuario satisfecho-Ganar dinero.

Quiero pensar que nadie en sus cabales se le ocurría contradecir este binomio, pero se ven tantas cosas raras ahí fuera que no pondría la mano en el fuego por ello.

Cuando me refiero a que es una estrategia errónea, me refiero a que la sensibilidad por una satisfactoria experiencia de uso debería formar parte del ADN de cualquier profesional relacionado con el diseño del producto.

Esta sensibilidad, es lo que nos permitiría abandonar el rol de abogado del usuario. Reorientar el concepto de diseño a una idea más amplia que el puro ejercicio de styling, y a dotar de significado muchas palabras que se están quedando vacías, como experiencial de uso, de servicio e innovación.

Creo en la parte lúdica y vocacional de la profesión, y por eso no entiendo cuando se  la quiere convertir en un cascaron hueco y vacío. También la entiendo como un proceso y como un intercambio en el que todos aprendemos.

Desambiguazión: Este post no habla de sitemap en XML para posicionamiento en buscadores.

Los Sitemaps son diagramas que representan los contenidos del site.
Vale, parece sencillo, este es nuestro Sitemap, un diagrama que dice aquí van “los servicios”, aquí “quieres somos”, aquí el “blog”…
Pero esta idea se complica cuando se incluye la variable “navegación”.  El Sitemap puede dar una idea de cómo se llega a un sitio, cual es la relación entre las distintas pantallas (¿páginas del site? ¿contenidos?). Pero la navegación se debe resolver en otro documento que se llama Task Flow. Llevar a cabo un Task Flow nos obliga a identificar objetivos de los usuarios (Investigación) y que diseñemos para lo probable y no para todo lo posible.
Volviendo a los Sitemap. Para iniciar el Sitemap hay que tomar una decisión. Y esa decisión responde a ¿Cómo se va a enfrentar el equipo al proyecto?.
Podemos elegir entre a un nivel muy alto de detalle, donde se van a modelar todas las pantallas y todas las interacciones y microinteraciones, vamos a llamar a esto Enfoque A.  O un enfoque modular, donde vamos a descomponer los componentes de las pantallas en módulos reutilizables. Vamos a llamar a este otro Enfoque B.

Estas consideraciones pueden influir mucho sobre como se va a desarrollar el proyecto, y se suelen dejar al gusto del “prototipador” que las puede tomar de una forma inconsciente. (Además de que no le compete a él tomar estas decisiones).

El enfoque A consume mucho más tiempo en prototipar, y se suele emplear en proyectos pequeños. Tiene como punto negativo que hace que lo importante se diluya entre la cantidad y genera la sensación de documentación al peso.

El enfoque B es mucho más participativo y esta más orientado a equipos de desarrollo,  se suele emplear en proyectos grandes donde hay varias personas implicadas en el diseño de los wireframes. Como punto negativo tiene un nivel de abstracción mucho más elevado que dificulta su consumo por el cliente, pero permite una ejecución mucho más ágil.

Algo tan asumible como en principio es un Sitemap puede determinar como se va desarrollar el proyecto.

Para leer más sobre Sitemap (y entregables)

• Information Architecture (2nd Ed.) de Rosenfeld and Morville.
• Communication design de Brown.
• A Project guide to UX design de Unger y Chandler.
• Modular web design de Curtis.