La primera noche temática, celebrada el pasado 22 de junio de 2006 en la oficina de IT7 y coincidiendo con el primer aniversario de los Cócteles Cadius en Canarias, la dedicamos al prototipado, tal como habíamos anunciado. Antes de sentarnos, decidimos que cada uno expondría aquello que le llamara atención sobre el asunto, y que iríamos interrumpiendo cuando tuviéramos algún punto que comentar.

Empezó José R. Quevedo rompiendo el hielo, y, posteriormente, Aritz Suescun, Domingo Cabrera y Ruymán Ferrera fueron interrumpiendo, aportando ideas y opiniones.

La idea principal de José es que hay tanta disparidad en la forma de concebir, plantear y llevar a cabo el prototipado que hacer un repaso exhaustivo a las teorías sobre él origina más dudas que certezas. Unas justificaciones al respecto:

• En cada caso depende de lo que se desee evaluar (diseño gráfico de la interfaz, parte de interacción…) y de la fase en la que se plantee el protipado; si es inicial, generalmente se usan prototipos muy esquemáticos y más abstractos para el cliente, si es en las fases finales, es conveniente emplear prototipos más elaborados y detallados.
• La enorme diversidad de formas de llevar a cabo el prototipado (desde el lápiz y papel a la denominada High-Fidelity; desde el prototipo que representa interfaces completas al que se limita a mostrar la disposición de una información determinada) tampoco ayuda a fijar ideas en torno a esta práctica.

Entendemos que los fundamentos del prototipado es filtrar posibles errores, depurar los diseños, tener un feedback directo con el cliente (reduciendo las malinterpretaciones) y, en definitiva, ahorrar costes en la fase del proyecto a la que se aplique.

En ese punto, todos planteamos nuestras dudas sobre la utilidad real de elaborar prototipos, la viabilidad de hacerlo con cierto tipo de clientes y para proyectos pequeños. La idea aportada por Aritz es que cada prototipo debe servir para una fase del proyecto determinada y debe adecuarse al cliente con el que se trabaja. Citamos a Eduardo Manchón:

"Un prototipo sólo vale la pena si se puede tirar a la basura".

Sobre eso, Mingo apunta que, a pesar de nuestras opiniones dudas sobre el uso de esta técnica, debe haber oportunidades para el uso de prototipos de alta calidad.

Comentamos que en el caso concreto de IT7 no utilizamos las técnicas de prototipado en el sentido estricto. Los principales motivos:

• La mayoría de nuestros proyectos son para sitios web pequeños.
• El origen de los encargos suele basarse en una propuesta de contenidos (y Arquitectura de la Información) que en normalmente contiene propuestas de navegación básicas y nos sirve de prototipo.
• Nuestros clientes suelen tener una escasa capacidad de abstracción: es frecuente que cuando presentamos bocetos de diseño, reparen en las imágenes colocadas como ejemplo y en "ese extraño idioma" de los textos de prueba (el famoso Lorem ipsum). Imaginen cómo reaccionarían si les presentáramos prototipos de baja definición.

Nos paramos en la concepción del diseño como concepto global, el llamado diseño con mayúsculas, que agrupa todas las escalas del trabajo web, no sólo la estética.

Los prototipos no miden el tiempo

Enlanzando con el punto anterior, comentamos la idea de Javier Cañada de que en la experiencia de los usuarios importa el diseño de interacción; y que éste se diferencia del resto de diseños en que tiene una cuarta dimensión: el tiempo.

Los prototipos, sin embargo, casi nunca miden tiempos reales. Cuando se usan prototipos, la respuestas suelen ser inmediatas, no importa cuán compleja sea la hipotética consulta realizada, ni lo que tarde el servidor en procesarla, ni las dificultades que pueda tener el usuario en el contexto real de uso.

Prototipos reutilizables y modulares

Prototipo reutilizable.

También denominado como evolutionary prototyping; no se pierde el esfuerzo efectuado en la construcción del prototipo, pues sus partes o el conjunto pueden ser utilizados para construir el producto real.

Prototipo modular.

También conocido como prototipado incremental; se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.

En ambos casos la idea básica consiste en aprovechar el trabajo realizado en el prototipo para las fases posteriores. Casi todos vemos un planteamiento demasiado optimista y, bajo nuestra experiencia, no vemos rentable esta técnica para elaborar prototipos. Aritz comenta que a veces no se pierde el trabajo, un ejemplo es el desarrollo ágil que realiza el equipo de 37signals, ellos comentan que no trabajan con bocetos en papel y crean directamente los prototipos con HTML y CSS que se usan en la versión final del producto (Actualización: dos años después siguen defendiendo su postura). Claro que la mayoría de sus proyectos son desarrollos propios que no dependen de la opinión de terceros.

Prototipado para aplicaciones de escritorio

También se abordó las diferencias entre elaborar prototipos para aplicaciones de escritorio y para sitios web. De hecho, hablamos de la experiencia de usuario en términos más generales, no nos limitamos al prototipado. Nos planteamos que, en la práctica, es muy habitual que los usuarios aprendan a utilizar la interfaz con sus posibles defectos sin cuestionarla.

Es evidente que la importancia de los estándares en este campo (es decir, de los sistemas operativos más utilizados) es muy grande y el desarrollo intenta imitar su funcionamiento casi siempre. Además, Aritz -que es quien más experiencia tiene en proyectos en este tipo- comenta que Microsoft establece parámetros muy claros (The Microsoft Windows User Experience, 1999 o Windows XP Visual Guidelines, 2001) para el desarrollo de aplicaciones de escritorio. Apple también hace lo propio (Apple Aqua Human Interface Guidelines, 2002).

Baxley, Morville, Brown y otros ejemplos

José presentó algunos conceptos, relacionados con el prototipado y bastantes distintos a los que habíamos comentado hasta el momento: el "Modelo Universal de la Interfaz de Usuario" (PDF) propuesto por Bob Baxley y comentó el "panal" de la experiencia del usuario de Peter Morville.

Hablamos un poco de Dan Brown, que cuenta en Boxes and Arrows su experiencia de cómo llegó a la idea de diseñar prototipos de baja definición, así como de sus comentarios sobre la posibilidad de diseñar prototipos que coarten la creatividad de los diseñadores. Vimos algunos de los prototipos que empleaba y comentamos su sencillez, tirando a rudeza. También comentamos su esquema de representación de datos (PDF) en "wireframes".

Asimismo, comentamos otros ejemplos, como los de Nelson Rodríguez-Peña o los mencionados por Torres Burriel, especialmente el que trata del artículo de Andres Zapata sobre wireframes para aplicaciones de Internet enriquecidas (Rich Internet Aplications, RIA) que hacen uso de storyboards para definir lo que pasa en la aplicación. Curiosamente, esta técnica se había aplicado en IT7 en 2004 para un soporte multimedia.

Durante la exposición de José, nos entretuvimos hablando de la importancia y relevancia que cobraban ciertos artículos por los esquemas o imágenes que incluyen. Dos ejemplos sobre lo mencionado fueron los hexágonos de Morville de los que hablamos antes o la superposición de planos en "los elementos de la experiencia del usuario" (PDF) de Jesse James Garret. Al respecto, Mari Carmen Marcos apunta que Garrett habla de cinco capas que definen un sitio web al mismo tiempo como una interfaz de software y como un sistema hipertextual. De abajo a arriba:

• Estrategia: necesidades del sitio y objetivos del usuario.
• Alcance: especificaciones funcionales y requisitos de contenido.
• Estructura: diseño de interacción y arquitectura de la información.
• Esqueleto: diseño de la información, diseño de la interfaz y diseño de la navegación.
• Superficie: diseño estético.

Entonces comentamos las obras de Edward Tufte sobre el "vocabulario visual" y la presentación gráfica de la información. Hablamos también de otros libros y autores de referencia: el propio Morville y varios de Don Norman.

Actualización del 22 de julio de 2006: para justificar los dos párrafos anteriores nos viene al pelo la reciente anotación de Javier Cañada en la que comenta la importancia del diseño de información con el ejemplo de Hans Rosling y Gapminder. También hay buenos ejemplos sobre el tema en Information aesthetics.

Cuestiones al margen del prototipado

Se comentó la expansión del uso de PowerPoint para presentaciones con gran carga visual (estética) y acabamos derivando en lo inadecuado que resultan las exposiciones y conferencias que se limitan sólo a leer o comentar lo proyectado sin aportar nada más. Citamos la anotación de Luis Villa sobre el @media 2006, en la que alabó a aquellos que en sus ponencias sólo usan las imágenes a modo de apoyo y se centran en contar con sus palabras lo que pretenden.

Enlazando con la exposición de Luis Villa, hablamos de las ideas planteadas sobre la colaboración: todos estamos de acuerdo en que la concepción de desarrollar proyectos en secreto es algo antiguo y muchas veces ineficaz; y que el avance en el desarrollo web (y en la sociedad de la información) sólo se conseguirá a través de la colaboración, de exponer claramente cuáles son las ideas y técnicas con las que se trabaja y debatirlas.

Casi al terminar, comentamos un par de cuestiones sobre las relaciones entre los equipos de desarrollo. Solemos ver con frecuencia empresas en las que todo está bien delimitado; cada sección se dedica a una parte del desarrollo, sin una visión global, o con la visión global de una o dos personas. Coincidimos en que, en la práctica, es difícil separar la arquitectura de la información, el resto de aspectos de contenido, el diseño y la programación, por lo que esa delimitación de tareas, normalmente, ocasiona pérdidas de la calidad del trabajo. En todo caso, volvemos a citar a Eduardo Manchón (se nota que lo tuvimos hace poco en Gran Canaria), quien cree que son necesarias las personas con una visión global del proyecto.