Prototipado en papel: probar ideas con lápiz y cartulina
El prototipado en papel usa bocetos dibujados o impresos para probar una interfaz antes de programarla. Cómo se hace, qué encuentra y dónde se queda corto.
¿Qué es el prototipado en papel?
Es un prototipo de baja fidelidad hecho con papel, tarjetas, marcadores y cinta. Cada pantalla es una hoja, y los botones o campos son recortes o dibujos. Cuando el participante toca algo, quien dirige la sesión retira la hoja actual y pone la siguiente.
Virzi, Sokolov y Karis, en su estudio de 1996 sobre problemas de usabilidad, simularon en tarjetas las pantallas y el teclado de un libro electrónico: los participantes pulsaban las teclas de papel y el experimentador cambiaba la tarjeta para mostrar la respuesta. Hasta mover un resaltado de un elemento al siguiente se simuló cambiando tarjetas. La técnica no necesita código, servidor ni herramienta digital.
¿Por qué le importa a un diseñador?
Porque te permite equivocarte barato. Cambiar una pantalla dibujada toma segundos; cambiar una pantalla programada puede tomar días. Si una idea falla en una prueba en papel, lo sabes antes de que el equipo de ingeniería empiece.
Además, la técnica obliga a pensar en el contenido y la secuencia antes que en los detalles visuales. Eso es útil para ideación y para validar la navegación de un flujo nuevo.
¿Qué materiales y cómo se conduce una sesión?
UXPin recomienda papel de impresora blanco (mejor sin rayas), marcadores negros de punta fina y de colores, notas adhesivas, tijeras, cinta y tarjetas. Con eso basta para una primera ronda.
Una sesión típica funciona así:
- Dibuja los estados del flujo en hojas separadas: pantalla inicial, cada paso, errores y confirmación.
- Define los roles. Una persona presenta la tarea, otra opera como “computadora” cambiando las hojas, y alguien toma notas.
- Ensaya antes con un colega. UXPin sugiere ensayar para que el cambio de hojas sea rápido y consistente.
- Pide que el participante piense en voz alta y no explique cada gesto.
- Cambia lo que falla durante la prueba y repite con el siguiente participante. Esto es una ventaja clara del papel: la versión evoluciona en la misma sesión.
UXPin recomienda bloques de 30 a 60 minutos y advierte que las sesiones más largas rinden menos. También aconseja grabar las sesiones.
¿Qué encuentra y qué se le escapa?
Virzi y colegas hicieron dos experimentos con 20 participantes cada uno, divididos en dos grupos de 10 (baja y alta fidelidad). En el primero, un libro electrónico, se detectaron 38 problemas distintos: cada participante de alta fidelidad encontró en promedio cerca del 38% y cada uno de baja fidelidad cerca del 34%, una diferencia que los autores no consideran significativa. En el segundo, un sistema de respuesta de voz, hallaron 21 problemas y tampoco hubo diferencia significativa. Son dos productos concretos, en 1996, así que no conviene generalizar sin más.
MeasuringU reúne ese estudio con otros trabajos y concluye que los prototipos de baja fidelidad son sustitutos razonables, aunque no perfectos, para encontrar problemas importantes. Son peores predictores del tiempo de tarea y de la valoración estética: los usuarios pueden sobrestimar el atractivo del producto final. Además, un prototipo en papel carece de la interactividad real del producto terminado, así que puede dejar escapar problemas que solo aparecen al usarlo de verdad.
Lo que el papel no puede simular bien:
| Aspecto | Papel | Digital |
|---|---|---|
| Animaciones y transiciones | Limitado: el participante imagina el movimiento | Se pueden probar |
| Estética y percepción visual | Poco fiable; el usuario puede sobrestimar el diseño | Más representativo |
| Tiempos de tarea | Poco fiable | Más fiable |
| Pruebas remotas | Difícil: hay que compartir fotos o escaneos y llevar el control de versiones a mano | Sencillo |
| Descubrir problemas de navegación | Bueno | Bueno |
¿Cuándo NO conviene el papel?
Evita el papel cuando la pregunta depende de la animación, de la estética fina, de la velocidad de respuesta o de una interacción compleja, como arrastrar varios elementos a la vez. También si necesitas medir tiempos para comparar versiones, o si el equipo está distribuido y no puede reunirse.
Tampoco lo uses para validar un patrón estándar que el usuario ya conoce, como un formulario de login. Ahí el papel aporta poco y puedes gastar la sesión en algo más incierto.
Ejemplo
Ejemplo ilustrativo: una diseñadora quiere probar si los usuarios encuentran la opción de “Cambiar plan” en una app de suscripciones. Dibuja seis hojas: inicio, menú de cuenta, lista de planes, detalle de cada plan, confirmación y error de pago. Con cinco personas, descubre que casi todas buscan el cambio en la pantalla de pagos, no en el menú. Mueve la opción esa misma tarde, dibuja la nueva hoja y repite con dos personas más. La prueba digital llegó después, con la navegación ya validada.
Errores comunes
- Usar papel para evaluar la estética, y concluir que el diseño es bueno o malo por cómo se ve en la hoja.
- No ensayar la operación de “computadora”, y perder la sesión por cambios lentos o hojas mal numeradas.
- Hacer preguntas guiadas en vez de observar, lo que sesga la prueba.
- Confundir la prueba con una demo, en la que el equipo explica lo que la pantalla “debería” hacer.
- No documentar los cambios, de modo que nadie sabe qué versión se probó con cada persona.
Si quieres combinar el papel con ideación previa, Wizard of Oz es otra forma de probar antes de construir. Para profundizar en el tipo de prueba que se hace después, mira las pruebas de usabilidad, y para entender el lugar de los prototipos en el ciclo, la página de prototipos. Las preguntas ¿Cómo podríamos…? son un buen punto de partida antes de dibujar la primera hoja.