04 julio 2007

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?

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 ambajes: 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 exhuberante 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.

Comentarios

  1. Algo que yo he intentado siempre completar en todo proyecto mediano a grande es hacer un post-mortem despues del proyecto.

    Creo que el concepto de post-mortem en los proyectos no se usa tanto como se debiera y despues no se reconoce que hubiera ahorrado problemas.

    Un post-mortem no es sino un analisis de como fue el proyecto, que se hizo bien, que se hizo mal y que se aprendio. No sobre el tema del proyecto especifico sino sobre el proyecto como tal.

    Gracias a post-mortems (que te obligan a analizar la vida del proyecto con el beneficio de la retrospectiva) hemos encontrado docenas de puntos debiles que afectaban al proyecto. Retrasos, malas decisiones, malas herramientas y elementos (gente) que trababa mas que facilitar.

    Lo que pones por aqui es la documentacion del proyecto de cara a su usuario final (o al cliente, dependiendo). Lo que yo pongo aqui es la documentacion del proyecto de cara a los que lo han hecho, sin importar el tema del mismo. Es una bitacora de la experiencia.

    Gracias a post-mortems yo he logrado aislar procesos defectuosos, vicios y he logrado justificar tomar caminos diferentes a los tradicionales.

    PD: Cada vez que cargo esta pagina, invariablemente, me salta un error que me cambia la pestaña del navegador y me blipa y me congela la pagina hasta que le doy a OK. El error esta relacionado con coloriuris. Es una alerta de js diciendo que http://www.coloriuris.net ha enviado un mensaje inesperado o incorrecto. Es MUY molesto. Puede ser porque accedo por proxy (no recuerdo que en casa me suceda) pero congela la carga de esta pagina y de todas las demas pestañas (viva JS y la comunicacion modal)

  2. En base a tu artículo me he animado a hablar un poco de mi corta experiencia en la creación de prototipos y de algunas ventajas que nos aportan.

    Por resumir: Los prototipos como parte de una metodología ágil de desarrollo son una de las mejores formas de involucrar tanto al cliente como al equipo de desarrollo en un producto centrado en el usuario.

    Como siempre un genial post para aprender un poco más. Muchas gracias y enhorabuena por ese Pagerank 7.

  3. Qué tendrá Luis Villa, que no sólo sabe mucho, sino que inspira a que aprendamos más…
    Como una especie de “mea culpa” hay que pensar menos en la tecnología, y más en las personas…

  4. […] del conflicto entre desarrollo ágil y diseño centrado en el usuario. Y no será porque aquí no me haya mojado más de una vez con el tema, […]

  5. […] que permiten crear fácilmente una maqueta interactiva de tu proyecto digital, con el objetivo de identificar cualquier deficiencia en el diseño, el flujo y la interacción del diseño antes de que sea demasiado […]

  6. […] sabéis que en el estudio somos partidarios de introducir un proceso de prototipado rápido en el diseño de pro…, tras una buena investigación de […]

En Torresburriel Estudio trabajamos los procesos de diseño de producto digital para lograr los objetivos definidos junto con nuestros clientes.