Cuando vas a realizar un proyecto de desarrollo de una aplicación informática, seguramente te aparezca la fase de análisis funcional. Si, esa fase en la que, sobretodo los clientes, ven grandes esfuerzos, poco retorno y, por tanto, sumamente cara.

¿Sabes que enfocar el proyecto desde el punto de vista de la experiencia de usuario puede hacer cambiar esa concepción?

La forma tradicional de desarrollar un sistema software era (y aún hoy me lo encuentro) por fases: primero una definición del alcance a grandes rasgos y luego una definición funcional con sus casos de uso, diagramas de las operaciones, diseño de pantallas, etc. Con la definición funcional pasabas al diseño técnico y al desarrollo.

La fase de análisis funcional era larga y árdua, porque se generaban documentos amplios con especificaciones difíciles de seguir y tener en mente, para hacerte una idea de lo que realmente acababa siendo el sistema. En mi artículo Documentación ágil hablo más sobre el tema de la documentación ardua y caduca. Y la mejor de las veces, el sistema respondía a nivel de formularios e interacción de pantallas pero no ayudaba a los usuarios en su flujo diario de actividades.

Pero estamos de suerte. Desde hace un tiempo ya existe en el mercado ( y por suerte en auge ) profesionales que desarrollan experiencias de usuario que facilitan el entendimiento y uso de las aplicaciones (entre otros sistemas). El desarrollo de una aplicación desde el punto de vista de la experiencia de usuario nos permite desarrollar aplicaciones centradas en el usuario.

Te recomiendo el artículo User eXperience para conocer desde un punto de vista teórico que es la experiencia de usuario y tener buenas referencias a tener en cuenta.

¿Qué me permite un abordaje desde el UX?

Cuando desarrollamos una aplicación centrada en el usuario nos ponemos en sus botas y damos respuesta tecnológica a sus necesidades más inmediatas, de forma que no pierde productividad ni efectividad en el uso de la herramienta. Esto se produce porque toda decisión de diseño se ha tomado de forma justificada contra un arquetipo de persona. Este arquetipo responde a un grupo de usuarios finales.

La ventaja versus al análisis funcional tradicional es que realizamos conjuntamente con el cliente y los usuarios una etapa de descubrimiento de las funcionalidades según escenarios de uso reales de cada usuario.

Esto significa que no es reunión tras reunión entrevistándonos y realizando anotaciones, actas y desarrollando documentación. Es reunión tras reunión trabajando en equipo sobre un modelo visual e inteligible y pivotable por todas las partes.

De los proyectos realizados y en curso, este planteamiento lleva a conclusiones lógicas pero que cogen relevancia en el momento en el que el cliente acaba afirmando por si solo que:

  • Es mucho más fácil poder entender la aplicación informática que se está desarrollando cuando estás viendo el esquema de la pantalla y puedes interactuar con él (digital o analógicamente).
  • Es mucho más fácil entender la justificación del diseño de una pantalla cuando has representado y escogido a un arquetipo de persona y has dibujado su día a día.
  • Es más motivante enfrentarte a un prototipo y “jugar con él” para validar el comportamiento de la aplicación que leer cientos de páginas y tener que saltar entre ellas para entender el hilo conductor de cómo funcionará la aplicación.
  • Requiere mucho menos tiempo trazar una imagen con cuatro textos en tiempo real que describir el funcionamiento y dejarlo por escrito.

Al trabajar conjuntamente de esta forma, durante los periodos (o sprints) de realización del diseño de la UX, el valor proporcionado y percibido es mucho mayor, porque se visualizan los avances en tiempo real y porque tienes alineados a todo el equipo y las expectativas sobre lo que es el sistema. También te avanzo que queda claro lo que no será (seguramente por tema de alcance de proyecto, costes o tiempo) y, mal gestionado, puede generar frustración.

La experiencia que tengo hasta el momento es que es mucho mejor, pero no hay que engañarnos porque sorpresas y cambios siempre existen. Y es que los procesos de trabajo de un departamento de empresa, equipo, sistema, etc. no siempre son tan claros como se presuponen y de ello te das cuenta cuando corres dentro del proyecto. Pero encontrar todo ello en este momento es mucho más barato que encontrartelo en tiempo de programación. ¿No crees?

Si estás trabajando en una aplicación que requiere un análisis profundo, desde el punto de vista de la UX también lo puedes hacer. No es que sustituyas uno por el otro, sino que el análisis lo haces desde otro paradigma, pero el resultado que generas debe ser el mismo a nivel práctico que el análisis funcional: debe describir el funcionamiento de la aplicación y debe estar suficientemente documentado (sin los aspectos técnicos) para desarrollar el prototipo final correspondiente.

¿Y tú qué dices?

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.