Icono flecha hacia izquierda Ver todos los artículos

Sprint: Crear y Validar Productos

Publicado el:

En WhoKnows trabajamos una hipótesis muy simple:

¿Como podríamos planear los top 3 tasks obligatorios de un día y terminarlos al finalizar la jornada?

Decidimos hacer un sprint reducido, para acelerar el proceso y tener visuales listas lo antes posibles. El Design Sprint usualmente dura 4 o 5 días, ya que requiere investigación, profundización sobre user persona y un nivel de prototipado más rápido.

Pero decidimos hacerlo en 3 horas.

Para hacerlo utilizamos:

1) ¿Cual es el objetivo?

alt text

Fuimos desde lo genérico hasta lo más específico y nos llevamos las preguntas más representativas. La performance de trabajadores remotos.

Incluso antes del coronavirus, había un gran espectro de trabajadores 100% remotos que usaban muchas herramientas para mantenerse productivos (pomodoros), para contabilizar horas trabajadas (pomello), para gestionar proyectos (Asana o Trello) con modelos kanban y muchas otras cosas más.

Sin embargo, notamos que falta algo que permita bloquear horarios y definir cuales son los motivos por los cuales tardamos más o menos en task.

2) ¿Sobre qué vamos a hacer el Sprint?

alt text

Cuando una piensa en soluciones, buscar ir de 0 a 100 lo más rápido posible. Pero con el sprint no es necesario trabajar TODA la solución. Simplemente se pueden seleccionar partes de la misma. Lo ideal es hacer un mapa de usuario para visualizar rápidamente los touchpoints de la solución y con esa información decidir sobre que experimentar el prototipado.

3) ¿Cuales son los micro-problemas que parten del primer objetivo establecido y de la parte de sprint seleccionada anteriormente?

alt text

Vamos a poder entender que en un onboarding de una app de productividad hay cientos de features: relojes, campos desplegables, calendarios integrados, time blockers y muchas otras cosas más. Lo conveniente es listar en cantidad (filosofía brainstorming) para poder tener un panorama más completo.

4) ¿Qué referencias tenemos?

alt text

Siendo 2020 probablemente no estemos descubriendo la pólvora. Lo ideal es mapear el mercado lo más posible para saber que se hizo, que hay que mejorar, y más importante, sobre qué base queremos trabajar nuestro producto. Para eso sirven los lightning demos.

Algunas de las referencias que encontramos en este caso:

5) ¿Cómo se vería?

alt text

Sí, lápiz y papel.

Toda la magia de la solución puede verse en un borrador 100% humano y entenderse.

Si no funciona de esta forma, es difícil que lo haga en una app nativa real.

En este momento, tomamos las referencias que tenemos, el momento de sprint elegido y los micro-problemas pensados y hacemos el ejercicio conocidos como Crazy8s. De esta manera dibujamos 8 veces formas de solucionar todos los puntos anteriores.

Nota: Con herramientas como excalidraw.com se puede hacer sketching de forma remota y fabulosa.

6) ¿Hay algo cercano a un MVPs de esto?

alt text

No hacen falta grandes habilidades de diseño para tomar un conjunto de referencias y diseñar interfaces en escala de grises que muestren una solución. El objetivo final es tener una visual representativa del producto. Es un gran punto de partida.

7) ¿Cómo sigue la historia?

Simple. Seleccionar otra etapa del sprint y volver a empezar.

En 12 horas netas se podría tener un conjunto de pantallas para simular un prototipo super realista.

Cualquier programador agradecería ver un conjunto de pantallas funcional antes de ponerse a escribir código, así que es una forma de empezar cualquier proceso que implique visualizar una idea en una interfaz tangible.

Después se pueden usar herramientas como Adalo, Bubble o Webflow para construir prototipos funcionales de productos digitales, sin código.

Conclusión

Los MVPs no tienen porque tardar 10 meses. Si usamos los procesos adecuados, podemos estar validando productos mucho más rápido de lo que creemos posible.