UX diseño centrado en el usuario

El principio del aprecio masivo, según Colborne, proviene de dirigirse precisamente a eso, a las masas. Y las masas persiguen algo simple, sencillo, pero enormemente útil. Y es ahí donde radica el reto. En un mundo, como el de el diseño de UX, en donde la palabra “complejidad” es el anatema a batir, Giles Colborne, reputado especialista británico en el diseño centrado en el usuario, escribió hará un par de años una de las obras más deliciosas al respecto, utilizando como axioma un mando a distancia plagado de botones y cuatro estrategias para mejorar la experiencia de su uso: Eliminar, organizar, esconder o desplazar.

Me interesan enormemente los procesos y los procedimientos. Ello no significa que no sea dada a improvisar, pero es necesario converger en una metodología formal a la hora de construir un proyecto para entender, sobre todo, qué hacer a cada momento.

Esto es especialmente relevante cuando se trabaja en equipo y, aún más, cuando dicho equipo opera en un contexto Agile. El proceso sirve a los miembros del equipo, en conjunto o de forma individual, como respuesta conveniente ante la cuestión sobre qué hacer a continuación. Y eso salvando la diferencia de perfiles (diseñadores visuales, de interacción, programadores frontend, backend, etc) y de estilos (ya seas un jugador de equipo o, desgraciadamente, un llanero solitario).

Pero, ¿significa eso que los procesos deben ser inmutables en la medida de lo posible? No. Por favor, NO. Yo misma he sido testigo en los dos últimos años de cómo ha mutado en PornTube.com nuestra metodología SCRUM con sucesivos cambios de workflow, incluyendo experimentaciones  fallidas en ocasiones. Al final, el resultado de dicha evolución ha sido, en líneas generales, siempre positivo.

  Créditos: Dennis Kardys - WSOL.com

Créditos: Dennis Kardys - WSOL.com

Centrándonos en el diseño, en los dos últimos años hemos pasado de redactar inacabables especificaciones técnicas de flujo de usuario a abocetar aplicaciones en programas de wireframing y lanzarlas de inmediato, puliéndolas incrementalmente en sucesivas iteraciones. Y todo ello con el fantasma del Agile Waterfall pendiendo sobre nuestras cabezas. La calidad de los proyectos no ha cambiado un ápice, pero sí el tiempo necesario para desplegar una aplicación o hacerla del todo eficiente.

Dicho esto, ¿por qué no seguir experimentando? Después de las vacaciones de Navidad obtuve luz verde para desplegar la que será la nueva web app de PornTube.com para iPad, idea que me rondaba la cabeza tras contemplar el éxito de nuestras aplicaciones para smartphones. Dado que nuestro equipo de ingeniería estaba concentrado en aquel momento en otras tareas más perentorias, nos saltamos nuestro flujo SCRUM habitual y trabajamos en paralelo. Al final de dos semanas, habíamos completado un proceso integral de planificación, wireframing, prototipado interactivo y despliegue de UI en HTML5, CSS3 y JavaScript. Para ello, utilizamos data-fixtures y un generador de mock-data reutlizable, lo que nos permitió concentrarnos en experimentar con diferentes patrones de interacción y gestuales, así como dar pasos adelante y atrás en el proceso, sin sentir el aliento de los programadores backend en la nuca. 

En circunstancias normales, este flujo de trabajo se desaconseja en cualquier equipo Agile, pero en esta ocasión el resultado final fue enormemente positivo y satisfactorio, sobre todo porque pudimos concentrarnos más en el diseño de experiencia de usuario que en el early delivery.

En estos momentos, la aplicación, lista en términos de UX/UI para un primer release, está siendo integrada por nuestros desarrolladores del lado del servidor y verá la luz en breve. Mientras tanto, esta experiencia me ha hecho reflexionar sobre cómo operar la próxima vez que debamos afrontar la confección de un proyecto completo: ¿Discurrir en paralelo e integrarlo todo basándonos en APIs? ¿Integrarlo todo linealmente? ¿Seguir atomizando el desarrollo en pequeñas iteraciones e ir acrecentando las aplicaciones con el tiempo? No encuentro una respuesta, porque cada caso exige una aproximación diferente.

Sin embargo, Marzo trajo consigo una lectura deliciosa de la que he extraído la cita que introduce este post, y cuya lectura os recomiendo, para que veáis como, en el nuevo escenario de las aplicaciones adaptivas y el desarrollo orientado a plataformas móviles, es necesario redefinir nuestros flujo de trabajo para no tener que volver atrás constantemente al confrontar el resultado de nuestro trabajo con las expectativas de nuestros clientes sin por ello comprometer la calidad del mismo.

Lectura imprescindible: A More Flexible Workflow, de Dennis Kardys.