Ideación

Con el user journey completado y trabajado junto al equipo, idearemos y esbozaremos las primeras funciona- lidades que tendrá nuestra aplicación. La ideación se com- pone de dos fases: la primera, consiste en la generación de hipótesis y, la segunda, en el esbozo de ideas en papel u ordenador.

4.1. Generación de hipótesis

Las hipótesis son una manera de probar nuestras suposi- ciones e intuiciones, aunque no tengamos pruebas fehacien- tes y contrastadas. ¿Para qué sirven?

• Nos sirven para centrarnos en soluciones a través del dise- ño, que cubran las necesidades de los usuarios y nuestros objetivos de negocio.

• Nos ayudan a generar una cultura de aprendizaje y mejora continua, ya que enseñamos a todos las partes interesadas los beneficios de validar hipótesis con usuarios.

• Nos sirven para basar suposiciones e intuiciones en inves- tigaciones cualitativas y cuantitativas previas, de forma que estén por encima de opiniones personales.

Al disponer de uno o varios user journey, estamos prepara- dos para generar las primeras hipótesis de posibles funciona- lidades y características que podría tener nuestra aplicación. A partir del siguiente modelo de creación de hipótesis, los miembros del equipo deberían hacer un taller donde cada uno genere hipótesis acordes a las necesidades de los usuarios, siempre teniendo en cuenta el user journey de cada persona.

4.1.1. Propuesta de plantilla de creación de hipótesis

Sabemos que [información cualitativa y cuantitativa] creemos que [acción]

para [persona] conseguiremos [objetivo].

Sabremos si la hipótesis es válida [experimento] observando [KPI]

• Información cualitativa y cuantitativa: ¿cuáles son los in-

sights de los que disponemos? Si hemos realizado, como se

explicaba en el paso dos, un mínimo de análisis contextual, tendremos suficiente información para trabajar nuestra primera hipótesis.

• Acción: es la esencia de lo que queremos prototipar y testear con usuarios, la acción que resolverá el problema. Por ejem- plo, puede ser un concepto, como enfatizar la confianza de los usuarios con la aplicación, o una funcionalidad más específica, como mejorar un formulario para registrarse en la aplicación. • Persona o personas: hacemos referencia al tipo de persona

o personas al que nos dirigimos, es la audiencia que utili- zará nuestra aplicación. Podemos utilizar las personas que hemos creado anteriormente.

• Objetivo: ¿cuál es el objetivo final del test? ¿Qué es lo que se desea conseguir?, ¿aumentar las ventas?, ¿aumentar la adqui- sición de usuarios?, ¿facilitar la navegación de la aplicación? Es muy importante definir bien los objetivos que queremos conseguir para luego saber si los hemos alcanzado o no. • Experimento: a nivel práctico, ¿qué solución diseñaremos

para luego probar con usuarios? El experimento hace referen- cia a la implementación práctica de la acción propuesta. Por ejemplo, si nuestra acción consiste en transmitir el concepto de confianza mediante la aplicación, un experimento podría ser cambiar la estrategia de contenidos de la aplicación. Otro ejemplo: si nuestra acción consiste en mejorar un formulario de registro, un experimento podría ser reducir la cantidad de campos del formulario y rediseñarlos a nivel visual.

• KPI: ¿cómo vamos a medir si el experimento que hemos rea- lizado ha sido exitoso o no?, ¿cómo sabremos si hemos alcan- zado el objetivo que nos habíamos propuesto?, ¿qué métricas utilizaremos para saberlo? Los KPI (key performance indicators o

indicadores clave de desempeño) son métricas que pueden ser cuali-

tativas o cuantitativas, y nos ayudan y orientan para medir los objetivos. Por ejemplo, si nuestro objetivo es adquirir nuevos usuarios y el experimento consiste en reducir la cantidad de campos de un formulario y rediseñar la parte visual, las mé- tricas podrían ser el tiempo que tarda un usuario en rellenar el formulario, comparado con el tiempo que tardaba antes. Otra métrica podría ser el porcentaje de usuarios que ha conseguido terminar el formulario y registrarse en la aplicación, compara- do con el porcentaje de usuarios que en el mismo período de tiempo utilizaba el formulario antiguo. En caso de no disponer de información cuantitativa, especialmente cuando estamos diseñando una aplicación nueva, el mejor ejercicio para saber si la solución que proponemos cumple con las necesidades y deseos de los usuarios consiste en realizar un test que se explica en el paso 6 (validación). De esta forma, podremos medir a nivel cualitativo el éxito de nuestra propuesta.

Estos son algunos ejemplos de hipótesis elaboradas con esta plantilla:

1) Ejemplo de hipótesis basada en datos cualitativos:

Sabemos que [gracias a algunas entrevistas con usuarios, a la mayoría les frustra

no conocer los estados de sus pedidos después de realizar una compra]

creemos que [creando una sección específica en la aplicación y diseñando una

para [cualquier tipo de usuario]

conseguiremos [reducir la frustración de los usuarios]

Sabremos si la hipótesis es válida [diseñando en la aplicación una sección llamada mis pedidos que comunique mediante colores y texto los estados de cada uno

de los pedidos]

observando [mediante varios test de usuario si la mayoría sabe acceder a la nueva

sección de mis pedidos y si se comprenden los estados y colores correspondien- tes a cada tipo de pedido]

2) Ejemplo de hipótesis basada en datos cuantitativos:

Sabemos que [existe un grupo de usuarios que entra en nuestra aplicación solo

para comprar zapatos y otro grupo de usuarios que solo entra para comprar ropa interior]

creemos que [personalizando las notificaciones push]

para [los dos grupos de usuarios que tenemos identificados]

conseguiremos [aumentar el engagement con la aplicación y las ventas de los dos

tipos de producto]

Sabremos si la hipótesis es válida [enviando una notificación push personalizada a

cada grupo de usuarios]

observando [si durante un tiempo determinado la conversión de la notificación push repercute en un aumento de ventas en cada uno de los grupos, comparán-

dola con la conversión que teníamos al enviar una notificación no personalizada]

Cuando los miembros del equipo han terminado sus hipótesis, se ponen en común con el objetivo de selec- cionar las más importantes para la primera versión de nuestra aplicación. Con la selección realizada, se crean los primeros prototipos que nos servirán para observar si las soluciones propuestas satisfacen a los usuarios y las entienden.

4.2. Esbozos y diseño conceptual

¿Cómo será la aplicación a nivel visual? ¿Diseñaremos una aplicación para teléfono inteligente o para tableta?

Los distintos miembros del equipo pueden ahora trasla- dar, de forma individual y/o en grupo, las hipótesis genera- das en funcionalidades de la aplicación. El objetivo es que con lápiz y papel, o directamente diseñando la interfaz de usuario desde un ordenador, se consigan unos primeros esbozos conceptuales de las funcionalidades. A estos prime- ros diseños que se plasman en papel o en formato digital se les suele llamar modelos alámbricos (wireframes) de baja fide- lidad y sirven para plasmar visualmente las funcionalidades y los flujos de navegación entre pantallas.

Cuantos más diseños conceptuales realice cada miembro del equipo, mejor. Al finalizar, habrá una puesta en común donde cada uno presentará las funcionalidades explicando cómo solucionan las necesidades y problemas de los usuarios. Después de exponer las propuestas, el equipo debe seleccio- nar las funcionalidades que finalmente se diseñarán para ser validadas posteriormente con usuarios reales.