4

Soluciones ineficaces para problemas inexistentes

UX


Sucede a menudo que en un entorno de desarrollo vamos desvariando el camino hacia lugares donde no hay vuelta atrás, se hace tan grande la bola de nieve de producir y producir que con frecuencia muchas de esas producciones o bien quedan en módulos técnicamente impecables almacenados en la alacena del olvido o bien se trunca su finalización por más nieve que se suma a la ya enorme pelota que hemos ido creando.

Happy Ideas es lo que yo llamaría al equivalente del Happy Text cuando se hace copy para un website, rellenar por rellenar contenido inservible e irrelevante. Estas Happy Ideas o ideas felices surgen del equipo de desarrollo con una frecuencia sorprendente basadas en la “intuición” del jefe de proyectos, del director de desarrollo, del diseñador visual, del desarrollador junior o del dueño del circo o de cualquier miembro con voz. A veces la opinión de un representante en una posición jerárquica superior se vuelve ley y sus ideas trabajo a hacer, entonces, cada parte del puzzle se limita a poner las piezas que le piden sin preguntarse “¿qué estoy haciendo?” sintiéndose ajeno o mejor dicho, no sintiéndose “parte” del diseño de un producto. Es más, sea cual fuese su posición y rol en la empresa estoy segurísimo que trabajará amargado pensando incluso “mi jefe no tiene ni p*ta idea de lo que se tendría que hacer”, el diseñador estará con la crisma a punto de reventar porque su opinión no vale y le hacen crear maquetas gráficas tras maquetas gráficas que al final no son tomadas en cuenta y bueno el jefe de proyecto queda a punto de tirar la toalla porque no se cumple con la idea que necesitaba.

Las Happy Ideas entonces son dañinas, porque crean soluciones ineficaces para problemas inexistentes

Creemos que construimos lo que le hace falta al usuario cuando lo que estamos desarrollando es producto para nosotros mismos, nuestros propios gustos e intereses los vertimos al trabajo que nos piden porque nos lo piden por separado y nos llenamos de montones de soluciones para necesidades inexistentes. Pasa por ejemplo que cuando se pregunta el porqué de una acción a llevar a cabo ni el desarrollador lo sabe explicar bien cuando se le pregunta: ¿la solución que has desarrollado, realmente soluciona algún problema que existía? ¿en qué hemos basado esta solución? ¿que fundamentación es la que puedes ofrecer para esta tarea? ¿hay al menos un feedback de los usuarios? ¿que investigación es la que sustenta este sprint?… aunque no me lo crean una de las respuestas que he sido testigo de oír es: Porque se nos ha ocurrido.

Working responsibly

¿Cuál debería ser el proceso entonces?, pues eso, trabajar de manera responsable, ni el diseñador debe ir a mostrar en la empresa su arte, ni el desarrollador es un autómata que solo va a hacer lo que le piden ni el jefe de proyecto o negocio idea soluciones que nadie las ha pedido porque no existía ningún problema que solucionar para “una rueda que ya estaba inventada”, esa “rueda” podemos mejorarla conociendo las necesidades reales de los usuarios pero si conocemos a los usuarios. Si no, pues estamos solamente creando producto por crear, que, lo dicho al inicio, igual no sirva para nada. Quizás el ejemplo más claro de una enorme Happy Idea es la de Google Wave, ustedes, ¿qué opinan?

I+D+i

Pero hay una luz sobre las Happy Ideas, no son tan terribles en verdad, tienen algo de bueno en ellas y un lugar donde estar felices: en la investigación y desarrollo e innovación, donde pequeños grupos de trabajo pueden realizar los labs pero basándose en argumentos que sustenten sus experimentos y con algo que a veces falta: sentido común.


Foto por:[phil h] via Compfight cc

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273