El uso de prototipos y el análisis funcional

Al comenzar a desarrollar un producto, una de los primeros puntos que suele generar cierta ansiedad tanto del lado del equipo como del cliente es la parte visual: cómo se va a visualizar todo el análisis funcional global ¿Cómo se verá cada pantalla del producto?

Al comenzar a desarrollar un producto, una de los primeros puntos que suele generar cierta ansiedad tanto del lado del equipo como del cliente es la parte visual: cómo se va a visualizar todo el análisis funcional global ¿Cómo se verá cada pantalla del producto?

Es muy común que algunos equipos de trabajo involucren al proceso de diseño una vez que toda la parte funcional esté 100% cerrada, incluso en ocasiones habiendo realizado trabajo de desarrollo.

Supongamos que tenemos una pantalla con un formulario. Llegamos a esa pantalla con una User Story relevada en Jira, y su análisis funcional está cerrado. El equipo de desarrollo la tomó, la implementó, pasó por testing y revisión, y se validó con el cliente.

¿Es ahora el mejor momento para enfocarnos en la parte visual?

Definitivamente no. Se pudo haber comenzado a visualizar toda esta información en una etapa previa para evitar re-desarrollo, y es evidente que un equipo de diseño junto con la colaboración del cliente puede proponer nuevos enfoques desde lo visual.

Utilizando Scrum como metodología de trabajo, los requerimientos del proyecto comienzan a bajarse en las ya mencionadas historias de usuario o User Stories. Y un punto importante en el proceso de creación y desarrollo de cada US es poder visualizar todo tipo de análisis, refinamiento e información funcional. 

De palabras a bocetos

Siguiendo el ejemplo mencionado, imaginemos que tenemos una US enfocada en un formulario de registro.

Estando en proceso de creación y refinamiento de esta story, el equipo funcional procede a darle formato en los zapatos del usuario:

—Como “comprador”, quiero “registrarme en el sistema”, para “poder acceder a mi dashboard y empezar a comprar”. —

Teniendo esto definido, comienza el trabajo y refinamiento sobre esta historia.

En este punto, es importantísimo poder involucrar a una persona con perfil de diseño UX para que forme parte del proceso y ayude al equipo a bajar ese análisis funcional del tipo de usuario y todo el contenido que tendrá la vista que se está trabajando, a papel.

Una herramienta excelente para esto punto es Excalidraw, una especie de gran pizarrón digital que no sólo nos permite bocetar rápidamente, sino también hacerlo de forma colaborativa y en la web. No hace falta descargar nada.

En llamados cortos, de entre 25 y 45 minutos, podremos rápidamente empezar a palpar este análisis funcional en una pantalla:

Un boceto o sketch realizado con la herramienta Excalidraw

A estos bocetos, en la jerga de UX, se los conoce como sketches ¿Por qué necesitaríamos a una persona con perfil de UX? Para que aporte una visión a largo plazo desde el sketch pensando en cómo podría ser el diseño de la vista en cuestión el día que tenga una interfaz de alta fidelidad.

De bocetos a wireframes

Habiendo iterado sobre el proceso de sketching dentro de la US, todo el equipo ahora tiene una noción un poco más completa de cómo se verá impactada esa story en el producto.

Como un sketch no es un boceto de alta fidelidad, subiremos un escalón y pasaremos al formato de wireframes.

Un wireframe sigue siendo un boceto en cuestión, pero al trabajarlo en alta fidelidad, nos enfocaremos en hacerlo a tamaño real, con una interfaz lo más acercada a una pantalla con diseño visual, e incorporando las interacciones básicas por las que pasará el usuario:

Los wireframes nos permiten trabajar en alta fidelidad, palpando lo más posible un producto real, pero sin detenernos en el diseño UI.

En un wireframe podemos incluir todos los componentes necesarios: inputs, labels, mensajes de error, botones en distintos formatos, desplegables, placeholders, etc. Y todo esto en un formato que le permita a cualquier persona visualizar una interfaz real.

Pasar de un sketch a mano alzada a un wireframe permitirá al proceso de refinamiento de la US iterar sobre los cambios que se fueron trabajando últimamente. A medida que el análisis funcional de la story avanza, también lo hace su wireframe (o wireframes), y todas las partes del equipo que participen de esta US podrán tener un entendimiento completo, tanto funcional como visual.

Lo positivo de un wireframe es que, usando herramientas como Figma, InVision, o Marvel, entre otras, se puede prototipar. Es decir, darle interacción para simular un producto real, construido. Podemos simular clicks, mensajes de error, apertura de desplegables, y flujos de navegación.

Proceso iterativo sin fin

Teniendo un conjunto de wireframes validados, el proceso puede seguir su curso y se puede continuar pasando de wireframes a diseño UI, con la estética que requiera el producto.

En caso de que el proceso de UI se vea detenido por algún motivo, un wireframe puede ser suficiente como lineamiento base para todo el proyecto.

Lo importante de este proceso es el hecho de que podemos iterar las stories de un proyecto sin limitaciones, y visualizando cada uno de los cambios que se aplican desde lo funcional, en un formato de sketch o wireframe.

¿Qué es lo relevante de todo esto? Que nunca hablamos de desarrollo en todo el proceso. Es decir, hasta ahora el equipo no tocó ni una linea de código.

De esta manera, iterando desde lo funcional y desde lo visual, con permanente colaboración tanto de analistas funcionales, desarrolladores, diseñadores y expertos en el negocio, se puede avanzar en un proyecto en escala, con una agilidad importante que no requiere idas y vueltas entre lo visual y lo funcional, y con una modalidad iterativa que le permite validar el producto tanto al equipo como al cliente.

Tan sólo sumando un pequeño porcentaje de estos conceptos, como el proceso de sketching, podremos no sólo agilizar el proceso sino también optimizarlo, y lograr mejores productos.

Comentario final

Hay situaciones donde es mejor pasar directamente al diseño de alta fidelidad con el cliente final para poder ahorrarse varios pasos con un prototipo de bajo nivel que tal vez pueda terminar de confundir a los futuros usuarios y como un efecto adicional traer ruido a la recopilación de los requerimientos.