Diseño UX para potenciar el software
Trabajo diseñando interfaces dentro del mundo digital hace ya casi 8 años. Al principio como freelancer y después como socio de una cooperativa de desarrollo de software a medida. Siempre necesité estar cerca de los desarrolladores.
¿Por qué?
Básicamente cuando los clientes tienen una idea y sienten la necesidad de resolverla a través del software, siempre recurren en primera instancia a una software factory. Incluso cuando la idea está apenas pensada o solamente bajada a un word con “puntos clave” necesarios para la plataforma. En mis años de experiencia vi que esos documentos (mientras más extensos peor) eran muy confusos para el equipo de desarrollo. Contenían un montón de detalles donde no estaban claros los objetivos y no respondían a preguntas básicas como qué, por qué y para quién. Además, el cliente quería empezar cuanto antes y que se demore lo menos posible. En muchos casos llegué a involucrarme en proyectos diseñando pantallas al mismo tiempo que estábamos desarrollando. ¡ERROR!
En arquitectura, por ejemplo, existen un montón de etapas previas a la construcción: se bocetan croquis desde distintos ángulos con el objetivo de tener una perspectiva “sensorial” y así poder entender la integración del espacio con el “usuario” (hola UX). Luego se confeccionan los planos que proporcionan información más técnica, vital para la construcción.
Relevar, bocetar, dibujar, prototipar son todos procesos que ayudan a estudiar detenidamente lo que vamos a hacer antes de hacerlo. Son etapas fundamentales de toda actividad proyectual y el desarrollo de software es una actividad proyectual, entonces… ¿Por qué no lo hacemos? ¿Por qué construiríamos una casa sin planos?
Evitar estos procesos en el desarrollo de una app no va a reducir costos, si no todo lo contrario. Se pueden usar y combinar para todo tipo de proyecto, se trate de una mega empresa o una pequeña pyme.
¡Perfecto! Pero… ¿Cómo lo hacemos?
Para eso tenemos que hablar de “Design Thinking”. Es una metodología que se apoya en herramientas y técnicas que potencian la creatividad y nos aportan datos claves para el éxito del proyecto. Una característica fundamental del “Design Thinking” es que está centrada en el usuario y en los problemas que se le pueden plantear.
Estos son los mandamientos claves:
Las técnicas que se utilizan van cambiando y evolucionando constantemente, pero me gustaría repasar algunas de las más útiles, sobre todo, pensando en los proyectos más simples.
User persona
Esta es una pieza clave en el proceso de diseño que trabaja la empatía. Se trata de nuestro usuario, es decir para quien estamos creando la experiencia. Tiene el formato de una ficha creada a partir de una investigación que sirve para identificar los diferentes tipos de usuarios que podrían usar nuestro sistema.
La idea es reconocer sus características a traves de entrevistas a usuarios y agruparlas en perfiles de personas imaginarias, a las que le vamos a poner un nombre y apellido ficticio y en quienes vamos estar pensando durante todo el proceso de diseño.
Esta técnica es muy adaptable a la escala del proyecto, pero recomiendo mucho que se haga independientemente de nuestros recursos. Claramente es mejor hacer muchas entrevistas, pero todos sabemos el tiempo que eso lleva, y a veces el proyecto podría estar en una etapa muy temprana como para hacer una inversión tan grande. En esos casos podríamos armar un “user persona” a partir de una reunión (o varias) entre el porduct owner y el resto del equipo, construyendo entre todos ese perfil (o perfiles). Más adelante, con el proyecto más avanzado y validado, siempre podemos volver a hacerlo mejor para ser más precisos ante nuevas funcionalidades o rediseños.
Benchmark
Hacer un benchmark puede que sea una de las cosas más baratas y fundamentales del proceso. No se justifica en ningún caso que un equipo no lo realice. Se trata de “chusmear” cómo resuelven otros sistemas las mismas funcionalidades que tenemos que diseñar. Es un relevamiento, navegar otros sistemas, sacar “prints de pantalla” y tomar notas de cómo fue esa experiencia. Es clave estudiar nuestra experiencia para no repetir errores y para apoyarnos en lo que está bien hecho. En proyectos que recién inician no tiene sentido invertir recursos en reinventar soluciones. No re-inventemos la rueda.
Flowcharts
Quiero aclarar que, hasta ahora, las técnicas que vengo describiendo no son nada exclusivas del mundo del diseño gráfico. Cualquier persona del equipo puede ponerlas en práctica, inclusive un “flowchart”.
Se trata de realizar un diagrama con figuras que describen el flujo del usuario a través de cierta funcionalidad. Estas figuras son diferentes entre sí y describen acciones del usuario, “vistas” (pantallas o “momentos” visuales específicos de nuestra app) y decisiones del sistema. De esta manera, ya podemos pensar y bajar ideas sobre distintas interacciones, ver qué tan extensas o cortas pueden ser, cuántas views vamos a necesitar, etc.
Bocetos (baja, media, alta)
A partir de los flowcharts ya tenemos una idea de cómo va a ser el flujo, entonces podemos pasar a bocetar las “vistas”. La idea es empezar en “baja”, esto significa que el boceto esté “dibujado” con elementos simples, que den una idea de estructura y del posicionamiento de los componentes. De esta manera podemos validar aspectos generales del flujo, como cantidad de botones, el largo de ciertos mensajes, el tamaño que le vamos a dar a las imágenes, elementos de navegación, etc. Incluso ya con los bocetos en baja podríamos crear prototipos y testearlos (de eso voy a hablar mas adelante).
Podemos ir sumándole fidelidad a esos bocetos a medida que vamos validándolos. Existe el concepto de “media” donde ya incluímos elementos del diseño final, como estilos tipográficos, colores, etc. A eso le podemos agregar personalidad hasta llegar a los bocetos en “alta”, los cuales serán utilizados por un desarrollador frontend para crear los distintos componentes.
Recordemos que mientras estemos validando distintas opciones y flujos, no es necesario que invirtamos tiempo en pasarlos a “alta”.
Prototipos
“Son una implementación parcial pero concreta de un sistema o una parte del mismo.” Hoy en día existen varias aplicaciones que nos permiten utilizar nuestros bocetos digitales (en baja o alta) y transformarlos en prototipos navegables. Sería muy complicado hacerlo con el sistema completo, ya que hay estados, reacciones y condicionales difíciles de replicar. Lo mejor es prototipar flujos específicos, desde donde inician hasta donde se resuelven.
Testeos
Esta es una etapa fundamental para validar nuestro diseño. Podemos acercarle un prototipo a alguien que consideremos un posible usuario para ver cómo se desenvuelve. Es importante que mientras estemos observando no emitamos comentarios ni intentemos vender nuestro diseño, si no que tengamos una mente abierta y preguntemos al usuario en qué está pensando o qué está sintiendo. También sirve mucho anotar todas nuestra observaciones.
Se puede volver costoso todo el proceso de seleccionar y reclutar los usuarios para testear, por lo tanto pensemos bien qué flujos nos conviene testear o en cuáles tenemos más dudas sobre cómo reaccionaría el usuario. Incluso, si no tenemos tantos recursos, es muy útil dárselo a un compañero, amigo o familiar para al menos reconocer casos graves de nuestra experiencia.
¿Cómo integramos estos procesos con el desarrollo?
Pienso que es ideal que algunos integrantes del equipo de desarrollo participen de las actividades de la etapa creativa. No tienen que ser todos, solo algunos (o uno) dependiendo del tamaño del proyecto.
Esto hace que el equipo tenga datos técnicos sobre la factibilidad o el costo de diseñar ciertas funciones.
Una vez que tenemos una etapa de diseño validada (por el cliente o product owner), los desarrolladores (tanto backend como front end) van a tener recursos útiles (flows, wireframes y prototipos) para estimar sus tareas con la mayor exactitud posible.
También podrían paralelizarse algunos procesos. Por ejemplo, si validáramos todos los flujos del sistema en “en baja”, los desarrolladores backend podrían empezar a hacer su trabajo, mientras los diseñadores UI trabajan en diseñar la interfaz en “alta” (recomendable solo para equipos aceitados).
En cuanto al desarrollo frontend, ahí existe una dependencia inevitable.
Al principio pensaba que UX era algo en lo que solo invertían las grandes compañías. Como si la única solución fuese “tener plata” para hacer las cosas bien.
Con el tiempo (y el estudio) me fui dando cuenta de que esta diversidad de prácticas son aplicables a todo tipo de proyectos y escalas. Siempre es mejor hacer “algo” de UX que no hacer nada.
Los beneficios son varios:
- Aportar visibilidad sobre la solución previa al desarrollo.
- Ordenar la etapa de desarrollo.
- Mejorar la estimación de tareas.
- Reducir fricciones entre el equipo y el cliente.
Todo esto apunta a un gran beneficio: “REDUCIR COSTOS”.
Entonces… ¿Por qué no se le da la importancia suficiente?
Por un lado hay una falta de protagonismo de los diseñadores en la industria. Siempre fuimos anexos de los equipos de desarrollo, ya que los clientes siempre acuden primero a un desarrollador y no a un diseñador para encarar su idea. Por este motivo creo que la llave para empezar a hacer mejor las cosas está en las software factorys, por el contacto con el cliente, y porque se les agiliza el trabajo a ellos también.
Por otro lado pienso que hay una tendencia a resolver cualquier necesidad con una “app”, cuando todavía, en algunos casos, no es necesario. El mundo está muy digitalizado, pero desarrollar software sigue siendo caro (sobre todo hacerlo bien), por lo tanto es muy importante masticar bien tu idea primero, bocetarla, ponerla a prueba, responder las preguntas básicas, hacer un verdadero foco en la necesidad y sobre todo en “quién” lo necesita.
