El kickoff termina con un «ya nos conocemos» y un Figma vacío. A la tercera semana alguien pregunta el alcance y la respuesta es un hilo de mails. Sin discovery el proyecto no arranca tarde: arranca inventado. El alcance se decide a mitad, cuando cambiar de opinión ya cuesta semanas.
Un discovery proyecto web no es una ronda de cafés ni un taller eterno. Es un tramo corto, con dueño y con salida: decisiones escritas, mapa de lo que entra y de lo que no, y un alcance que se puede presupuestar sin magia. Si no sale eso, no has hecho discovery. Has retrasado el diseño.
Este artículo fija qué tiene que salir de las primeras semanas de un proyecto de desarrollo web a medida, quién tiene que estar y cómo no convertirlas en reuniones que no cierran nada. El mismo criterio que usamos en Truman antes de abrir producción.
Qué es un discovery proyecto web (y qué no es)
Discovery es el tramo en el que el problema se vuelve trabajo. No es research académico. No es «alinearnos». Es responder, por escrito, a cuatro preguntas: qué problema de negocio resuelve la web, para quién, qué tiene que existir el día del launch y qué queda fuera a propósito. Si una de las cuatro queda en el aire, el desarrollo va a rellenar el hueco con suposiciones.
Tampoco es un brief de diseño disfrazado. El brief de un proyecto UX/UI es un entregable de discovery, no el discovery entero. En un proyecto web a medida hay que decidir además CMS, integraciones, idiomas, quién edita y qué pasa con el SEO de la web actual. Eso no cabe en una lista de pantallas.
En Truman el discovery dura lo que haga falta para cerrar esas decisiones —habitualmente dos o tres semanas, no un trimestre— y tiene fecha de cierre. Si a esa fecha no hay mapa ni fuera de alcance, no «seguimos descubriendo». Paramos y nombramos el bloqueo. Un discovery sin fin es un proyecto sin contrato.
Qué tiene que salir de las primeras semanas
Las primeras semanas no se miden en horas de call. Se miden en artefactos. Si no puedes señalar un archivo, no salió. Esto es lo que pedimos que exista antes de diseñar a producción.
En Clínica Eleya el discovery no podía ser una home abstracta. Había que cerrar especialidades, equipo, cita y el tono de un centro médico: qué se puede decir, qué no, quién edita tratamientos. En Grupo Candela el entregable crítico era el mapa del grupo: líneas, marcas internas, qué vive en la corporativa y qué no. Sin eso, el diseño habría pintado una landing de un solo producto.
El cierre del discovery es un alcance que se puede presupuestar. Si quieres entender qué mueve el número después, el desglose está en cuánto cuesta una web a medida. Discovery barato que deja el alcance abierto sale caro en desarrollo. Discovery que cierra el fuera de alcance es la partida que evita el change request eterno.
Cómo no convertir las primeras semanas en reuniones eternas
El discovery se pudre cuando la reunión es el producto. Se agenda otra call «para alinear» porque la anterior no decidió. La regla es al revés: cada sesión tiene una pregunta que cerrar y un entregable que actualizar. Si no hay pregunta, no hay reunión. Hay un comentario en el documento.
| Hábito | Efecto | Sustituto |
|---|---|---|
| Call semanal sin orden del día | Repite dudas | Una pregunta por sesión, decisión por escrito |
| Todos en todas las calls | Cara pero lenta | Dueño por tema: oferta, técnico, contenidos |
| Actas que nadie firma | No hay alcance | Documento vivo con «cerrado / abierto / fuera» |
| Workshops de medio día | Útiles una vez | Un taller de mapa; el resto, asíncrono |
| Esperar a tener «todo» | No arranca | Cerrar el día uno; listar lo aplazado |
Dos o tres sesiones bien preparadas superan a ocho calls flojas. La preparación es trabajo vuestro tanto como del estudio: llegad con la oferta actual, con accesos a analítica y con quién decide. Si el decisor no está, la sesión es un ensayo. En Truman cancelamos antes que fingir un cierre.
Si cancelas todas las reuniones de las próximas dos semanas y solo queda un documento, ¿alguien podría diseñar con eso —o seguiríais necesitando «otra call para alinear»?
Quién tiene que estar (y quién sobra)
Discovery no es un town hall. Hace falta quien decide la oferta, quien va a editar la web y quien conoce las integraciones. Sobra quien opina de color en la semana uno. Si marketing, ventas y dirección no se ponen de acuerdo sobre el objetivo, eso es el trabajo del discovery —no un problema que se le pasa al diseñador en la semana seis.
La decisión de panel a medida o WordPress es de este tramo, no de «ya veremos». El criterio —quién edita, qué tan a medida es el contenido, qué coste de mantenimiento aceptáis— está en CMS a medida frente a WordPress. Si se aplaza, el diseño asume un CMS y el desarrollo otro.
Qué pasa si te saltas el discovery
Te lo saltas de dos maneras. Una: pides presupuesto con un PDF de dos páginas y quieres diseño la semana siguiente. Dos: pagas «fase de inmersión» y la usas para opinar de referencias. En los dos casos el alcance se escribe en los comentarios de Figma. Cada comentario es un requisito que no estaba. Cada requisito nuevo es una semana que nadie presupuestó.
Cómo lo cerramos en Truman
En València y fuera, el discovery de un proyecto web en Truman tiene dueño en el estudio y fecha. No es un extra opcional para quien «aún no lo tiene claro»: es el suelo. Salimos con un documento que diseño y desarrollo pueden usar el lunes siguiente sin preguntar «¿esto iba?».
Discovery no es hablar más. Es salir con un alcance que se puede señalar. Si a las tres semanas solo hay actas, no has descubierto nada. Has aplazado el conflicto.
Antes de dar por cerrado el discovery
- ¿Hay una frase de objetivo que dirección y ventas firman igual?
- ¿Existe un mapa de páginas y flujos con qué entra el día uno y qué queda fuera?
- ¿Están nombrados usuarios, roles de edición y quién aprueba contenidos?
- ¿Las integraciones (CRM, cita, analítica, ERP) tienen sí/no y dueño, no un «ya veremos»?
- ¿La decisión de CMS está tomada con criterio, no aplazada al desarrollo?
- ¿Cada reunión de discovery tuvo una pregunta que cerrar y un documento actualizado?
- ¿Hay un decisor con nombre que puede decir «esto no entra»?
- ¿El alcance se puede presupuestar sin inventar partidas genéricas?
Preguntas frecuentes sobre el discovery de un proyecto web
¿Cuánto tiene que durar el discovery de un proyecto web?
El que usamos en Truman cabe en dos o tres semanas si el decisor está y el material llega. Un grupo con varias marcas o una web con integraciones pesadas puede pedir un poco más. Si dura meses, ya no es discovery: es un proyecto sin alcance.
¿Puedo pedir presupuesto sin haber hecho discovery?
Sí. El presupuesto honesto en ese punto es un rango o una fase de discovery cerrada. Un número cerrado sobre un PDF de dos páginas es una apuesta. Luego alguien la paga.
¿Discovery y brief UX/UI son lo mismo?
No. El brief es un entregable: usuarios, objetivos, restricciones de interfaz. El discovery cubre además negocio, CMS, migraciones e integraciones. El brief solo no sostiene un desarrollo a medida.
¿Quién tiene que venir a las sesiones?
Quien decide la oferta, quien edita y quien conoce los sistemas. No hace falta el equipo entero. Hace falta que las decisiones no se reabran la semana siguiente porque «Fulano no estaba».
