Tu app o web que la gente entiende a la primera

Sí, y es la razón de ser de esta fase. Se entrega un prototipo navegable: se puede clicar y recorrer como si fuera la web de verdad, antes de escribir una línea de código. Cambiar algo ahí cuesta minutos; cambiarlo cuando ya está programado cuesta días.

Cuando hay varias pantallas o un formulario largo, sí, porque es donde se decide si la gente lo entiende. En una web de pocas secciones y estructura conocida se puede ir directo. Lo que no compensa nunca es descubrir el flujo mientras se programa.

UX es el recorrido: qué pasos hay, en qué orden y qué se puede quitar. UI es lo que se ve en cada paso: tamaños, colores, botones. Una interfaz bonita sobre un recorrido mal pensado sigue perdiendo usuarios, y esa es la parte que más se descuida.

Mirando dónde se van, no opinando sobre por qué. Se identifican los pasos del recorrido y se ve en cuál se caen, y eso casi siempre señala un sitio concreto: un formulario que pide demasiado, un precio que aparece tarde o un botón que nadie encuentra. Lo contamos con más detalle en el artículo sobre webs que reciben visitas pero no generan llamadas.

Sí, antes de pasar a producción. No hacen falta muchas personas: con unas pocas intentando completar la tarea sin ayuda aparecen los problemas de verdad, y suelen ser distintos de los que discutimos internamente.

Sí, en Figma y listos para que cualquier equipo de desarrollo trabaje con ellos, sea el nuestro u otro. No queda nada atado a nosotros.

Se diseña para móvil primero, porque es la pantalla difícil: la que obliga a decidir qué es lo importante. Después se aprovecha el espacio extra del ordenador. Al revés siempre acaba en una versión móvil apretada.

Sí, y a menudo es lo más rentable. Si el problema está concentrado en un paso concreto, rehacer ese paso da más resultado que rediseñar el sitio entero, y se puede medir si ha funcionado.