Antes de construir la web, dibuja qué tiene que pasar

01 / LA IDEA EN UN MINUTO

Una web organiza una experiencia.

Una página puede tener colores cuidados y aun así dejar a una persona sin saber qué hacer. El diseño no empieza en la elección de una plantilla. Empieza en la situación de quien llega: qué busca, qué sabe ya y qué necesita resolver.

Dibujar el recorrido ayuda a conectar pantallas, información y acciones. Puedes descubrir que pides una reserva antes de explicar la duración, que no hay forma de volver atrás o que el formulario termina sin confirmar nada. Son problemas que un boceto puede hacer visibles antes de programar.

El dibujo no elimina la necesidad de probar. Lo que parece evidente al equipo puede resultar confuso a otra persona. Su ventaja es que resulta fácil cambiarlo: todavía no has convertido cada suposición en horas de construcción.

02 / LA SEMILLA DE ESTA IDEA

Poner en papel lo que parece claro en la cabeza.

En el LP de creación de una tienda online, Iván propone definir la finalidad de la web, hacer croquis y representar el paso a paso del usuario antes de abrir el editor. Utiliza VelaMarket para explicar esa forma de trabajar.[1]

El original insiste mucho en preparar el diseño. Conservamos esa intención, pero no sus porcentajes como si fueran mediciones: no hay una regla universal que diga qué parte exacta del trabajo debe ocurrir antes del editor.

También ajustamos la idea de dejarlo todo perfectamente cerrado. Diseñar antes ayuda a descubrir ambigüedades; observar una prueba puede revelar otras nuevas. El recorrido se revisa, no se convierte en una promesa de que ya conocemos cada necesidad.

La expansión cambia el foco de llevar al visitante por un camino perfecto a ayudarle a tomar una decisión informada. La acción que interesa al negocio debe tener sentido para quien la realiza, sin ocultarle información o dificultarle otras opciones.

03 / DIBUJA DECISIONES, NO SOLO CAJAS

Incluye lo que pasa antes y después.

El Service Manual de GOV.UK recomienda usar prototipos para contrastar las suposiciones más importantes y situar la parte digital dentro del recorrido completo del usuario. No exige construir toda la experiencia para aprender sobre un punto crítico.[2]

En una web de servicios, el recorrido puede empezar en una recomendación y terminar en una llamada, no dentro de la pantalla. Si el formulario promete respuesta y nadie se encarga de contestar, el diseño visual habrá resuelto solo una parte.

Para cada paso, escribe qué pregunta tiene la persona, qué información necesita y qué acción puede realizar. Una llamada a la acción debe describir con claridad lo que ocurrirá. Solicitar información y comprar ahora no generan la misma expectativa.

Incluye estados que suelen olvidarse: falta información, no hay plazas, el envío falla o la persona quiere corregir un dato. No necesitas dibujar todos los casos posibles de golpe, pero sí los que podrían bloquear la tarea principal o crear una promesa falsa.

04 / UNA INSCRIPCIÓN QUE TERMINA DEMASIADO PRONTO

El formulario no es el final del servicio.

Imagina una web para un taller de cerámica. Es un ejemplo hipotético. El primer boceto tiene una fotografía, una descripción y un botón de inscripción. Parece suficiente hasta que alguien pregunta si el precio incluye materiales y si la plaza queda confirmada al enviar sus datos.

El equipo añade esa información y representa el siguiente paso. Decide distinguir una solicitud de plaza de una reserva confirmada. La pantalla final explica qué ha ocurrido, cuándo habrá respuesta y cómo contactar si no llega.

Al enseñarlo a otra persona descubre una duda más: necesita saber si puede cambiar de fecha. El equipo no inventa una política para completar el diseño. Primero acuerda cómo podrá gestionar ese cambio y después lo explica.

La prueba no demuestra todavía que el taller vaya a venderse. Sí ayuda a comprobar si la propuesta y el proceso se entienden. La viabilidad del servicio y la facilidad para usar la web son preguntas relacionadas, pero diferentes.

05 / LLÉVALO A TU PROYECTO

Prueba el recorrido antes de pulirlo.

Elige una tarea principal de tu web y describe desde dónde llega la persona. Dibuja los pasos mínimos para resolverla, incluyendo la confirmación y cualquier acción que deba realizar vuestro equipo después.

Escribe el contenido esencial con palabras comprensibles. Los textos provisionales genéricos pueden ocultar problemas reales: no es lo mismo dibujar un bloque de información que explicar de verdad precio, alcance o condiciones.

Enseña el boceto y pide a alguien que intente completar la tarea. Observa qué interpreta y dónde duda sin explicarle cada pantalla por adelantado. Si necesita tu narración para entenderlo, has encontrado algo que revisar.

Construye con lo aprendido y vuelve a comprobar en móvil, con el contenido real y los estados necesarios. El boceto facilita la decisión; la web terminada todavía debe demostrar que permite realizar la tarea de forma comprensible.

06 / APRENDIZAJES

Aprendizajes

• El diseño empieza en la tarea. Define qué necesita resolver la persona.
• Un boceto hace visibles supuestos. No equivale a una solución validada.
• El recorrido supera la pantalla. Incluye respuesta y trabajo del equipo.
• Las palabras también son diseño. Explica qué ocurrirá al actuar.
• Probar evita adivinar. Observa dudas antes de pulir detalles.

07 / PREGUNTAS DETONANTES

Preguntas detonantes

1. ¿Qué busca alguien cuando llega a esta página?
2. ¿Qué información necesita antes de actuar?
3. ¿Qué prometemos después del formulario?
4. ¿Qué ocurre si algo falla o no hay disponibilidad?
5. ¿Qué parte solo se entiende cuando la explicamos nosotros?

08 / CONEXIONES

Para seguir aprendiendo