Diseño
Product box y maquetas: qué, cómo y con qué herramientas
El curso pide un product box en la inception (Fag-1) y maquetas de calidad en la presentación al cliente (Fag-2). Esta página explica qué debe haber en cada uno, cómo hacerlos paso a paso, qué herramientas podéis usar (Figma, Google Stitch...) e incluye un ejemplo completo.
El product box: la visión en una caja
Imaginad que vuestro producto se vende en una estantería. El product box es la caja: tiene un frente, un reverso y poco espacio para convencer. Os obliga a decidir qué es, para quién es y por qué alguien lo querría. Viene de los Innovation Games y es una pieza del Agile Inception Deck.
Pedalea con cabeza.
Gratis- Estaciones en directo
- Rutas menos contaminadas
- Insignias por pedalear
- Ves dónde hay bicis ahora
- Eliges la ruta más limpia
- Ganas insignias y retos
«Ahora sé si hay bici antes de salir de casa.»
Marta, usuaria de prueba (cita inventada)
Frente
- Nombre y logo fáciles de recordar.
- Eslogan: una frase que dice el beneficio.
- Una imagen fuerte que muestre el producto en uso.
- 3 o 4 funcionalidades, escritas como beneficios para el usuario, no como tecnología.
Reverso
- Descripción corta y la lista de funcionalidades clave.
- Capturas o ilustraciones de la interfaz.
- Requisitos: plataforma, precio, datos que usa.
- Opcional: una cita de usuario o un premio (si son inventados, decidlo).
Qué se valora: visión clara, las 3 o 4 funcionalidades más representativas y diseño atractivo. Tiene que ser coherente con el elevator pitch y con la NOT list. En la entrega puede ser un enlace a un recurso externo.
Cómo hacer un product box, paso a paso
Una tarde de equipo basta. Hacedlo juntos: la conversación vale tanto como la imagen.
- Escribid la visión en una frase: «Para [quién] que [necesidad], [producto] es un [categoría] que [beneficio]. A diferencia de [alternativa], nuestro [diferencia]».
- Elegid 3 o 4 funcionalidades que hagan comprar el producto. Si tenéis diez, todavía no habéis decidido qué es.
- Ponedle nombre, logo y eslogan. Comprobad que no existe ya en Google Play ni como dominio.
- Buscad una imagen fuerte: una captura, una ilustración o una foto. Si es de terceros, comprobad la licencia y citad la autoría.
- Montadlo en Canva, Figma, Google Slides o PowerPoint: un rectángulo vertical para el frente y otro para el reverso; si queréis el efecto caja, añadid un lateral o una plantilla de maqueta de caja.
- Probad los 5 segundos: enseñadlo a alguien que no conozca el proyecto y pedidle que os diga de qué va. Si no acierta, simplificad.
Errores típicos
- Demasiadas funcionalidades, o funcionalidades escritas como tecnología («API REST con Spring»).
- No dice qué lo hace distinto de lo que ya existe.
- Texto demasiado pequeño o con poco contraste: en la estantería no se leería.
- No cuadra con el elevator pitch ni con la NOT list: se valora la coherencia entre los tres.
- Logos o imágenes de otras marcas sin permiso.
Las maquetas: ver el producto antes de hacerlo
Una maqueta enseña lo que verá el usuario sin escribir código. Sirve para poneros de acuerdo como equipo, para vender el producto al cliente y para que quien programa sepa qué debe construir. En Fag-2 se piden las más críticas; después, maquetad lo que el sprint va a construir.
| Nivel | Qué es | Para qué sirve | Tiempo |
|---|---|---|---|
| Boceto | Dibujo a mano o con Excalidraw. | Explorar ideas y discutirlas con el equipo. | Minutos |
| Wireframe | Cajas y etiquetas, sin color ni tipografía final. | Decidir la estructura y la jerarquía de cada pantalla. | Decenas de minutos |
| Maqueta de alta fidelidad | Colores, tipografía y contenido reales. | Presentar al cliente y guiar el desarrollo. | Horas |
| Prototipo clicable | Maquetas enlazadas que simulan el recorrido. | Probar el flujo con personas reales. | Horas o un día |
Una buena maqueta
- Contenido real (nombres de estaciones, precios, fechas), no «lorem ipsum».
- El recorrido completo de las historias críticas, no pantallas sueltas: haced un mapa de navegación.
- Los estados que cambian la pantalla: vacía, cargando, error y éxito.
- Componentes y estilo coherentes: mismos colores, tipografía, espacios y botones en todas las pantallas.
- Móvil primero: zonas táctiles de al menos 48 dp y texto con contraste suficiente (WCAG AA, 4,5:1).
- Una etiqueta con la historia (US-12) en cada pantalla: así se ve qué cubre cada maqueta.
Herramientas para hacer maquetas
Ninguna herramienta es obligatoria. Elegid una que todo el mundo pueda editar y exportar. Los planes y límites cambian a menudo: mirad las condiciones actuales antes de decidir.
| Herramienta | Qué es | Va bien para | Coste y notas |
|---|---|---|---|
| Figma | Diseño colaborativo en el navegador, con componentes y prototipos clicables. | Maquetas de alta fidelidad y prototipos en equipo. | Plan gratuito; para estudiantes hay un plan educativo (hay que verificarlo). |
| Penpot | Alternativa de código abierto a Figma, en el navegador. | Lo mismo que Figma, sin depender de un proveedor. | Gratuito. |
| Google Stitch | Herramienta de IA de Google Labs que genera pantallas a partir de un texto o una imagen. | Un primer borrador rápido y variantes de una pantalla. | Gratuito en versión experimental; los límites pueden cambiar. Exporta a Figma o a código. |
| Balsamiq | Wireframes con aspecto de boceto. | Discutir la estructura sin distraerse con el diseño. | De pago, con prueba. |
| Excalidraw, papel | Dibujos a mano alzada. | Bocetos en minutos, en la reunión. | Gratuito. Haced una foto y adjuntadla. |
| Canva, Slides | Editores de diseño y de presentaciones. | El product box y los gráficos de las diapositivas. | Plan gratuito con plantillas. |
Generar maquetas con Stitch (y otras IA)
Stitch no sustituye al diseño: os da un primer borrador en segundos que luego tenéis que revisar. La clave es lo que le pedís.
- Preparad la historia: qué dato se muestra, qué acciones hay y qué estados (vacío, error).
- Escribid el prompt con: plataforma, finalidad de la pantalla, quién la usa, contenido concreto, componentes, estilo y restricciones.
- Generad pantalla a pantalla y repetid el mismo estilo (colores, tipografía) en cada prompt para que sean coherentes.
- Iterad con cambios pequeños: «botones más grandes», «muestra el estado vacío».
- Revisadla contra la historia: ¿el texto es real? ¿Ha añadido funciones que no tenéis? ¿Se lee bien?
- Exportad a Figma o como imagen y guardad el prompt para la memoria.
Un prompt de ejemplo
Los prompts suelen funcionar mejor en inglés; el texto que pidáis para la pantalla puede ser en catalán o castellano.
Mobile app (Android), screen "Nearby stations".
Users: people in Barcelona who ride Bicing.
Show: a map with station pins coloured by availability, and a bottom sheet for the selected station
(name "Pl. Catalunya", 7 free bikes, 13 free docks, a green "Get directions" button).
Style: clean light theme, rounded cards, green accent #58cc02, 48 dp touch targets, high contrast.
Text in Catalan. Do not add features that are not listed.Cuidado con las IA
- Añaden cosas. Si aparece una función que no está en el backlog, borradla o cread una historia.
- Pueden ser incoherentes entre pantallas: rehacedlas con el mismo tema.
- No tienen criterio de accesibilidad: comprobad el contraste y el tamaño de los botones.
- No subáis datos confidenciales ni logos de otras marcas.
- Si las usáis, explicad el proceso en la memoria, igual que con los asistentes de código.
Ejemplo: del boceto a la maqueta
La misma pantalla de Bici Verda en tres niveles de fidelidad. Cada paso responde a una pregunta distinta: qué hay, dónde va y cómo se ve.
¿Qué hay?
Un mapa, las estaciones y una ficha con un botón. Cinco minutos con lápiz, para discutirlo en equipo.
¿Dónde va cada cosa?
Cajas y etiquetas: cabecera, mapa, ficha de la estación y un único botón principal. Todavía sin color.
¿Cómo se ve?
Colores, tipografía y contenido real: Pl. Catalunya, 7 bicis, 13 huecos. Etiquetada con la historia US-12.
Fijaos en que la maqueta final lleva la etiqueta de la historia (US-12), contenido real y un único botón principal.
Ejemplo: los cuatro estados de una pantalla
Una maqueta completa no es solo el caso feliz. Esta es la pantalla de estaciones cercanas cuando no hay nada cerca, mientras carga, cuando falla la red y cuando todo va bien. Diseñadlos todos antes de programar.
Vacío¿Qué ve quien no tiene nada cerca?
Cargando¿Qué pasa mientras llegan los datos?
Error¿Y si falla la red?
ÉxitoEl caso feliz, con confirmación.
Cómo lo entregáis
El product box va a la inception 1 y las maquetas críticas, a la presentación y a la memoria de la inception 2.
- Guardad las imágenes en el repositorio, por ejemplo en
docs/mockups/US-12_estaciones-cercanas.png, y enlazad el archivo fuente (Figma en modo solo lectura). - Enlazad la maqueta a la historia de Taiga para que quien la implementa la tenga a mano.
- En la memoria, una imagen por pantalla con un pie que explique qué muestra.
- Para la presentación, exportad a PNG al tamaño de la diapositiva: no hagáis capturas de pantalla borrosas.