Apuntes varios sobre prototipado

Siempre me ha interesado el prototipado como una forma de plasmar la organización de la información. Cuando todavía no lo practicaba, ya investigaba y participaba en reuniones al respecto. Qué lejano lo veo, y qué atrevido era hablando desde el desconocimiento.

Ahora llevo seis meses en Usolab practicando esta técnica, la más ejercitada por los profesionales del área de Experiencia de Usuario en España, la principal habilidad necesaria para quienes trabajan en el sector según Jared Spool y una práctica totalmente olvidada en el Máster en Interacción Persona Ordenador de la Universitat de Lleida. Así que del contacto casi diario con los wireframes y del reciente webinar de Perficient que seguí he extraído algunas conclusiones (más bien rápidas y simplonas para quienes la usan habitualmente, pero que hubiesen sido interesantes para mí antes de febrero).

La importancia (y elegancia) del gris

El uso de colores distrae del objetivo principal del documento en las etapas tempranas del prototipado, cuando son de baja y/o media fidelidad. Saber jugar con las tonalidades de grises para resaltar o atenuar la importancia de los bloques de información es fundamental. Los shades of gray mostrado en UX Magazine son ejemplos de buenas prácticas en este sentido.

Prototipos frente a arquitectura de información

Estoy convencido, como digo, de que prototipar es lo que más tiempo hacen los profesionales de departamentos de experiencia de usuario. No sé cómo era la práctica profesional hace seis u ocho años, pero supongo que había más trabajo en la definición de la arquitectura de información (AI). Creo que en la actualidad, por la importancia de los buscadores, en la mayoría de casos de trabajos para la web -sobre todo en sitios comerciales- el trabajo de prototipar es mucho más importante, porque las páginas fundamentales van a tener más visitas a través de buscadores que desde dentro del sitio. La AI sigue teniendo mucha relevancia, pero, quizá, a un nivel jerárquicamente superior que al planteado en los manuales clásicos, incorporando la capacidad de ser encontrado a través de buscadores y de orientar a los usuarios una vez entran en el sitio a través de páginas que no son la de inicio.

Prototipos como documentos de recogida de requisitos

Un punto tratado en el webinar de Perficient es la capacidad de los prototipos de servir como documento de requisitos. De mi trabajo en IT7 aprendí, sobre todo, la ineficacia de los documentos de texto que sirven para recoger esos requisitos. Los clientes no saben verbalizar lo que necesitan, no tienen capacidad de abstracción para entender lo que escriben los equipos de desarrollo y no tienen paciencia ni interés en revisar documentos que para ellos son obvios. Por ello, infinidad de veces ocurre que cuestiones que parecían completamente aclaradas vuelven a ser tema de debate y hay que tirar a la basura todo el trabajo de definición previo.

Ahora creo que uno de los grandes errores que cometimos era no entregar siempre los prototipos, porque estoy convencido que con una definición visual aceptable (quiero decir, entregando wireframes decentes y no bocetos) hubiesen atraído más la atención de los clientes que los extensos documentos de texto. Éstos no sirven como herramienta de comunicación, mientras que los prototipos, sí. O quizá sea que me voy a costumbrando al nivel de los clientes de Barcelona, no sé.

Piensa primero, dibuja después

Me gustó una frase del seminario online: “Don´t start building things if you should be chewing it” (repetición aproximada; quiere decir algo así como “No empieces a construir algo si todavía tienes que estar masticándolo”). Es algo que todavía me ocurre: primer dibujo con bolígrafo y cuando tengo una idea aproximada, me pongo con el Axure. Pero en muchas ocasiones, por no pensar más tiempo o buscar más ejemplos en la competencia, me quedo en la superficie y propongo soluciones demasiado fáciles, demasiado previsibles que frecuentemente no solucionan el problema que se quiere arreglar. Esto también se mejora con la práctica, estoy convencido.

Pensando más allá de las cajitas grises

Como digo en el anterior punto, todavía a veces hago más trabajo manual que cerebral, pero voy solucionándolo. Aunque pensar las soluciones es mucho más difícil y requiere más experiencia, me parece importante haber avanzado en el manejo de herramientas y patrones para ejecutar esas ideas. Tengo claro que el trabajo en experiencia de usuario es mucho más amplio que dibujar cajitas grises, pero por el momento estoy contento de estar aprendiendo a hacerlas.