Este post es una transcripción de la charla que di el pasado 28 de abril en Campus Madrid.
Si te da pereza leer, la mitad de la charla está en Periscope.

Me llamo Ivo y diseño Gamify.

El guapo soy yo ↗️

Mi trabajo consiste en comunicar, especialmente cuando no se pueden usar palabras.

Para ello uso colores, iconos, el espacio y, eventualmente, cuando tengo que estructurar cierta cantidad de información, las cosas se vuelven más o menos complejas:

⬆️ Esto es un proyecto de Sketch, el mítico software de diseño de interfaces

Hay veces que mi trabajo no cumple su función: no comunica el mensaje adecuado. Y es que no es fácil comunicar sin palabras.

Más a menudo de lo que me gustaría escucho frases como:

🤔 ¿qué hace ese botón?
😯 ¡no me esperaba que pasase eso!

y, con menos frecuencia:

😒 pero… esto no es la versión final, ¿verdad?

Y es que aunque te hayas pasado años estudiando diseño, psicología de la percepción y todo el rollo, la vas a cagar si no haces dos cosas:

1. Prototipos

Es gratis, es fácil, y si no sabes, te voy a enseñar a hacerlo. No tienes excusa.

2. Probar los prototipos (con gente que no seas tú)

Hacer que una persona pretenda que cuatro garabatos son una interfaz real que se mueve y hace cosas es bastante ridículo, pero no tanto como tener que tirar una app a la basura porque tu diseño es una mierda.

Regla nº2: tú no representas al usuario medio porque el usuario medio no existe.

Es célebre en el mundillo de la usabilidad la historia de la primera impresora electrónica (o una de las primeras, me disculpen la falta de rigor histórico). 
Hicieron una interfaz que no sabía usar ni su puta madre, y tras el lanzamiento, los ejecutivos encargados del proyecto dijeron algo así como:

“Si la gente no sabe usarla, es porque son imbéciles. ¿Por qué no se leen el manual?”
⬆️ Tu cara cuando tienes que leerte un manual

¿Cómo les fue? Pues supongo que no muy mal, porque las grandes empresas casi siempre esconden bien sus errores.

Pero la moraleja es que, hagas apps o impresoras, antes de tirar a la basura meses y montañas de 💰 desarrollando algo que no va a poder usar ni tu prima, viene muy bien ir involucrando a gente que no seas tú ni tu equipo en el desarrollo.

Y ahora viene cuando dices :

¿Enseñar mi app antes de lanzarla? ¡Me van a robar la idea!

Te la van a robar igual:

Para quienes no se hayan enterado (!!!): Facebook ha ido integrado en todas sus apps (Facebook, Messenger, Instagram y WhatsApp) “stories”, un formato acuñado por Snapchat.

👷🏻‍ El caso práctico

Normalmente, cuando haces un producto digital (una app) pasas por varias fases: encuentras un nicho de mercado, validas la idea, diseñas el mínimo producto viable, lo pruebas con usuarios, lo programas y lo sacas.

Hay quien se salta la parte de probarlo con usuarios, quien se salta la de validar la idea y hasta hay gente que tiene que retirar después de lanzar.

Con Gamify, hicimos validación, testing y lanzamiento en una misma noche:

Back to School (a.k.a. Back to Campus) fue la primera gran fiesta que se organizó en Campus Madrid, al poco de abrir sus puertas.

Mis socios y yo acabábamos de empezar a desarrollar Gamify, y el equipo de Campus nos propuso probarlo en Back to School.

En la fiesta había muchas actividades, como preparar tu propio cóctel o hacerte un tatuaje temporal, y la idea era convertir todas estas actividades en logros, y usar Gamify para “conseguirlos” todos.

Cada vez que participabas en uno de los talleres, subías una foto a la app y salía en las teles de Campus:

Tuvimos más o menos un mes para desarrollar dos apps para la fiesta (una para móvil y otra para las teles).

¿Quién tiene tiempo para prototipar, verdad?

Nos pusimos directamente a diseñar y a picar código, y el MVP (mínimo producto viable) fue el que nos salió de las ⚽️🏀🎾.

Os transcribo una de las conversaciones con el entonces product manager:

PM: La app tiene que tener chat.
YO: ¿Por qué?
PM: Todas las apps tienen chat.
YO: ¿Y qué?
PM: Tenemos que ser mejores.
YO:

¿Sabéis cuántos mensajes se mandaron? DOS.

Una semana de desarrollo para dos putos mensajes.

Si hubiéramos contextualizado el uso de nuestra app, nos habríamos dado cuenta de que, en una fiesta como aquella, la gente entra, saluda y va directa a por [comida y] bebida.

Luego, se pasan 3 horas hablando con quien pillan, y cuando les suben las dioptrías, se van a casa.

No hay tiempo para usar un chat.

Y ahora es cuando dices:

Bua, pero eso es de sentido común.
Regla nº 8: Nunca comprometas tu producto dando cosas por hecho: destierra el “sentido común”.

Estamos hablando de productos que van a usar otras personas, quizá muy distintas a ti, y quizá en situaciones también distintas: en el salón de casa con WiFi fibra óptica ultra HD 4K o en un vagón de Metro de la Línea 6.

Si para ti era “de sentido común” que tu usuario final tiene un ancho de banda tremendo…

🤓 EN SÍNTESIS:

  1. Haz prototipos y pruébalos con gente que no seas tú.
  2. Pueden robarte la idea y mantener una valoración de ~20.000.000.000 de dólares.
  3. Cuidado con el “sentido común”.

Todo eso era la intro. Ahora viene la magra:

Vas a pasar por distintas fases a medida que tu prototipo evolucione. Las dos primeras (needfinding y storyboarding) se centran en averiguar las necesidades de tus potenciales usuarios/as y en qué entorno van a usar tu producto, mientras que las dos siguientes se centran en probar prototipos más o menos complejos con dichos usuarios/as.

Fase 1: Needfinding + Storyboarding

Seguro que el primer impulso a la hora de ponerte a trabajar es pensar “¿cómo se va a ver mi idea?”; quizá buscas en Internet “material design” o “guías de diseño de Apple”.

Quizá empiezas con algo así:

No lo hagas.

Primero tienes que saber quién va a usar tu producto, cómo y dónde: haz un storyboard. Como en las pelis.

Aquí tienes una miniguía para hacer storyboards.

En Shazam, la app de reconocimiento de canciones, hicieron muy bien los deberes: averiguaron que la gente suele usar Shazam cuando está escuchando una canción y no se la quiere perder, así que solo tienes que pulsar un enorme botón azul para reconocerla:

Otro método que funciona muy bien es dramatizar. Esto lo aprendí de unos tipos de UX de Google que pusieron el ejemplo de los cajeros automáticos para hacer esto en directo:

👱🏻 Hola, cajero. ¡Dame dinero!
📺 Hola, persona. ¡No sé quién eres!
👱🏻 ¡Oh, es cierto! ¿Qué debería hacer ahora?
📺 Meter tu tarjeta y poner tu pin, así sabré quién eres y podré darte tu dinero.

Parece una idiotez, pero si fuera tu app, acabarías de descubrir que necesitas un login. Puede que ya hubieras pensado en desarrollar un login, pero ¿sabías si realmente lo necesitabas?

Dramatizar o tocar botones de papel es ridículo, pero nada comparado con Jeff Hawkins en 1995, cuando se fabrico una PDA de madera para llevarla por ahí haciendo como si fuera de verdad en los lugares en los que la usaría de verdad:

Si de normal parecerías gilipollas, hace veintipico años era como para ingresarte.

Aquí te dejo un guión que encontré en Internet para entrevistar a gente y obtener las necesidades antes de ponerte a desarrollar nada.

Fase 2: wireframing

Ahora que ya sabes dónde y cómo va a usar la gente tu producto, diseña una interfaz en papel, o como dicen los bretones, un wireframe:

Como ves, esos dibujos cutres muestran todas las acciones posibles de un producto tan complejo como YouTube: reproducir un vídeo, darle a like, comentar, vídeos relacionados… sin picar una sola línea de código.

Sin hacer un diseño increíble en Sketch o Photoshop.

Ponerte a diseñar algo “más pro” es tentador, pero hacerlo en papel y en plan cutre tiene su porqué: cuando la gente ve algo muy bonito, muy bien hecho, es más reticente a dar feedback. Les da palo.

Y también nos ha pasado en Gamify: en seguida nos pusimos a probar prototipos “hi-res” (la siguiente fase), y de verdad que nos costaba mentalizar a la gente de que por favor criticase todo.

Aquí te dejo un guión para probar uno de estos prototipos con gente.

Alguna vez dijimos en las entrevistas que el que había diseñado la interfaz (yo) no estaba, así que podíamos ponerle a parir. Sorprendentemente, se soltaron y nos dieron un buen feedback sin miedo a herir los sentimientos de nadie.

Las claves de esta fase serían:

  1. No condiciones a la gente: no preguntes directamente “¿querrías un chat?”, porque probablemente digan que sí.
  2. Cuidado con los falsos positivos. Que alguien te diga que quiere un chat ni siquiera significa que vaya a usarlo.
  3. No les hagas un tour guiado. Cuando la gente se baje tu app, no vas a estar ahí para explicárselo todo.

Fase 3: hi-res mockup

Este proceso culmina con un mockup de alta fidelidad, o lo que es lo mismo: la interfaz terminada. Para esto, te va a venir bien un/a diseñador/a, pero si no tienes esa suerte, en las últimas slides puse buenos tips and tricks para diseñar interfaces funcionales.

Dependiendo de tu producto, te será suficiente con usar InVision, una herramienta que convierte imágenes estáticas en esto:

Es súper fácil de usar. De verdad. Y ni siquiera tienes que empezar a diseñar de cero.

Aquí tienes los recursos oficiales de Google para diseñar una interfaz con Material Design:

Y aquí los de Apple:

Para otras cosas más complejas, quizá necesites usar Framer (hay que saber programar un poquito).

Y si las interacciones requieren que la información cambie en tiempo real, hay un tipo prototipo que se llama “mago de Oz”. ¿Por qué? Porque parece una app de verdad, pero es todo humo y espejos.

Vale, pero… ¿y la gente?

Igual a estas alturas estás pensando:

Todo el rato hablas de entrevistar a gente y enseñarles mi prototipo, pero… ¿de dónde saco a esa gente?

Sal a la calle. O regístrate en Twitter.

Vete a un Starbucks. Pásate por la cafetería de Campus Madrid. Ve a algún evento de startupeo y lía a quien sea para que te preste unos minutos. Y si no te puedes mover, pues mira, nosotros conseguimos nuestros primeros testers a través de Twitter, y hacíamos las entrevistas por Skype.

Si optas por abordar a gente en cafeterías, te sugiero que les invites a un café en pago por su tiempo. Nosotros les regalábamos pegatinas. Hay quien paga con tarjetas de regalo de Amazon.

¿Y cuánta gente necesito?

Según los estudios de Jacob Nielsen, a partir de 12 personas (por prueba) encontrarás prácticamente todos los problemas de usabilidad que pueda tener tu interfaz:


Bonus level

Libros recomendados:

  1. The Design of Everyday Things (Norman, Don)
  2. Don’t Make Me Think (Krug, Steve)
  3. Hojas de hierba (Whitman, Walt) — No tiene nada que ver con diseño, pero es maravilloso.

Resumen gráfico:


Si tienes cualquier duda, quieres discutir de algo o simplemente te he robado una foto y no te hace gracia, mándame un DM 😊👍🏻

¡Ah! Y recuerda que puedes prototipar casi cualquier cosa.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.