Estimar trabajo de diseño: apetito, tallas y tiempo fijo

¿Por qué es difícil estimar diseño?

Porque el trabajo de diseño es exploratorio. Nadie sabe de antemano cuántas versiones hará falta hasta que aparecen los problemas. Además, el esfuerzo de diseño y el de desarrollo no siguen la misma curva. Un cambio visual puede ser rápido de dibujar, mientras que la parte de datos o de integración que lo sostiene puede tardar semanas.

NN/g lo resume en su artículo sobre capacidad de UX: el esfuerzo de UX puede estar muy desconectado del esfuerzo de desarrollo. Por eso estimar el diseño con la misma lógica que el código suele dar cifras que no sirven para planificar.

¿Por qué le importa a un diseñador junior?

Porque tarde o temprano alguien te preguntará “¿cuánto tardas?”. Si respondes con una cifra precisa sin base, la cifra se convertirá en un compromiso. Si respondes “no sé”, el equipo pierde la posibilidad de planificar. Hay un punto intermedio, y es el que conviene aprender pronto.

Además, la estimación es una conversación sobre alcance. Cuando una tarea se alarga, la pregunta útil no es “¿por qué tardaste más?”, sino “¿qué parte del alcance podemos recortar?”.

¿Qué es el apetito y en qué se diferencia de la estimación?

Shape Up, el método de Basecamp, separa dos ideas. La estimación predice cuánto tardará algo. El apetito indica cuánto tiempo merece un problema. Para Basecamp, el apetito es completamente distinto de una estimación: una estimación empieza con un diseño y termina con un número, mientras que un apetito empieza con un número y termina con un diseño.

La consecuencia práctica es que se fija el tiempo y se varía el alcance. Shape Up llama a esto “tiempo fijo, alcance variable” y lo considera clave para definir y entregar proyectos con éxito. En lugar de preguntar cuánto costará construir todo, el equipo pregunta qué versión cabe en el tiempo que merece el problema.

Para un diseñador, esto cambia el trabajo. Ya no se trata de dibujar todo lo que se pidió, sino de encontrar la versión del diseño que resuelve el problema dentro del tiempo acordado.

¿Cómo se estima en la práctica?

1. Empieza con tallas, no con horas. En su encuesta, NN/g encontró que muchos profesionales de UX prefieren estimar su esfuerzo por separado del equipo de desarrollo, y que las tallas de camiseta (S, M, L, XL) son una forma habitual de hacerlo sin afectar la velocidad del equipo.
2. Estima también el trabajo de datos e integración. Un diseño que depende de datos nuevos o de una API tiene un esfuerzo que no aparece en el mockup. Pregunta qué sostiene la pantalla antes de estimarla.
3. Usa una escala coherente. NN/g señala que no importa qué escala uses, siempre que la mantengas. Cambiar de escala a mitad del proyecto impide comparar.
4. Espera varios intentos. Según NN/g, los equipos de UX suelen necesitar varias rondas antes de que las estimaciones se vuelvan precisas.
5. Revisa el pasado. Compara cada estimación con el esfuerzo real y busca patrones de error. Si siempre subestimas las pruebas con usuarios, eso ya es información útil.

Las ceremonias de equipo, como la planificación o la revisión de sprint, son el lugar natural para hacer esta comparación. El artículo sobre ceremonias de equipo describe cómo se estructuran.

¿Cómo estimar sin romper al equipo?

NN/g advierte de un riesgo: los puntos de UX separados pueden afectar a la cohesión del equipo, y UX puede acabar percibido como una unidad de trabajo aparte. Su recomendación es integrar con el tiempo la estimación de UX en el proceso de estimación del equipo principal.

En la práctica, eso significa que el diseñador participe en la misma conversación que los desarrolladores, aunque la escala sea distinta. Una estimación de diseño que nadie discute con ingeniería no sirve para planificar.

¿Cuándo NO conviene estimar?

• Cuando el problema todavía no está definido. Estimar algo que no entiendes solo produce cifras arbitrarias.
• Cuando el trabajo es crítico para la seguridad o está sujeto a plazos legales. En esos casos el alcance suele ser fijo y el tiempo también. No es el escenario de tiempo fijo de Shape Up.
• Cuando el equipo convierte la estimación en una medida de desempeño. Eso desincentiva a estimar con honestidad. Para ese tema, el artículo sobre planes de carrera y evaluación de desempeño es más útil.

Ejemplo

Ejemplo ilustrativo: un equipo recibe una petición para rediseñar el panel de reportes.

• Primera estimación: el diseñador dice “M”, porque son cuatro pantallas nuevas.
• Pregunta de desarrollo: el panel necesita datos de un servicio que todavía no existe. El esfuerzo de datos es “L”.
• Decisión: el equipo fija un apetito de tres semanas. Dentro de ese tiempo entra el rediseño de dos pantallas y la integración de los datos básicos. Las otras dos pantallas pasan al siguiente ciclo.
• Revisión: al final, el equipo compara: el diseño tardó lo previsto, pero la integración tardó el doble. La siguiente vez, esa integración se estima antes.

Lo que el equipo aprende no es a predecir mejor, sino a recortar alcance a tiempo.

Para el lado financiero de estas decisiones, el artículo sobre gestión de presupuesto ayuda a conectar el esfuerzo con el coste.

Errores comunes

• Estimar el diseño sin incluir el trabajo de datos o de desarrollo que depende de él.
• Usar la escala de puntos del equipo de desarrollo para UX, cuando no encaja.
• Pedir precisión desde el primer intento.
• Estimar por separado de forma tan estricta que el equipo de UX queda aislado.
• Confundir el apetito con una promesa de entrega.
• No comparar nunca la estimación con el esfuerzo real.

Fuentes

• Basecamp, Shape Up: Set Boundaries (capítulo 3)
• Nielsen Norman Group, UX User Stories
• Nielsen Norman Group, Tracking UX Capacity
• Nielsen Norman Group, Return on Investment for Usability