CategoríaDesign Thinking

Qué actividades hicimos en el taller de User Research del Google Launchpad Developers Launchpad Week en Mexico City?

1. Comenzamos la jornada con la charla “Tips para hacer User Research creativamente”.

  • ¿Por qué elegimos esta charla?
  • Porque Design Sprint abandona la idea de hacer un research extenso al inicio de un proyecto y la reemplaza por un user research puntual y rápido al inicio de cada sprint.
  • Entonces los investigadores deben convertirse en grandes creativos
  • Por lo tanto, si estamos – por ejemplo – haciendo un proyecto para una universidad, quizás necesitemos entrar a las aulas y hacer dinámicas con los alumnos para comprender sus necesidades y sus frustraciones.
  • Y el desafío es lograr obtener insights en un día, el primer día de la sprint.

2: Definición y mapping de los tipos de usuarios

  • Luego les pedimos a los startups que definan un borrador de los tipos de usuarios que utilizan su app (con nombre, edad y una mínima descripción).
  • Y les pedimos que ubiquen a cada tipo de usuario dentro de un eje cartesiano donde la X es la experiencia comprando online y la Y es el conocimiento sobre los servicios que el startup está ofreciendo.

Seguir leyendo

De qué se trata Design Sprint y por qué me parece tan interesante

¿Qué es Design Sprint? Creo que podría resumirlo en un mínimo párrafo como una metodología creada por Google que ayuda a los equipos a diseñar y probar soluciones entre 2 y 5 días unificando: Design Thinking de IDEO y el mundo de desarrollo ágil.

A grandes rasgos, el proceso cuenta con 3 partes:

  1. Antes de la sprint: el líder define el reto estableciendo para cuándo debe estar desarrollada la solución que se idee, prepara la documentación necesaria, invita al equipo interdisciplinario
  2. Durante la sprint: se trabaja en el equipo interdisciplinario durante una semana completa basándose en el paradigma de Design Sprint
  3. Luego de la sprint: el líder prepara todo lo que se necesite para que la idea pueda ser implementada.

¿Por qué necesitamos un equipo interdisciplinario para alcanzar el desafío en una semana?

  • Trabajar en un equipo interdisciplinario nos permite movernos rápido y más eficientemente que si solo ideara soluciones gente de áreas específicas que puede llegar a desconocer barreras y detalles que deberían tenerse en cuenta.

El paradigma implica compartir el momento de ideación de un modo democrático, con el fin de avanzar todos juntos a una solución concreta que realmente se pueda llevar a cabo.

Seguir leyendo

Podcast de @analiticageek sobre la metodología Design Sprint

Dado que mi querido compañero Richard Johnson me esbozó que  mi post era hermético y volado, aprovechamos e hicimos un podcast en @analiticageek  para intentar explicarlo ;)

El detalle es que:

  1. No nos tomamos ni un día para comprender en profundidad la problemática de los usuarios y la definición estratégica está ligada a un latir romántico y las soluciones que intentamos generar, muchas veces no llegan al corazón del problema y solucionan suposiciones.
  2. Al momento de idear; cuando deberíamos hacer divergencia y cada participante – de un equipo interdisciplinario – debería tener el espacio para poder escribir en una hoja en blanco al menos ocho ideas; no existe tal hoja, no existe tal equipo interdisciplinario, no existe ese espacio para que cada uno piense, escriba y exprese sus ideas. Y sólo se trabaja sobre la idea del que habló más alto. Algún cacique del equipo. Algún autoritario :/
  3. Al momento en que se debería realizar el voto en silencio y democrático de las diferentes ideas, el voto está vedado. En realidad, no existe la idea del voto. Aún estamos en Argentina en 1911 y no se sancionó en el congreso la Ley Sáenz Peña.
  4. Al momento en que deberíamos converger y construir una idea entre todos con esas mini ideas que fueron las más votadas; como no hubo un espacio para la divergencia ni un voto democrático; prevalece ese cacique con su propia idea, lo cual suena arbitrario y el equipo internamente no lo compra; con lo cual sigue existiendo una profunda divergencia.
  5. Al momento de prototipar, seguro se llama a un pobre diseñador al cual ni siquiera se lo incluyó en el momento de idear. El diseñador prototipa sin saber para quién y sin comprender en profundidad el problema.
  6. Nadie hace usability testing y hay una figura que se llama Product Owner, que se proclama a sí misma “la voz del usuario” (aunque nunca la escuchó) y él es quien dice lo clara, comprensible, fácil de usar y solucionadora que ha resultado cada pantalla.
  7. Se programa y se sube a producción.

Necesitamos la Ley Saenz Peña.

;)

Si quieren una explicación un poquito más detallada de Design Sprint, en Medium escribí el post en inglés: “What is the Design Sprint method and why do I think it’s interesting?”