Kickoff de proyecto de diseño: qué acordar antes de diseñar
Un kickoff de diseño alinea objetivos, métricas de éxito, stakeholders y decisor antes de empezar. Qué agenda seguir, qué preparar y cómo cerrar la reunión.
¿Para qué sirve un kickoff?
Para evitar el problema más caro de un proyecto de diseño: que cada persona tenga en la cabeza un proyecto distinto. Slack lo plantea como una reunión en la que cada asistente debe salir sabiendo qué se espera de él (Slack, “How to run effective project kickoff meetings”).
Como diseñador, el kickoff es también tu primera oportunidad de hacer preguntas. Si el alcance o el objetivo no están claros aquí, lo vas a pagar en rondas de revisión, en pantallas que hay que rehacer y en discusiones que nunca se cierran.
¿Qué debe quedar acordado?
Estas son las decisiones que bloquean el trabajo si no se toman al principio:
- Objetivo. El porqué del proyecto y el problema concreto que resuelve. Umbrex recomienda objetivos SMART: específicos, medibles, alcanzables, relevantes y con plazo.
- Métricas de éxito. Cómo sabremos que funcionó. Acordarlo al principio evita discutir el resultado al final.
- Alcance y restricciones. Qué entra, qué queda fuera, con qué supuestos, presupuesto y límites de personal.
- Stakeholders y roles. Umbrex recomienda una matriz RACI: quién es responsable, quién rinde cuentas, a quién se consulta y a quién se informa.
- Decisor. Quién hace la última llamada sobre el diseño. UX Tools aconseja no ofrecer el rol de aprobador a todos los stakeholders, para evitar el “design-by-committee”.
- Cronograma y dependencias. Hitos, fechas de revisión y lo que hay que tener antes de empezar.
- Riesgos. Qué podría salir mal. Slack propone un ejercicio de pre-mortem: imaginar que el proyecto fracasó y listar por qué.
¿Qué preguntas hacer en la reunión?
UX Tools sugiere preguntar por el contexto del diseño, no solo por la solución: qué problemas ya se conocen, por qué la función se construyó así y qué clientes sería útil entrevistar. Esas preguntas te dan material para la investigación y evitan que empieces por el botón.
Algunas que funcionan bien:
- ¿Qué tendría que pasar dentro de seis meses para que digas que esto salió bien?
- ¿Qué decisiones ya están tomadas y cuáles siguen abiertas?
- ¿Quién puede decir que no a una propuesta, y en qué momento?
- ¿Qué usuarios necesitamos escuchar antes de diseñar?
¿Cómo se prepara?
Umbrex recomienda enviar antes el brief o charter, un cronograma preliminar, el análisis de stakeholders, un registro preliminar de riesgos, el organigrama del proyecto y la agenda con tiempos estimados. UX Tools propone algo más directo: llevar una propuesta de plan, no una hoja en blanco. Así la reunión discute algo concreto y no tiene que inventarlo.
La agenda de referencia de Umbrex, adaptable al tamaño del grupo:
- Bienvenida y presentaciones (5 a 10 minutos).
- Contexto y antecedentes del proyecto (10 a 15 minutos).
- Objetivos y alcance (10 a 15 minutos). Aquí caben las métricas de éxito.
- Alineación de stakeholders y expectativas (10 a 15 minutos).
- Cronograma, hitos y dependencias (10 a 20 minutos).
- Riesgos y problemas (5 a 10 minutos).
- Plan de comunicación (5 a 10 minutos).
- Próximos pasos y acciones (5 a 10 minutos).
- Preguntas o discusión abierta (5 a 15 minutos).
- Cierre (5 minutos).
Sumados, los bloques llegan a entre 70 y 125 minutos, así que en una reunión de 60 a 90 minutos conviene recortar o fusionar. UX Tools propone un orden parecido: explicar por qué están todos ahí, fijar el objetivo, aclarar roles, presentar el cronograma, definir qué es el éxito y asignar acciones al final. Los tiempos son una guía. Lo que no cambia es el orden: primero el porqué, después el cómo.
Ejemplo
Ejemplo ilustrativo: un equipo va a rediseñar el panel de administración de una plataforma de reservas. En el kickoff, el director comercial dice que el objetivo es “mejorar la experiencia”. Al hacer la pregunta de éxito a seis meses, aparece algo más concreto: reducir las llamadas al soporte por cambios de horario. Ese dato cambia el alcance: el rediseño se centra en la pantalla de horarios y deja fuera los informes. También se decide que la directora de operaciones es quien aprueba las propuestas, con plazo de dos días hábiles. Sin esa reunión, el equipo habría rediseñado todo el panel y después discutido por qué no se notó mejora.
¿Cuándo NO conviene un kickoff formal?
- En trabajos pequeños de un solo equipo. Un ajuste de texto en una pantalla no necesita 90 minutos con stakeholders. Basta un mensaje con objetivo y responsable.
- Cuando el proyecto ya está en marcha. Un kickoff a mitad de camino tiene que ser una reunión de realineación, con el alcance actual y no el original.
- Si la reunión solo sirve para presentar decisiones ya tomadas. Un kickoff sin espacio para preguntas no cumple su función, y conviene reconocerlo.
Errores comunes
- Empezar por la solución en lugar del problema.
- No definir métricas de éxito y discutirlas al final.
- Invitar a todos y que nadie decida.
- Salir sin acciones asignadas o con acciones sin fecha.
- No enviar la minuta y que cada persona recuerde algo distinto.
Cómo empezar mañana
Antes de tu próximo proyecto, escribe una página con cuatro campos: problema, objetivo, métrica de éxito y decisor. Envíala a los stakeholders con dos días de antelación y pide que la corrijan. En la reunión, revisa solo lo que no está claro. Al final, manda la minuta con las acciones, los responsables y la fecha del siguiente seguimiento. Si quieres ver cómo se conecta con el resto del proceso, revisa el proceso de diseño UX y la gestión de proyectos.
Si una parte del kickoff trata de alinear personas, la gestión de stakeholders te dará más herramientas. Y para dejar registro de lo que se decide, sirve la documentación de diseño.