Business analyst.
Es el primer contacto con el cliente y su nexo de unión con el equipo de desarrollo. Pensar en diseño UX antes de presentar cualquier proyecto suma un gran valor añadido frente a otros, y ayuda a que éste sea más atractivo. Porque cuando se habla de atractivo, no solo se hace referencia a valores estéticos —que también pueden ser interesantes para el cliente—, sino que hablamos de su usabilidad y puede que en muchos casos de ganar la oportunidad.
Una interfaz de usuario buena (UI, siglas de User Interface) con una experiencia de usuario defectuosa no nos salvará de posibles contratiempos. En cambio, poner el foco en la usabilidad no solo ayudará a la venta, sino que facilitará el trabajo del business analyst.
Steve Krug, en No me hagas pensar apunta que:
No leemos. Solo ojeamos y nos fijamos en lo que buscamos. El resto lo ignoramos.
No averiguamos cómo funcionará algo, simplemente nos lanzamos a ello y vamos avanzando a través del “barro”.
No tomamos la decisión óptima, sino la suficientemente buena. Buscamos satisfacer la necesidad que tenemos y la primera opción que tiene pinta de ser mínimamente válida es la que escogeremos.
Fuente: www.uifrommars.com
El equipo de soporte.
¿Qué ocurre si el usuario final no entiende el uso de la app o la web? Es fácil no contabilizar las horas que invertimos en soporte, incluso pueden parecer efímeras, pero sin el apoyo del UX, la complejidad de las incidencias podría significar que el equipo de soporte necesitaría de un knowledge base acorde con el producto.
Si no podemos mantener este knowledge base, empezamos a crear un flujo de trabajo accidentado. Aquí, y en casi cualquier otra problemática, las 10 Heurísticas de Jakob Nielson nos pueden ayudar; especialmente en este caso la número 6: “Reconocimiento en vez de recordar”. Si podemos conseguir que el usuario sepa en qué punto del proceso está y puede identificarlo, se podrá ofrecer mejor soporte.
Gestión de producción/desarrollo.
Cuando ya hemos llegado al punto en el que nos damos cuenta de que el producto no funciona, no es usable ni amigable para el usuario final —y, por tanto, frustrante para el cliente—, es el momento de actualizarlo. Analizar cuáles son y dónde están los puntos débiles y definir dónde está el código que se tiene que cambiar. Entonces, llega la pregunta: ¿Cómo se pueden integrar estos cambios con lo que ya existe? ¿Pensar en UX habría evitado llegar a esta fase?
Un buen proceso de diseño UX:
Ahorra problemas desde el primer contacto con el cliente.
Ayuda a fijar una hoja de ruta flexible, pero con un propósito bien definido.
Evita elementos innecesarios que han supuesto una inversión de tiempo en el desarrollo y ayudaría a identificar cuáles son aquellos elementos necesarios que faltan por desarrollar.
¿Cómo se puede identificar el gasto de no crear productos desde una perspectiva UX?
Las principales fugas son:
¿Cómo se pueden detectar y corregir estos desajustes?
El libro Lean UX, cómo diseñar grandes productos con equipos Agile de Jeff Gothelf y Josh Seiden, en el capítulo “Visión, marco y resultados”, hace referencia a cómo equipos de producto ponen el foco en funciones, con el énfasis en los requerimientos e implementaciones y plantean un escenario alternativo:
«Lean UX cambia por completo nuestro marco de trabajo al reintroducir el contexto estratégico para las elecciones que hacemos sobre las funciones y diseño, y aún más importante como nosotros –el equipo entero, no solo el equipo de diseño– definen el éxito. Nuestro objetivo no será crear un documento entregable o función, sino cambiar algo en el mundo real, es decir, producir un resultado».
