Hace unos días escribí acerca de los wireframes y la necesidad de reducir la documentación en los proyectos de UX. Y aunque me concentré en hablar de los wireframes, no se trata de condenarlos al olvido ni de negar su utilidad. De lo que se trata es de optimizar los procesos de trabajo y mejorar la comunicación entre equipos.

El problema es el siguiente: los wireframes documentan un sistema interactivo o de información en un momento determinado. E incluso en un estado determinado.

Un momento porque los wireframes son la foto de una etapa en el desarrollo del sistema. Pero sabemos que los sistemas son dinámicos y evolucionan permanentemente. La documentación que los describe, del mismo modo,  debe ser actualizada o queda obsoleta. Esto es un esfuerzo que, con el dinamismo que se requiere cada vez más, se hace difícil.

Además, los wireframes sólo son capaces de representar un estado de una interfaz a la vez. Pero también sabemos que los sitios y aplicaciones tienen muchos estados diferentes.

Así, los wireframes no son capaces de evolucionar junto a los sistemas que documentan, ni son capaces de representar todos sus estados. Por lo mismo, no siempre son efectivos en su resultado —documentar y comunicar un sistema— o eficientes en su ejecución —considerando el tiempo y esfuerzo que requieren.

Otro aspecto del problema, es que en un proyecto interactúan diferentes equipos, con objetivos y necesidades particulares. La comunicación entre ellos y la forma en que ésta se produce, varían según la relación que tengan los equipos y la naturaleza de los proyectos.

¿Cuáles son las alternativas?

Las opciones son varias, pero existen diferentes escenarios:

• Escenario 1: si un equipo incluye tanto a investigadores, como a diseñadores de experiencia y a desarrolladores —el escenario ideal—, lo mejor es realizar bocetos rápidos, prototipar, evaluar con usuarios y pasar rápido a desarrollar. Y evaluar con usuarios nuevamente.
• Escenario 2: si los equipos de diseño de experiencia de usuario (UX) y desarrollo son áreas distintas de la organización, se deberá documentar más. El equipo de desarrollo necesita precisiones; el de UX necesita respaldos de lo que ha definido. Aún así, se pueden documentar muchos aspectos en prototipos complementados con flujos de interacción, y sólo cuando sea necesario, wireframes. Pero el propósito será pasar lo más rápidamente posible a desarrollo.
• Escenario 3: si el equipo de desarrollo y el de UX corresponden a empresas diferentes colaborando en un mismo proyecto, se hará necesaria documentación más detallada. En este caso, los prototipos documentados y los wireframes serán centrales. Deberán sustentar las definiciones de UX cuando el equipo no esté presente. Y tendrán que ser precisos para facilitar el desarrollo.

Por sobre todas estas consideraciones y escenarios, debemos tener presente que el tiempo disponible para los proyectos es reducido y en muchos casos la competencia y la carrera por el time-to-market son críticos. Con lo cual debemos calibrar todos los aspectos para asegurar un diseño de UX y un desarrollo fluido.

Otra forma de reducir tiempos, costos y esfuerzos, es pasar rápidamente desde el prototipado al desarrollo. En lo posible, prototipar en herramientas lo más cercanas al lenguaje final: HTML, CSS, JavaScript en el caso del web. La idea de generar prototipos detallados, con herramientas especializadas (como Axure, InVision, etc.), que luego deberán ser reconstruidos durante el desarrollo, parece superflua en la mayoría de los casos. Gastar recursos en aprender los trucos de las herramientas de prototipado, que luego serán desechados, no parece una forma eficiente de avanzar.

En conclusión, tenemos muchas herramientas de definición y comunicación a nuestra disposición, sólo debemos saber cuándo usarlas para beneficio de cada proyecto.