En la pasada edición de Lean IT Summit celebrada en París (Francia) tuvimos la oportunidad de hablar con Jeff Gothelf, uno de los máximos exponentes cuando se habla de agile UX y lean UX. Durante nuestro encuentro charlamos con Jeff sobre el diseño y desarrollo de productos software, el necesario trabajo con hipótesis como base para llegar a ofrecer valor al cliente o el necesario cambio de modelo que deben poner en marchas las empresas para adaptarse a este nuevo contexto.
Antonio Medina | @amedinadiaz

Nos acercamos a Jeff Gothelf y constatamos que es un hombre amable, que acepta, a pesar del cansancio de un largo viaje, sen­tarse con nosotros unos minutos. Un tipo con ideas claras. Pero no ideas fáciles de entender para muchas organizaciones que no están dispuestas a acometer riesgos, por pequeños que sean, para adaptarse a una demanda crecientemente más exigente en time to market y en respuesta a unas necesidades cambiantes.

Y esas ideas se podrían resumir en que un gran diseño hace que un proyecto tenga éxito o no. Así de sencillo. Y que este principio tam­bién puede, y debe, funcionar en un mundo cada vez más agile.

El año pasado Jeff fue uno de los autores que introdujo esta idea, junto con otras en la misma línea, en el libro lean UX: Cómo aplicar principios de lean para mejorar la experiencia de usuario.

“Los diseñadores ya no pueden permitirse el lujo de tener tres o cuatro meses para diseñar algo en el mundo del software. Eso se ha acabado desde que se introdujo agile”, comenta Jeff. Entonces, ¿cómo se puede conseguir un diseño con sentido cuando la mayor parte del tiempo se trabajar bajo el desconocimiento de cómo será el producto final? Utilizando de forma racional los principios de lean UX, que se basan en centrarse en el usuario en todo momento y en asegurarse de que es el foco del diseño, estableciendo un en­torno colaborativo amplio y transversal, juntando a diseñadores, ingenieros y product managers desde la etapa de descubrimiento del producto y no sólo en la entrega.

Pero, especialmente, implica cambiar el chip y afrontar la reali­dad: “Cuando se desarrolla un producto de software, se trabaja so­bre una conjetura, una hipótesis, aunque esta esté bien formulada y estructurada y, por lo tanto, hay que evitar emplear mucho empeño en desarrollar algo”. El objetivo, según Jeff, debería ser justo el con­trario, “conseguir, con el menor esfuerzo posible, descubrir si esta­mos trabajando en la línea correcta o, al revés, si nuestro trabajo no es lo que busca nuestro usuario y por lo tanto debemos aprender del feedback recibido y reajustar nuestro producto”.