Paper y clickable: los dos primeros niveles

Descripción

La lección 2 te dio el filtro que cualquier prototipo tiene que pasar: aprender, sin implementación real, desechable. Esta lección entra en el primer par de niveles de fidelidad — paper (un boceto, dibujado a mano o en una herramienta simple) y clickable (un mockup navegable, sin ningún backend real, pero con el que se puede interactuar tocando o haciendo clic). Los dos son baratos comparados con construir de verdad, los dos son prototipos legítimos según el chequeo de la lección 2 — pero no son intercambiables, porque responden preguntas distintas.

Hoy defines los dos primeros objetos del catálogo de niveles de fidelidad —paper y clickable— con su costo relativo y la lista de preguntas que cada uno puede responder, y verificas con canAnswerQuestion() cuál de los dos alcanza para una pregunta concreta sobre recommendations.

Conexión con el módulo. Los objetos paper y clickable que defines hoy no cambian en el resto del módulo — la lección 4 les agrega un tercer hermano (wizardOfOz), la lección 5 un cuarto (fakeDoor), y la lección 6 los junta a los cuatro, sin ningún cambio, en una sola tabla comparativa. Lo que construyes hoy es, literal, la base del catálogo completo.

Una analogía cotidiana: el storyboard y el animatic de una película

Antes de filmar una escena, un equipo de cine casi nunca salta directo a la cámara. Primero dibuja un storyboard: una secuencia de viñetas estáticas, dibujadas a mano, que muestran el encuadre de cada toma, una detrás de otra. El storyboard es barato — un dibujante lo produce en horas — y responde una pregunta muy específica: ¿la secuencia de tomas cuenta la historia en el orden correcto? ¿falta algún plano intermedio para que la acción se entienda?

Si el storyboard convence, el siguiente paso —antes de filmar con actores y cámaras reales— es a veces un animatic: las mismas viñetas del storyboard, ahora puestas en secuencia con tiempos reales, a veces con un audio provisorio de diálogo o música. El animatic sigue sin tener ningún actor real, ninguna locación real, ningún efecto especial — pero ahora se puede "reproducir", y eso permite responder una pregunta que el storyboard estático no podía: ¿el ritmo de la escena se siente bien? ¿una transición dura demasiado, o muy poco?

Un boceto en paper es el storyboard de un producto: estático, barato, perfecto para verificar la secuencia y la estructura. Un mockup clickable es el animatic: agrega la dimensión del tiempo y la interacción —tocar, navegar, avanzar— sin agregar todavía nada de lo que hace falta para filmar (o construir) de verdad.

Ejemplo trabajado: canAnswerQuestion() sobre paper y clickable

Definimos los dos primeros niveles del catálogo — cada uno con su cost relativo (en person-days, la misma unidad de timeToEvidence del módulo 1) y la lista de preguntas que puede responder — y chequeamos cuál de los dos alcanza para la primera pregunta que el equipo de Mercado quiere resolver sobre el feed de recomendaciones.

// L3: catalogo parcial de niveles de fidelidad -- solo paper y clickable por
// ahora (wizard-of-oz y fake door se agregan en las lecciones 4 y 5). `cost`
// esta en person-days: cuanto le cuesta al equipo CONSTRUIR este prototipo,
// no el producto real -- misma unidad que `personDays` en timeToEvidence
// (modulo 1).
const paper = {
  type: 'paper',
  cost: 0.5,
  canAnswer: [
    'se entiende el flujo de principio a fin',
    'el orden de las pantallas tiene sentido',
  ],
};

const clickable = {
  type: 'clickable',
  cost: 3,
  canAnswer: [
    'se entiende el flujo de principio a fin',
    'el orden de las pantallas tiene sentido',
    'la interaccion se siente natural',
    'los usuarios completan una tarea de varios pasos sin ayuda',
  ],
};

function canAnswerQuestion(prototype, question) {
  return prototype.canAnswer.includes(question);
}

const question = 'se entiende el flujo de principio a fin';
console.log('=== ¿Quien puede responder: "' + question + '"? ===\n');
[paper, clickable].forEach((p) => {
  console.log(p.type + ' (cost=' + p.cost + ' person-days): ' + (canAnswerQuestion(p, question) ? 'SI puede' : 'NO puede'));
});
console.log('\ndiferencia de costo: clickable cuesta ' + (clickable.cost / paper.cost) + 'x lo que cuesta paper, para responder la MISMA pregunta.');

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== ¿Quien puede responder: "se entiende el flujo de principio a fin"? ===

paper (cost=0.5 person-days): SI puede
clickable (cost=3 person-days): SI puede

diferencia de costo: clickable cuesta 6x lo que cuesta paper, para responder la MISMA pregunta.

Los dos pueden responder la misma pregunta — pero uno cuesta seis veces más que el otro para llegar exactamente al mismo lugar. Fíjate, sin embargo, en la lista canAnswer de clickable: tiene dos preguntas más que paper no tiene — "la interacción se siente natural" y "los usuarios completan una tarea de varios pasos sin ayuda". Esas dos preguntas necesitan algo que un boceto estático, por definición, no puede dar: la posibilidad de que alguien de verdad toque, navegue, avance y retroceda, y que el prototipo responda a esas acciones. Un boceto en papel puede simular eso hasta cierto punto —alguien "hace de computadora" y cambia la hoja según lo que el usuario señala—, pero pierde fidelidad rápido en cuanto la interacción se vuelve compleja.

Por qué clickable no reemplaza a paper, aunque pueda todo lo que paper puede

Es tentador, mirando la lista de canAnswer de clickable —que incluye todo lo que responde paper, y dos preguntas más—, concluir que conviene usar clickable siempre: "si puede responder más preguntas, ¿por qué no saltarnos directo el paso del papel?". La respuesta está en el costo, no en la capacidad: si la pregunta de esta semana es solo sobre el orden de las pantallas, pagar cost=3 por una capacidad que no vas a usar es exactamente el desperdicio que este módulo entero existe para evitar. La lección 7 va a formalizar este criterio con un algoritmo completo —pickFidelity—, pero la intuición ya está aquí: más capacidad no es gratis, y pagar por capacidad que no necesitas para la pregunta de hoy es un costo real, no una precaución inofensiva.

Errores comunes

Saltarse el paper y empezar directo por clickable, "porque así se hace siempre". Qué pasa: el equipo, por costumbre o porque las herramientas de mockup clickable son fáciles de usar, arranca directo en Figma con un prototipo navegable, sin pasar antes por ningún boceto en papel — incluso cuando la pregunta de esa semana era solo sobre la secuencia de pantallas. Por qué pasa: las herramientas modernas de diseño hacen que un mockup clickable se sienta casi tan rápido de armar como un boceto, así que la ventaja de costo del papel deja de sentirse urgente — aunque siga siendo real. Cómo detectarlo: nadie en el equipo recuerda la última vez que probó una idea con lápiz y papel antes de abrir una herramienta de diseño. Cómo corregirlo: antes de abrir cualquier herramienta, pregunta explícitamente qué pregunta se está tratando de responder — si la respuesta cabe en la lista canAnswer de paper, empieza ahí, aunque tome solo unos minutos menos que el clickable.

Usar paper para una pregunta que necesita interacción real. Qué pasa: el equipo intenta validar "¿los usuarios completan una tarea de varios pasos sin ayuda?" mostrando una serie de bocetos en papel, uno por uno, con alguien del equipo pasando las hojas manualmente según lo que el usuario "haría" — y termina con una señal confusa, porque la persona que pasa las hojas termina, sin querer, guiando al usuario en vez de dejarlo navegar solo. Por qué pasa: pasar hojas de papel se siente parecido a navegar un mockup, y es fácil no notar la diferencia hasta que el usuario se traba en un punto que el papel no puede simular bien. Cómo detectarlo: la pregunta que se quiere responder incluye palabras como "sin ayuda", "solo", o "de forma independiente" — exactamente las preguntas que, en el catálogo de esta lección, solo aparecen en canAnswer de clickable, no de paper. Cómo corregirlo: revisa la lista canAnswer de cada nivel antes de elegir — si la pregunta específica no está en la lista de paper, no fuerces el papel a responderla; sube a clickable.

Pensar que un boceto tosco condena al producto final a verse tosco. Qué pasa: alguien se resiste a mostrar un boceto en papel a un usuario real, con el argumento de que "se ve poco profesional" y podría dar una mala impresión de Mercado como marca. Por qué pasa: es fácil confundir la fidelidad visual del prototipo con la calidad del producto final, cuando en realidad son cosas completamente distintas — un boceto tosco no predice nada sobre qué tan pulido va a ser el producto terminado. Cómo detectarlo: la objeción se centra en cómo se ve el prototipo frente al usuario, no en si responde la pregunta que hace falta responder. Cómo corregirlo: sé explícito con el usuario sobre qué es lo que está viendo — "esto es un boceto muy temprano, todavía no se parece al producto final" — y recuerda que el craft visual real, cuando llegue el momento de construir, es trabajo de ui-systems-and-design-implementation-guide, no de este módulo.

Ejercicios

Ejercicio 1 — Encuentra la pregunta que solo clickable puede responder. Sin ejecutar Node, de las cuatro preguntas en canAnswer de clickable, ¿cuáles dos NO están en la lista de paper? Explica, en tus propias palabras, por qué un boceto estático no puede responderlas bien.

Ver solución

"La interacción se siente natural" y "los usuarios completan una tarea de varios pasos sin ayuda" son las dos preguntas exclusivas de clickable. Un boceto estático no puede responder la primera porque "sentirse natural" depende de cómo el prototipo reacciona a lo que el usuario hace —qué tan rápido aparece la siguiente pantalla, si hay alguna animación o retraso—, algo que el papel no puede simular sin la ayuda constante de una persona actuando de computadora. No puede responder la segunda por la misma razón que menciona el segundo error común de esta lección: "sin ayuda" exige que el usuario navegue solo, y un boceto en papel casi siempre necesita a alguien pasando las hojas.

Ejercicio 2 — Calcula el costo de una tercera pregunta. Sin ejecutar Node, si el equipo necesita responder "el orden de las pantallas tiene sentido" (que está en la lista canAnswer de ambos niveles), ¿cuánto se ahorraría en person-days eligiendo paper en vez de clickable? Expresa el ahorro como porcentaje.

Ver solución

paper cuesta 0.5 person-days, clickable cuesta 3 — la diferencia es 2.5 person-days, un ahorro de (1 - 0.5/3) × 100 = 83.3%, redondeado a 83%. Este es exactamente el tipo de cálculo que pickFidelity, en la lección 7, va a automatizar para cualquier pregunta y cualquier lista de candidatos — hoy lo hiciste a mano, con el mismo criterio.

Ejercicio 3 — Diseña un boceto en paper para una oportunidad distinta. Para la oportunidad "comparar precios entre productos similares me toma mucho tiempo" (del árbol de Mercado, módulo 3), describe en 2-3 frases qué contendría un boceto en paper para responder "¿el orden de las pantallas de comparación tiene sentido?", y explica por qué no hace falta todavía un mockup clickable para esa pregunta específica.

Ver solución

Un boceto razonable: dos o tres hojas dibujadas a mano, cada una mostrando una pantalla del flujo de comparación —la ficha de un producto con un botón "comparar", una pantalla intermedia mostrando los productos seleccionados, y una tabla final con las columnas de precio y características lado a lado—, mostradas en orden a un comprador para preguntarle si el camino tiene sentido antes de llegar a la tabla. No hace falta un clickable todavía porque la pregunta es puramente sobre secuencia y estructura —¿en qué orden aparecen las pantallas, falta algún paso intermedio?— exactamente el tipo de pregunta que está en canAnswer de paper, sin necesitar ninguna de las dos capacidades exclusivas de clickable (interacción que se sienta natural, o completar la tarea sin ayuda).

Resumen y siguiente paso

En esta lección definiste los dos primeros niveles del catálogo de fidelidad: paper (cost=0.5, responde preguntas sobre secuencia y estructura) y clickable (cost=3, seis veces más caro, responde esas mismas preguntas más dos adicionales sobre interacción). Viste, con canAnswerQuestion(), que ambos pueden responder la misma pregunta simple sobre el flujo de recomendaciones — y que pagar el costo extra de clickable solo tiene sentido cuando la pregunta específica lo exige.

Antes de avanzar deberías poder: explicar la diferencia entre paper y clickable con la analogía del storyboard y el animatic; nombrar las dos preguntas que solo clickable puede responder; y elegir, para una pregunta dada, cuál de los dos niveles alcanza sin pagar de más.

La lección 4 agrega un tercer nivel, muy distinto de los dos anteriores: el wizard-of-oz, donde el prototipo se ve y se siente completamente automático — pero hay una persona real, detrás de la cortina, haciendo todo el trabajo a mano.

Recursos

• Jakob Nielsen (Nielsen Norman Group), "Paper Prototyping: Getting User Data Before You Code" — nngroup.com/articles/paper-prototyping. El artículo de referencia sobre por qué un boceto en papel, probado con usuarios reales, encuentra problemas de usabilidad hasta cien veces más barato que corregirlos después de programar. En inglés.
• Nielsen Norman Group, "UX Prototypes: Low Fidelity vs. High Fidelity" — nngroup.com/articles/ux-prototype-hi-lo-fidelity. Ya lo viste en el módulo 1; vale la pena releerlo con el catálogo de hoy en mente — describe exactamente los tres ejes (visual, contenido, interactividad) que distinguen a paper de clickable. En inglés.
• IDEO, "Rapid Prototyping" (Design Kit) — designkit.org/methods/rapid-prototyping.html. Sobre por qué empezar con la fidelidad más baja posible —incluida la analogía del storyboard de esta lección— acelera el aprendizaje en vez de frenarlo. En inglés.