Proceso General de UX

Hay muchas veces que llegamos a tener una muy buena idea de producto digital (app móvil ó de cómputo) y no sabemos por dónde empezar, queremos sacar un nuevo Uber ó Facebook, pero no tenemos el dinero y tiempo para invertir en plataformas como ellas, y aunque tuviéramos estos recursos nos encantaría tener un producto en el mercado lo más pronto posible para esos momentos nos conviene salirnos un poco de la caja y utilizar de la mejor manera nuestros recursos, siempre pensando que son limitados, para estos casos el modelo de product development llamado Lean UX nos caería de Maravilla.

Lean UX

Lean UX se enfoca en generar experiencias de usuario en diseño requiriendo que el trabajo en equipo este muy integrado. El objetivo principal es centrarse en obtener retroalimentación tan pronto como sea posible para que se pueda utilizar para tomar decisiones rápidas bajo conceptos ágiles (Véase Manifiesto por el Desarrollo Ágil de Software). La naturaleza del desarrollo Ágil es trabajar en ciclos rápidos e iterativos (que tomen en base el resultado del ciclo anterior) y Lean UX imita estos ciclos para garantizar que los datos generados creen nuevas conclusiones por cada iteración.
Trabajar con este tipo de metodologías nos podría traer las siguientes ventajas:

  1. Velocidad: Realizar versiones mejoradas de manera rápida y desechar los entregables que no generan ningún valor.
  2. Visión heterogénea: Todos los involucrados deciden sobre las modificaciones que mejorarán el producto.
  3. Mejoras múltiples: Mientras más validaciones, se obtendrá un producto más funcional.
  4. Menos consumo de recursos. Cada hora de desarrollo tiene un costo, al ser Lean la manera más rápida de hacer un desarrollo, también es la más económica.
  5. La mejor versión viable, Lean ux no se basa en probabilidad sino en certeza, que es lograda por la experimentación validada.
  6. Adaptación al cambio, hoy en día un producto que no evoluciona se muere porque se lo come el mercado, haciendo procesos iterativos se evita la oxidación de la idea y del producto.

Sabiendo todo ésto una forma sencilla de hacer el proceso de desarrollo de productos sería siguiendo los siguientes 14 pasos.

1. Insights ó idea principal:

Se trata de generar una hipótesis fundamentada en experiencias personales.
Un día estamos en la regadera y mientras nos estamos bañando se nos ocurre una idea que podría revolucionar la manera del mundo de funcionar, (sí, a todos se nos ocurre esa idea que podría cambiar la manera de resolver un problema), lo importante es no dejarla ahí, apuntarla, platicarla, enamorarse para poder generar un proyecto de la misma.

2. Benchmark Research

Se trata de entender mejor el ambiente con el cual va a competir nuestro producto digital, lo primero que debemos de entender es que un producto exitoso SIEMPRE es la solución a un problema, por lo tanto el producto podrá evolucionar, pero siempre enfocándose a resolver el problema principal, por lo tanto la serie de preguntas a resolver sería:

  • ¿Cuál es el problema a resolver?
  • ¿Qué otros productos en el mercado resuelven el problema encontrado?
  • ¿Hay alguna solución similar ó mejor a la planteada como insight?
  • ¿Qué problemas tiene la competencia?
  • Otras. En esta sección se hará una investigación lo más completa posible, por lo tanto, cualquier pregunta que te pueda ayudar a entender mejor el mercado es válida.

Razones por las que nos sirve el estudio de Benchmark:

  • Nos ayuda a conocer productos para superarlos.
  • Enriquece nuestro diseño.
  • Nos ayuda a aprovechar los estudios de usabilidad que pudo haber hecho alguien más
  • Nos ayuda a identificar lo que no está haciendo nuestra competencia ó está haciendo mal.

El objetivo de este ejercicio es conocer al mercado y si ésto no te desmotiva para continuar con el proyecto te dará más herramientas para que éste sea exitoso, además es importante guardar toda la investigación en un solo lugar para que podamos acceder a ella de manera sencilla en el futuro, una muy buena herramienta es https://mural.co/, pero hay otras en el mercado.

3. Entendiendo al usuario (Research)

Lo más importante del UX es que está centrado en el usuario, lo que significa que ellos son la última palabra para tomar cualquier decisión, así que se recomienda validar con ellos para ésto se podrán hacer:

  1. Entrevistas a profundidad
  2. Encuestas

El objetivo será conocer si:

  • ¿El producto es viable?
  • ¿Existe la necesidad?
  • ¿Existe oportunidad de mejora?
  • ¿La solución resolverá la necesidad?
  • ETC.

4. Proto Persona

Las proto-personas son recreaciones del equipo para identificar a los usuarios óptimos para utilizar el producto, se originan en talleres de lluvia de ideas donde los participantes de la empresa intentan resumir las hipótesis de la organización (en función de su experiencia en el dominio y su intuición) sobre quién va a utilizar su producto o servicio y qué los motiva a hacerlo. Las proto-personas le brindan a la organización un punto de partida para comenzar a evaluar sus productos y a crear algunas hipótesis de diseño temprano. También son útiles para iniciar y reforzar la conciencia corporativa del punto de vista del cliente para garantizar que esté incluido en la planificación estratégica. Esto es especialmente cierto cuando los creadores de estos proto-personajes están en condiciones de afectar la dirección estratégica de la empresa.
Se deberán de diseñar al menos 3 proto-personas y cada una deberá de tener al menos las siguientes características:

  • Nombre
  • Cualidades
  • Defectos
  • Objetivos del usuario a cumplir con la plataforma

5. Casos de uso

Escribir una historia por cada proto-person de cómo utilizarían la plataforma mismas que nos ayudará a evaluar funcionalidades para agregar a nuestro producto en los puntos de toma de decisión.
Los casos de uso estarán basados en suposiciones y incorporarán escenarios de posible uso para nuestras plataformas aunque no deberán de incluír la existencia de nuestro producto.
Sobre los casos de uso será importante destacar y separar los momentos óptimos de uso de la aplicación con las funciones que podrían mejorar la experiencia del usuario en la situación descrita.

6. Definir elementos del MVP (Producto mínimo viable)

El MVP (por sus siglas en inglés minimum viable product) es un concepto ágil que se refiere a la versión del producto mínima para que cumpla con su necesidad, se podría decir que es un producto basado en el corazón de la idea, sin más ni menos, para poder encontrar los puntos fundamentales del MVP se podrán dividir los elementos en 3 categorías.

  1. Must to have: El corazón de nuestro proyecto, acá van todas las características que generen el valor trascendental de la aplicación y que sin ellas no se logre resolver los problemas planteados,
  2. Should have: Son características imprescindibles que aporten valor pero que sin ellas se sigan resolviendo los problemas planteados
  3. Nice to have: Son características que no estén directamente relacionadas al problema a resolver y que puedan llegar a estorbar ó no se vayan a usar frecuentemente.

Siendo la primer categoría (must have) la que definirá el producto mínimo viable, los elementos que no se encuentren en ésta deberán de tener una ponderación baja a la hora de diseñar la plataforma y serán prescindibles, es importante tener en mente que cada característica ó feature que se plantee requerirá tiempo de desarrollo y cuando esté desarrollada necesitará tiempo de mantenimiento, y para Lean lo más importante es aprovechar el tiempo sólo para las tareas trascendentales para poder tener productos funcionales lo más pronto posible.

7. Arquitectura de la información

La arquitectura de información se refiere al esqueleto de la aplicación por lo tanto contiene a los módulos de la misma, primero el diseñador deberá de plantear los módulos y pantallas que se necesitarán para completar los must to have.
Teniendo este bosquejo de arquitectura se podrá validar con el usuario con card sorting:

Card Sorting:

Existen dos tipos de técnicas de card sorting:
abierto, si durante el proceso entregamos tarjetas en blanco a los participantes y se permite nombrar los contenidos y ordenarlos en categorías,
cerrado, se les entregan tarjetas predefinidas y únicamente deben ordenarlas.
La dinámica básica de un card sorting es la siguiente:
Entregamos un número de tarjetas que no supere las 30 o 40.
Dejamos al participante o participantes, que las ordenen en categorías (si es cerrado) o coloquen un nombre (si es abierto).
Comparamos los resultados del card sorting entre los participantes, identificando los puntos de coincidencia o discrepancia, para extrapolar conclusiones.
Los resultados pueden ser muy variables: que coincidan con nuestro criterio, que los usuarios no entienden el etiquetado, que lo entiendan pero no están de acuerdo en la agrupación o les resulte confusa, o que discrepan en todo. De nuestro criterio como diseñadores de UX deberemos extrapolar conclusiones que aplicar a nuestro diseño.

8. Mapa de flujos

El mapa de flujos ordenará la arquitectura de información en procesos lineales, dicho ésto se dibujará en papel de manera básica cómo interactuará la aplicación en los casos de uso, ésto nos deberá sacar las pantallas con las que deberá de contar nuestra aplicación.

9. Wireframes

Un wireframes es la representación visual de los elementos de una aplicación ó página web, sería algo como la columna vertebral de un proyecto y sirve para:

  • Establecer la jerarquía de la información
  • Como puente de comunicación entre el clientes, usuarios, diseñadores y programadores
  • Definir interacciones básicas (no finales)
  • Definir la estructura y alcances básicos del proyecto sin conocer los detalles finos del mismo

Los wireframes son esquemas que van a dar sentido a la aplicación que estamos desarrollando de manera estructural. Son dibujos con estructuras simples que muestran cada una de las pantallas de la aplicación con los elementos maquetados a manera de boceto sin tomar en cuenta tipografías, colores, contenido, etc.
Un buen wireframe es hecho rápidamente y contendrá notas, lo importante es que pueda “dar una idea” de cómo se va a ver la aplicación.
Una recomendación es hacer los wireframes a mano, en lo personal a mi me gusta empezar a bocetar en un pizarrón y tomarle fotos.

Wireframe en papel

En esta fase será importante entender el proyecto a la perfección, enfocarse en lo indispensable para que podamos bocetar el MVP (Proyecto mínimo viable) nada más, ésta técnica ayudará a empezar a sacar todo de la cabeza al papel.
Para realizar un wireframe es necesario entender el proyecto y pensar en formas de comunicar la funcionalidad, los siguientes son unos tips para la hora de hacer un wireframe:

  • Divide el flujo en pantallas
  • Cada pantalla deberá de tener secciones que expresen las diversas funcionalidades de la aplicación, para ésto cada bloque debe de ser definido,
  • Empieza con los bloques y secciones (ponles nombres y notas)
  • Dentro de las secciones dibuja los elementos de la interfaz basándose en patrones de diseño
  • Utiliza figuras geométricas básicas poco detalladas
  • No temas a volar tu imaginación, y si puedes, es mejor hacer varias variantes de las pantallas para que al final del proceso tengas material para tomar decisiones
  • El wireframe debe de ser legible y para eso se pueden usar todas las herramientas que se tengan a la mano, como notas, patrones de diseño, recortes de revistas, etc.

Para más información de cómo bocetar una experiencia de usuario podrás verlo en los siguientes videos:

  • ¿Cómo hacer un wireframe en papel ó pizarrón?

10, Digitalización del wireframe de bajo y alto nivel

El proceso de UX que estamos haciendo va de lo general a lo particular, por lo que primero haremos una digitalización de bajo nivel y luego lo detallaremos poco a poco.

Digitalización de bajo nivel (wireframe)

El objetivo de este proceso es de manera rápida convertir lo que hicimos a mano a la computadora para que podamos enfocarnos luego en los detalles por lo tanto por el momento sólo nos enfocaremos en los bloques de información y en la interacción básica de la aplicación.
Yo utilizo programas de diseño UX tales como sketch ó Adobe XD, si deseas aprender a utilizarlos sigue las siguientes ligas:

  • Curso de sketch
  • Curso de Adobe XD

Lo primero que tendremos que hacer será importar las fotos de las pizarras con la experiencia de usuario correcta para nuestra aplicación.
Se tendrá que trabajar en el mismo archivo por separado cada pantalla y por cada una de éstas se definirán las secciones de la siguiente manera:

  1. Definir las secciones de la pantalla en bloques (encabezado, contenido, footer, zonas de interacción, etc)
  2. Definir los elementos que irán en cada subsección (utilizar sólamente formas básicas como rectángulos y círculos, además de notas para poder entender la interfaz a futuro)

Contando con la definición básica de todas las pantallas podremos iniciar a detallar nuestra plataforma a nivel intermedio.

Digitalización nivel intermedio de detalle (wireframe)

Una interfaz es como un chiste, si no se entiende, no sirve. Grandes estudios invirtieron grandes cantidades de diseño para generar sus experiencias y lo mejor sería de momento tomar prestados los resultados de esas investigaciones para que nuestro prototipo se entienda mejor, todo esto está englobado en un término llamado Patrones de diseño.
Si deseas saber más por favor ve el siguiente curso

  • Curso  de patrones de diseño

11. Mockup

Nuestro wireframe de alto nivel podrá mostrarnos la intención de la aplicación, pero para poder generar experiencias y sentimientos es necesario ir un paso más y generar interacciones, en este paso detallaremos qué es un mockup y para qué sirve.
Los mockups son los flujos visuales completos utilizados para la presentación del diseño visual general del producto. Tiene elementos visuales más ricos que los wireframe, incluidos gráficos, diseño, color y otra presentación visual más detallada. Hasta cierto punto, es el diseño final del producto.
Tomando como base un wireframe de alto nivel las acciones a realizar serían:

  • Detallar al máximo la interfaz de usuario
  • Generar interacciones (botones, scrolls, gestures, cambios de pantallas, etc) al mayor nivel que se pueda

Todo ésto se puede hacer con Adobe XD y con plugins de Sketch.
Al terminar un mockup ya se tendría suficiente material para mostrarse a cualquier persona y se entienda el producto (sobre todo al cliente y al usuario final), mismos que validarán el prototipo en la siguiente sección

12. Prueba de usabilidad

El peor escenario posible para el desarrollo de un proyectos es que acabe siendo costoso, largo, tedioso y que al final no sea lo que el usuario necesitaba, para bajar la posibilidad de este escenario fatídico la metodología LEAN UX recomienda hacer testing con los usuarios finales.
Un proceso sencillo para ésto es:

  1. Hacer un Mockup del producto
  2. Redactar un guión de cómo se va a hacer la prueba, en éste se recomiendan plantear tareas sencillas (por ejemplo cómo resolverías cierto problema de tu vida cotidiana usando mi plataforma).
  3. El test debe de ser corto, es preferible revisar una funcionalidad a profundidad que 10 por encima
  4. Es importante reiterarle al usuario que no se esta calificando su desempeño y que cualquier error encontrado puede servir para mejorar, lo mejor sería que el personal que hace la prueba no esté involucrado en el diseño del producto para que no esté viciado el test.
  5. Al hacer la prueba hay que tener cuidado con el cómo formular las preguntas para no influenciar al usuario.
  6. Hacer la prueba a 6 personas de cada uno de los targets evaluados (con 6 personas similares se cubre el 80% de los errores que se puedan cometer por el mismo perfil)
  7. Cada prueba deberá ser grabada y ejecutada por dos personas del staff (una para guiar la prueba que interaccione con el usuario y otro que tome notas) y con cada usuario por separado
  8. Se le deberá de pedir al usuario que comente en voz alta todo lo que esté haciendo y pensando
  9. El usuario se debe sentir cómodo al hacer la prueba, por lo tanto se debe de acoplar el test para que sea lo más natural posible, para ésto se podría llevar material adicional como mouse, teclado, micrófonos ocultos, plumas, hojas, etc.
  10. Para cerrar el test se recomienda recompensar al usuario por su tiempo y molestia, si se hace ésto el usuario va a sentirse cómodo para regresar a hacer otro test.

13. Sesión de análisis y toma de decisiones

Con toda la información generada en el test con los usuarios se deberán tomar decisiones, para ésto se debe de sentar en la mesa todo el personal involucrado en el proyecto:

  • Diseñadores UX
  • Programadores
  • Clientes
  • Equipo de validación
  • Si es posible invitar a algún experto se podría tener un buen feedback.

El objetivo de esta sesión será tomar decisiones de los siguientes pasos del desarrollo con base en el proceso que se desarrolló para el producto, se tomará como base los resultados de las pruebas de usabilidad teniendo en mente de que el que mejor conoce sus necesidades es el usuario mismo y con modestia, se deben de revisar los siguientes puntos.

  • Satisfacción de los usuarios
  • Elementos innecesarios de la aplicación
  • Puntos fundamentales de la aplicación
  • Molestias del usuario
  • Notas del usuario
  • Tiempo de desarrollo de los elementos

Terminando esta sesión que no debe de durar más que 6 horas con hora de comida intermedia se debe de tener un consenso de lo siguiente:

  • ¿El producto satisface las necesidades del usuario?
  • ¿Conocemos lo suficiente del producto para desarrollarlo?
  • ¿Es el producto mínimo a desarrollar que no pierde la escencia del proyecto? MVP (Minimum viable product), MLP (Minimum lovable product)
  • ¿Los usuarios usarían el producto?
  • ¿Es monetarizable el producto?

Con las conclusiones existen las siguientes posibilidades

  1. Tomar la decisión de no seguir el proyecto porque los resultados dicen que es una mala idea, genial, quebraste sin invertir en el desarrollo y tienes tiempo para hacer otros proyectos.
  2. Decidir que el producto planteado anteriormente tiene algunas fallas, con lo que se deberá de corregir el mockup, la entrevista y volver a hacer la prueba de usabilidad.
  3. Hacer cambios mínimos en el mockup basándose en la data de los usuarios y seguir con el proceso de desarrollo del mismo

14. Documento de alcances

Ya teniendo un producto validado es importante redactar al mayor detalle el proyecto, a éste documento se le llama “scope document” y es la biblia de todos los desarrollos, lo empieza redactando el diseñador UX y lo corrige el equipo de desarrollo para que lo valide el cliente, teniendo esto en cuenta se deberán planear sprints cortos, cada uno de estos sprints deberá terminar una funcionalidad completa y con `ésto realizar un proceso iterativo de:
Iterativo (Diseñar → prototipar → testear → validar → programar)

  1. trabajamos en el flow
  2. hicimos wireframes en papel
  3. hicimos algunas pantallas que subimos y trabajamos en fidelidad baja y luego alta
  4. luego definimos tipografía y colores
  5. Con ese modelo ya terminado nos pusimos a trabajar en detalle en las pantallas para dejar todo listo y completamente cerrado (esto es lo que probablemente lleve más trabajo, porque es donde aplicamos todo lo definido y le ponemos el diseño FINAL a absolutamente TODAS las pantallas, lo que no solo es necesario sino ahorrará muchisimo tiempo de desarrollo y malos entendidos)
  6. aprendimos como hacer pruebas de usuarios
  7. aprendimos como facilitar la vida a los programadores y comunicar claramente todo a todo el equipo.