Una página puede mostrar un botón de contacto, un formulario de edición o un cambio de plan. Para entender el trabajo que hay detrás, conviene seguir la acción hasta su resultado.
Los tres casos del laboratorio permiten hacerlo: puedes ver y probar cada resultado antes de leer las decisiones de construcción. Ladera y Cuaderno de equipos son escenarios ficticios; el constructor de briefing es una herramienta utilizable de esta web. El formulario de Ladera no envía mensajes y los pagos de Cuaderno son simulados.
Una web que ayuda a entender y consultar
En Ladera el trabajo principal es reconocer qué servicio corresponde a una necesidad. El recorrido conecta portada, catálogo, detalle, propuesta visual y contacto.
La decisión importante no es cuántas páginas hay. Es qué pregunta resuelve cada una y qué información debe conservarse al pasar a la siguiente. Si eliges un servicio y llegas a contacto sin esa elección, el recorrido añade una tarea que ya habías hecho.
El caso también permite observar contenido que una captura de portada no explica: qué incluye un servicio, qué aporta la persona y dónde termina el alcance. Los ejercicios visuales muestran decisiones y alternativas, no fotografías atribuidas a obras reales.
Para revisar esta web, sigue un servicio de principio a fin. Después prueba un formulario vacío y uno válido. La confirmación debe corresponder a lo que efectivamente ocurre en la demo.
Una aplicación que conserva el trabajo
El caso de aplicación utiliza el constructor de briefing. Aquí la persona crea y modifica información, vuelve atrás, cambia de modo y necesita encontrar su documento después.
Aparece una diferencia decisiva: el resultado tiene estado. Un dato pendiente debe seguir pendiente al exportar. Un cambio de web a aplicación no debería borrar trabajo sin avisar. Un archivo incompatible necesita una salida que conserve lo válido.
La interfaz y la estructura de datos tienen que responder al mismo acuerdo. Si la pantalla ofrece guardar y el almacenamiento falla, el mensaje debe permitir continuar o exportar. Si la importación sustituye datos, la persona necesita entender qué va a cambiar.
Puedes probarlo con un encargo propio y comparar el resultado con el documento exportado. La metodología del constructor explica las decisiones de datos y continuidad.
Un producto para varios equipos
En Cuaderno de equipos se registra información bajo organizaciones y roles. La misma acción —editar una decisión— puede estar permitida para una persona y denegada para otra.
El recorrido obliga a relacionar miembro, organización, proyecto y decisión. También aparece una operación: cambiar los roles de los personajes de prueba, observar estados, gestionar límites y decidir qué ocurre al cambiar un plan.
La demo permite reducir un plan cuando existen más proyectos que su límite. El dato no desaparece: la regla explica qué acceso se conserva y qué debe hacerse antes de crear otro. Esa continuidad forma parte del producto.
El ciclo simulado de suscripción muestra otra diferencia. Solicitar una cancelación al final del periodo y terminar el acceso son momentos distintos. Repetir un evento no debería duplicar su efecto.
SaaS describe una forma de prestar y operar una aplicación. Puede seguir utilizándose en el navegador. La diferencia respecto a la aplicación individual está en las responsabilidades y reglas adicionales, no en que la pantalla parezca más compleja.
La misma pregunta en tres implementaciones
| Pregunta | Ladera | Constructor de briefing | Cuaderno de equipos |
|---|---|---|---|
| ¿Qué completa la persona? | Entender un servicio y preparar una consulta | Crear y conservar un documento | Registrar decisiones con permisos y límites |
| ¿Qué cambia? | Selección y estado del formulario | Datos y estados del briefing | Datos de la organización y acceso |
| ¿Qué error importa? | Campo inválido o resultado mal comunicado | Guardado/importación incompatible | Acción no permitida, límite o ciclo de acceso |
| ¿Qué debe conservarse? | Contexto de navegación y consulta | Documento y decisiones | Información y continuidad del equipo |
| ¿Qué necesita quien mantiene? | Contenido, rutas y entrega real cuando exista | Esquema, almacenamiento y exportaciones | Roles, estados, administración y operación |
La tabla ayuda a localizar preguntas que una etiqueta como “web” o “plataforma” deja abiertas. Puedes utilizarla al preparar un briefing o comentar una propuesta.
Un ejercicio para guardar o compartir
Elige una de estas modificaciones:
- Ladera incorpora una agenda con disponibilidad.
- El constructor permite editar el mismo briefing entre dos personas.
- Cuaderno añade documentos adjuntos por proyecto.
Para la modificación elegida, escribe entrada, dato que cambia, resultado, permiso, error y continuidad. Después decide qué parte debe formar una primera capacidad completa y qué puede esperar.
Por ejemplo, edición compartida requiere algo más que un botón de invitar: identidad, acceso al documento, cambios simultáneos y una forma de saber qué se ha conservado. El ejercicio termina cuando puedes describir un recorrido correcto y uno que falle de forma comprensible.
El mapa de alcance permite conservar esas decisiones.
Cómo leer los casos de construcción
Cada caso reúne demo, explicación, diagrama, capturas, vídeo y acceso al origen de código o documentación. Utiliza el vídeo para orientarte y la demo para comprobar el comportamiento.
Las comprobaciones técnicas se identifican por alcance y versión. Te dicen qué se ha probado; para saber qué entienden o prefieren personas reales haría falta observar ese uso con su propio método.
Si estás preparando un proyecto, la guía de idea a aplicación o SaaS conecta estos ejemplos con la elección de solución, la primera versión y la operación. También puedes contarme la idea o los requisitos que ya tienes; no hace falta completar el ejercicio ni el mapa de alcance antes.