Que tu producto avance.

Depende de cuánta gente construya producto. Con un equipo pequeño y un producto acotado, rediseñar las pantallas resuelve; cuando hay varios equipos, plataformas o marcas, las pantallas vuelven a divergir a los pocos meses sin reglas comunes. La señal suele ser encontrarse discutiendo por segunda vez la misma decisión.

Sí, y cuanto antes mejor. Las decisiones de diseño se revisan con desarrollo mientras se toman, no cuando ya están cerradas, porque un componente que no se puede construir con el stack que hay no es una solución. La entrega incluye las especificaciones y los estados de cada pieza, no solo las pantallas bonitas.

Se empieza con lo que ya existe, que casi siempre es más de lo que parece: analítica, tickets de soporte, grabaciones de sesión, lo que sabe el equipo comercial. Con eso se formulan las hipótesis y se decide qué merece una entrevista o una prueba de uso. No hace falta un programa de investigación montado para tomar mejores decisiones que las actuales.

Es el caso habitual. Se ordena qué cambia primero según impacto y riesgo, de modo que el producto siga funcionando mientras se rediseña por partes. Un cambio total de golpe suele ser peor negocio: concentra el riesgo y deja a los usuarios sin referencias de un día para otro.

Porque antes de diseñar se acuerda qué se va a mirar: conversión, tiempo hasta completar una tarea, incidencias de soporte, adopción de una funcionalidad. Sin ese acuerdo previo la discusión posterior se vuelve una cuestión de gusto, y entonces gana quien más manda, no quien tiene razón.