¿Por qué insisto tanto con los prototipos?

Me fastidia un poco que el título del post sea una pregunta. No lo puedo evitar. Pero es bien cierto que me resulta imposible -lo reconozco- escribirlo de otra manera. Os cuento.

Hace ya tiempo empecé a escribir cositas al respecto de una cosa llamada wireframes. ¿Os acordáis?

• La importancia de los wireframes
• El zen de los wireframes
• Wireframes: recopilación de enlaces
• Narrativa de wireframes guiados
• El proceso de arquitectura de información (II) y el III y el IV
• Creación de prototipos con Omnigraffle
• Entregables tras un proceso de arquitectura de información
• Prototipando sitios dinámicos

También hemos hablado en el blog sobre prototipos:

• Herramientas para hacer prototipos en 2021
• Prototipos y wireframes en proyectos de UX
• Wireframes y prototipos
• Herramientas online para hacer prototipos

Bueno, pues no es ningún capricho. En el proceso de trabajo que existe en todo proyecto web hay un tema que subyace y fluye en todo el recorrido: creación de un producto final. O lo que otros llaman cierre de proyecto.

Luis Villa escribió un día un post interesantísimo, al hilo de un debate no menos sabroso que tuvimos Alberto Knapp y yo mismo. Knapp hablaba de Proceso Vs. Producto. Este que escribe habló de metodología, proceso y producto. Luis Villa, genial como siempre, se descolgó con Proceso vs. producto o cómo estrellar un proyecto por culpa de 37 Signals.

En el fondo de todo ese debate, que nunca debería pasar inadvertido en cualquier factoría que trabaje para la web, se esconde desde mi punto de vista una dicotomía. Y es, me temo, la hora de poner nombre a las criaturas. Esta dicotomía es la que está detrás del desarrollo de software tradicional, frente al desarrollo de producto o nueva metodología de trabajo que tiene como guía de referencia al usuario.

Si bien es cierto, que lo es, que la tesis que mantengo en metodología, proceso y producto se apoya en el seguimiento de una metodología de trabajo como factor asegurador del éxito de los proyectos, sería de estúpidos pensar que, cual dogma de fe, ésta va a solucionar todos los males, presentes y futuros. Matizo sin ambages: sería de auténticos necios pensar que ésta va a solucionar los problemas futuros.

Pues bien, la cuestión es que mientras que esa metodología tradicional, que yo llamo ‘de desarrollo de software’, se apoya en una colección de entregables que adquieren el nombre de cada una de las fases que le dan sentido (requerimientos, análisis, implementación, producto), el hecho de tomar al usuario como centro y pivote de todas y cada una de las tareas que se realizan en el ciclo de vida de un proyecto, implica necesariamente la irrupción con fortaleza, seguridad y fiabilidad del prototipado. De principio a fin. Sin traumas, sin complejos y sin ambigüedades. Y todo lo que sea perder de vista al usuario, encarnado en esa cosa llamada prototipo, wireframe, mockup, etc., está casi condenada a tres posibilidades:

• el fracaso, en forma de exuberante e intachable despliegue técnico, que el usuario no comprende
• el fracaso, en forma de impresentable chapuza técnica, apaños mil; en resumen, una colección de parches
• el fracaso, en forma de producto que nadie utiliza porque no está alineado con las expectativas del usuario

El panorama es desolador con esta luz. O al menos es lo que el tiempo y los golpes me han hecho ver.

Por otra parte, una metodología presidida en todo momento por un pensamiento constante en el usuario, izadas las velas de los wireframes, prototipos o mockups durante todo el trayecto, garantiza por lo menos -que no es poco- dos cosas:

• el usuario conoce desde el primer día su producto, frente a la rigidez de una generosa colección de documentos en negro sobre blanco que nadie entiende pero que son condición sine qua non para seguir adelante
• el equipo de trabajo habla el mismo idioma que el usuario, con lo que la comunicación adquiere su pleno sentido, mención aparte de la carga de motivación que ese feedback supone en un equipo

De todo ello, no me queda sino concluir con las más importantes de todas las ventajas, bondades o beneficios que se le puedan atribuir al diseño centrado en el usuario, que es de lo que estoy hablando: el impacto terriblemente positivo que tiene este modus operandi en la calidad del producto final, el negocio subyacente y, cómo no, la motivación y sinergias positivas que se desprenden, en pro del equipo de trabajo.

Esta reflexión se la debo, aunque él no lo sepa, a Luis Villa, que ha acertado a tocar la tecla que me ha permitido componer una melodía que hace tiempo venía tarareando, pero que no se decidía a salir.

Nunca es tarde.

Artículo actualizado en marzo 2022.