Qué ocurre realmente, y en qué orden

Una llamada corta o un brief por escrito, que cubra qué hace el producto, para quién es, qué está ya decidido y qué aspecto tiene lo «terminado». La parte más útil suelen ser las restricciones: el plazo que es real, la persona que tiene que aprobar, la decisión técnica ya tomada.

Si un proyecto no encaja —el alcance equivocado, el stack equivocado, o un trabajo que necesita un especialista que no soy— este es el momento en que se dice. Es un lugar más barato para descubrirlo que la tercera semana, y pasa lo bastante a menudo como para mencionarlo.

El brief se convierte en un alcance por escrito: qué se incluye, qué queda explícitamente fuera, las fases, los puntos de revisión, los hitos de pago y el calendario. Se presupuesta como un precio cerrado frente a ese alcance, en lugar de como una estimación por horas.

Los cambios de alcance son normales y se gestionan como un cambio por escrito tanto del alcance como del precio. La alternativa —absorberlos en silencio y discutirlo al final— es la forma en que los proyectos terminan mal para el lado que menos dispuesto está a tener esa conversación.

Flujos y wireframes de baja fidelidad antes de dar estilo a nada. Dibujar cada pantalla y cada punto de decisión de principio a fin es lo que saca a la luz las ramas que nadie contempló: el pago fallido, la invitación caducada, las dos personas editando el mismo registro.

Esta etapa es deliberadamente gris y de aspecto inacabado, porque un mockup pulido cambia la conversación. Enseña una pantalla acabada y el feedback será sobre el color del botón; enseña un wireframe y el feedback será sobre si ese paso debería estar ahí siquiera.

Diseño de alta fidelidad en Figma sobre una retícula, una escala tipográfica y un sistema de espaciado, construido como componentes con tokens desde el principio, en lugar de ordenarlo dentro de ellos después.

Los estados se diseñan aquí, no se dan por supuestos: vacío, cargando, error, permiso denegado, y la versión de cada pantalla en la que el contenido es el doble de largo que el marcador de posición. La revisión ocurre en cada etapa, en lugar de en una sola ronda al final, para que el feedback llegue mientras todavía es barato actuar sobre él.

En los proyectos que continúan hasta el código, el diseño aprobado se construye como un front end responsive —React y Next.js, Webflow o Framer, según lo que fijara el alcance—. El componente de Figma se convierte en el componente en código y el design token se convierte en el token de código, de modo que una decisión sigue siendo una sola decisión.

El rendimiento y la accesibilidad forman parte de la construcción, no de una pasada al final: renderizado estático donde el contenido lo permite, imágenes dimensionadas y servidas correctamente, marcado semántico, navegación por teclado, foco visible y un contraste que aguanta. Incorporarlos a posteriori es reescribir el marcado.

QA en distintos navegadores y dispositivos frente al diseño, un mapa de redirecciones aplicado allí donde las URL han cambiado, y una entrega de los archivos, el código y las cuentas —todo en tu propiedad, sin que nada dependa de que yo siga involucrado—.

La entrega se documenta para que tu equipo pueda mantener y hacer crecer el sitio con confianza, con componentes limpios y una estructura clara.