Storyboards: contar la experiencia en paneles
Un storyboard de UX cuenta, en paneles, cómo una persona vive una experiencia: escenario, visuales y leyendas. Cómo hacerlo, qué fidelidad usar y cuándo no.
¿Qué es y de dónde viene?
El concepto viene del cine de animación. Adobe XD lo atribuye a los estudios de Walt Disney en los años treinta, y el lenguaje se trasladó después al diseño de productos. En UX, un storyboard no pretende ser una pieza final. Su función es mapear eventos clave y dar contexto emocional a una secuencia de acciones.
NN/g (Rachel Krause) lo define como una historia contada con imágenes en una secuencia de paneles. Lo importante no es el dibujo, sino la secuencia: qué pasa primero, qué siente la persona y qué ocurre después.
¿Por qué le importa a un diseñador?
Porque las pantallas explican qué hace el producto, pero no explican por qué le importa a alguien. Un storyboard obliga a mirar el momento anterior y el posterior a cada interacción: dónde estaba la persona, qué la motivó, qué esperaba y cómo se sintió cuando el resultado no llegó.
También sirve para alinear. Entre los usos que NN/g enumera están resumir sesiones de pruebas de usabilidad (con citas del usuario y su lenguaje corporal), añadir contexto de usuario a un mapa de recorrido, construir una comprensión compartida para priorizar y generar ideas, donde el storyboard es una herramienta de conversación más que un entregable duradero. Un equipo que discute un storyboard de cinco paneles suele ponerse de acuerdo más rápido que uno que discute cuarenta pantallas.
NN/g también marca la diferencia con el mapa de recorrido: el storyboard se apoya en imágenes, tiene un alcance estrecho y lo usa sobre todo un equipo; el mapa es amplio, usa mucho texto y circula entre áreas para encontrar puntos de dolor.
¿Cómo se hace, paso a paso?
NN/g propone un proceso de seis pasos:
- Reunir datos. Entrevistas, pruebas de usabilidad o métricas que sustenten el escenario.
- Elegir la fidelidad según el objetivo y la audiencia.
- Definir la persona y el escenario. Un storyboard por camino de usuario.
- Planificar los pasos escribiéndolos con flechas y añadiendo un icono de estado emocional a cada uno.
- Crear los visuales y añadir leyendas breves sobre la acción, el entorno, el estado emocional y el dispositivo.
- Distribuir, pedir retroalimentación e iterar.
Adobe XD añade un matiz útil: el escenario debe describir el entorno, la persona con sus frustraciones y emociones, el objetivo que quiere resolver y un arco narrativo con inicio, desarrollo y final. Esa estructura ayuda a que el storyboard no se quede en una lista de clics.
¿Qué fidelidad conviene?
NN/g afirma que la baja fidelidad es lo más valioso. Los bocetos o notas adhesivas sirven para ideación; las fotos o capturas de video, para grabaciones de pruebas de usabilidad; las ilustraciones detalladas, para presentar a un cliente o como entregable de diseño. Cuanto más pulido, más tiempo cuesta y más difícil es cambiarlo, lo que va en contra de la conversación que buscas.
Las leyendas deben ser breves. NN/g recomienda no superar dos puntos por imagen, porque el visual es el contenido principal. Si necesitas explicar más, probablemente la escena está mezclando dos momentos. Digital.gov, en su método de storyboards, pide anotar cada escena con lo que el usuario intenta hacer y estima uno o dos días de trabajo según la complejidad del escenario.
¿Un camino por storyboard?
Sí, y es una regla importante. Cuando un storyboard intenta cubrir varios caminos, se convierte en un diagrama de flujo. NN/g lo resume así: “no es un diagrama de flujo, es un argumento narrativo” (en el original, it’s not a flowchart, it’s a storyline). La solución es hacer un storyboard por cada camino relevante. Si el usuario puede llegar al mismo resultado por dos vías, el storyboard de cada una te dirá cuál es más natural.
¿Cuándo NO conviene?
- Cuando el flujo es lineal y simple. Un user flow o un wireframe cuenta lo mismo con menos esfuerzo.
- Cuando la pregunta es de lógica, como qué pasa si la tarjeta es rechazada. Para eso sirve mejor un diagrama de decisiones.
- Cuando no hay datos del usuario. Un storyboard sin investigación detrás es una fantasía bien dibujada.
- Cuando se pulen los paneles antes de haber discutido el problema.
Ejemplo
Ejemplo ilustrativo: un equipo de una app de transporte escolar quiere entender por qué los padres dejan de usarla después de la primera semana. Con las entrevistas de la semana anterior, arma un storyboard para una madre con dos hijos y un horario de trabajo rígido. Cuatro paneles: la madre recibe la alerta de retraso, busca el número de la conductora, no lo encuentra en la app y llama por teléfono. La leyenda del tercer panel dice: “Esperaba ver la ubicación del bus y el contacto de la conductora sin salir de la app”. El equipo descubre que el problema no es la ubicación, sino el contacto. Lo convierte en una prioridad antes de rediseñar nada.
Para tu próximo proyecto: elige un escenario de tu producto, dibújalo en cinco paneles sin pensar en pantallas, y pregúntate en qué panel la persona duda. Esa es la pantalla que más necesita atención.
Errores comunes
- Pulir el dibujo antes de validar el escenario.
- Mezclar varios caminos en un solo storyboard.
- Dibujar pantallas en lugar de momentos de la persona.
- Escribir leyendas largas que compiten con la imagen.
- Olvidar la emoción, que es lo que distingue el storyboard de un flujo.
- No basar el escenario en datos reales de investigación.
Relacionado en la wiki
Para la parte lógica de la experiencia, los user flows son el complemento natural. Si quieres ver el recorrido a lo largo del tiempo y los puntos de contacto, mira los mapas de recorrido del cliente. Y para definir quién vive el escenario, las personas son la base.