Respuesta corta: un rediseño UX/UI de un SaaS se hace en cinco fases: auditoría de cada pantalla del producto actual, design system adaptado a la marca, prototipo navegable (idealmente en código), sesiones de decisión en vivo con el equipo y handoff con una especificación que desarrollo pueda construir sin interpretar. Para una plataforma de tamaño medio, el proceso dura entre 6 y 12 semanas y no obliga a parar el desarrollo del producto actual.
Rediseñar un producto que ya tiene clientes da vértigo: hay usuarios acostumbrados a la interfaz actual, un equipo de desarrollo con su propia hoja de ruta y mil decisiones heredadas que nadie recuerda por qué se tomaron. Esta guía explica cómo lo hacemos en Pleya Studio con un ejemplo real: el rediseño completo de Mainder, una plataforma SaaS de reclutamiento con IA, en el que rediseñamos 24 pantallas, añadimos 8 módulos nuevos y entregamos un prototipo navegable en código.
¿Cuándo necesita un SaaS un rediseño UX/UI?
No todo producto que "se ve antiguo" necesita un rediseño completo. Estas son las señales de que sí:
- Las ventas chocan con la percepción del producto. El equipo comercial pierde demos porque el producto parece menos potente de lo que es, o no está a la altura del precio que quieres cobrar.
- Cada funcionalidad nueva se añade "donde cabe". La navegación crece sin estructura y los usuarios no encuentran lo que ya existe.
- La interfaz es inconsistente. Tres estilos de botón, cuatro tipos de tabla, modales que se comportan distinto en cada pantalla.
- El onboarding y el soporte se comen el tiempo del equipo explicando cosas que la interfaz debería explicar sola.
- Desarrollo va lento porque cada pantalla se diseña y se construye desde cero, sin componentes reutilizables.
En el caso de Mainder concurrían varias: el producto tenía mucha más capacidad (búsqueda con IA, mensajería multicanal, analítica) de la que transmitía, y la empresa quería subir de ticket. Como nos dijo Samuel Sala, de Mainder, el objetivo era "cambiar el tipo de cliente que cerramos": que todo comunicara "ambición, claridad y autoridad".
Fase 1: auditoría del producto actual
Antes de diseñar nada, recorremos el producto entero: cada pantalla, cada botón, cada columna de cada tabla. El objetivo es entender qué hace hoy el producto y por qué, no juzgarlo.
Qué documentamos:
- Inventario de pantallas y flujos: qué existe, cómo se llega y qué tareas resuelve cada pantalla.
- Inventario de componentes: cuántas variantes hay de botones, inputs, tablas, tarjetas, modales y estados.
- Problemas de usabilidad: jerarquía confusa, acciones escondidas, textos ambiguos, estados vacíos sin ayuda, errores sin explicación.
- Datos y tareas clave: qué tiene que ver el usuario de un vistazo en cada pantalla para tomar su siguiente decisión.
- Restricciones técnicas: qué se puede cambiar sin tocar el backend y qué no.
Si hay analítica de producto, la usamos para saber qué pantallas y funciones se usan de verdad. Si no la hay, hablamos con el equipo de soporte y de ventas: saben exactamente dónde se pierde la gente.
Fase 2: design system
El design system es la base de todo lo demás: colores, tipografía, espaciado, iconos y una librería de componentes con sus variantes y estados. En un SaaS no es un lujo, es lo que permite que 24 pantallas parezcan un único producto y que desarrollo construya cada pantalla nueva más rápido.
Para Mainder adaptamos el sistema a su marca y lo diseñamos pensando en densidad de información: tablas con muchas columnas, filtros, etiquetas de estado, puntuaciones y avatares. Un sistema pensado para una web de marketing no sirve para un producto que se usa ocho horas al día.
Si quieres profundizar, tenemos una guía completa sobre cómo crear un design system para una startup.
Fase 3: prototipo navegable en código
Aquí está la principal diferencia con un proceso clásico. En lugar de entregar decenas de pantallas estáticas en Figma, construimos un prototipo navegable en código desde el primer día. En el caso de Mainder, el prototipo es una aplicación real que se puede usar en el navegador, con datos de ejemplo, en la que cada pantalla está conectada con las demás.
¿Por qué en código?
- Se prueba la experiencia real, no una imagen. Scroll, tablas con cien filas, filtros, estados de carga, hover y foco: cosas que en un mockup estático se imaginan y en código se ven.
- Las decisiones se toman antes. Un prototipo que funciona provoca comentarios concretos ("esta columna sobra", "aquí necesito filtrar por fase") que en un PDF no aparecen.
- Desarrollo recibe algo mucho más cercano al resultado final. Estructura de componentes, comportamiento y estados ya están resueltos.
- Ventas puede usarlo. Un prototipo navegable sirve para enseñar la dirección del producto a clientes e inversores antes de que esté construido.
La IA ha hecho que esto sea viable en plazos de diseño. Hoy diseñamos directamente en código con herramientas de IA que generan y modifican componentes a partir de nuestro design system, y el diseñador mantiene el criterio sobre cada detalle. Si quieres verlo funcionando, puedes probar el prototipo de Mainder.
Fase 4: sesiones en vivo
En lugar de rondas de feedback por email, trabajamos en sesiones en vivo con el equipo de producto: abrimos el prototipo, revisamos una pantalla o un flujo y decidimos en la misma reunión. Los cambios pequeños se hacen en directo; los grandes salen de la reunión con una decisión tomada.
Esto reduce semanas de idas y venidas a unas pocas sesiones, y evita el clásico problema de los rediseños: que cada persona del cliente opine por separado sobre un PDF y el diseñador tenga que reconciliar comentarios contradictorios.
Fase 5: handoff a desarrollo
El rediseño solo vale si se construye. El handoff incluye:
- El prototipo en código, que funciona como especificación viva.
- El design system documentado: tokens, componentes, variantes y cuándo usar cada uno.
- Flujos y estados: vacíos, carga, error, permisos, casos límite.
- Un plan de implantación por fases, para que desarrollo pueda ir sustituyendo pantallas sin un "big bang".
El caso Mainder: qué cambió
Mainder es una plataforma de reclutamiento con IA que reúne búsqueda de candidatos, gestión de procesos de selección, mensajería multicanal y analítica. Estas son algunas de las pantallas que rediseñamos y la idea detrás de cada una:
| Pantalla | Antes | Después |
|---|---|---|
| Home | Mucha información sin prioridad | Qué atender hoy, de un vistazo: posiciones abiertas, tareas, mensajes sin leer y candidatos estancados |
| Posiciones | Tabla densa y difícil de escanear | Todas las posiciones más claras, con pipeline, prioridad y cliente legibles |
| Proceso de selección | Fases poco visibles | Cada candidato en su fase y con su puntuación |
| Ficha de candidato | Navegar fuera de la lista | La ficha del candidato sin salir de la lista |
| AI Hunt | Resultados difíciles de revisar | Búsquedas con IA revisables de un vistazo |
| People Finder | Formularios de filtros | Describe el perfil y la IA extrae los criterios |
| Mensajería | Canales separados | LinkedIn, email y WhatsApp en una sola bandeja |
| Calendario | Agenda saturada | La agenda del equipo, más limpia |
| Analítica | Gráficos difíciles de interpretar | Gráficos que se leen a la primera |
En cifras: 24 pantallas rediseñadas, 8 módulos nuevos y 1 prototipo navegable en código, listo para que su equipo lo construya. Puedes ver el proyecto completo, con el antes y el después, en el caso de Mainder.
Cómo diseñar pantallas de un SaaS con mucha información
Algunos principios que aplicamos en todos los productos B2B:
- Cada pantalla responde a una pregunta. "¿Qué tengo que hacer hoy?", "¿cómo va esta posición?", "¿quién es este candidato?". Si no sabes cuál es la pregunta, la pantalla acabará mostrando todo.
- Jerarquía antes que decoración. Tamaño, peso y posición deben decir qué es importante. El color se reserva para estados y alertas.
- Densidad con aire. Los usuarios expertos quieren ver mucha información, pero bien alineada y agrupada.
- Acciones donde está la atención. La acción principal de cada fila o tarjeta, visible; las secundarias, en un menú.
- Estados vacíos que enseñan. Una pantalla vacía es la mejor oportunidad de explicar qué hacer.
- La IA, visible y revisable. Cuando un resultado viene de la IA, el usuario debe poder entender por qué y corregirlo. Por eso en AI Hunt y People Finder los criterios que extrae la IA se muestran y se pueden editar.
¿Cuánto cuesta y cuánto dura un rediseño UX/UI de un SaaS?
Depende del número de pantallas y de la complejidad de los flujos. Como referencia:
- Rediseño de un módulo o flujo concreto (onboarding, checkout, panel principal): de 2 a 4 semanas.
- Rediseño de un producto de tamaño medio (15–30 pantallas, design system incluido): de 6 a 12 semanas.
- Productos grandes o con varias aplicaciones: por fases, empezando por los flujos que más impacto tienen en ventas o retención.
El coste se presupuesta por alcance, no por horas abiertas. En la primera reunión revisamos el producto contigo y te proponemos el alcance mínimo que mueve la aguja.
Errores comunes en un rediseño de producto
- Rediseñar solo la "capa visual" sin revisar flujos y arquitectura de información.
- Empezar por las pantallas bonitas (dashboard, landing interna) en lugar de por las que más se usan.
- No implicar a desarrollo desde el principio, y descubrir al final que la mitad no se puede construir.
- Entregar cien pantallas en Figma sin estados ni comportamiento.
- Lanzarlo todo de golpe a usuarios que llevan años con la versión anterior, sin plan de transición.
Cómo presentar el rediseño a los usuarios actuales
Un buen rediseño puede fracasar si se lanza mal. Lo que recomendamos:
- Lanzar por fases, empezando por las pantallas con más impacto y menos riesgo.
- Avisar antes con un email o un aviso en el producto que explique qué cambia y por qué.
- Ofrecer un recorrido guiado la primera vez que el usuario entra en una pantalla rediseñada.
- Escuchar los primeros días: un canal de feedback visible y revisión diaria de los tickets de soporte.
Qué recibe el cliente al final del rediseño
- Un prototipo navegable en código con todas las pantallas y flujos rediseñados.
- El design system en diseño y en código, con tokens y componentes.
- La documentación de flujos, estados y casos límite.
- Un plan de implantación por fases priorizado por impacto.
- Acompañamiento durante la construcción para resolver dudas de desarrollo.
Una nota sobre los plazos
Los plazos de un rediseño dependen menos del número de pantallas que de la velocidad de decisión. Un equipo que decide en las sesiones en vivo puede rediseñar un producto completo en seis semanas; uno que necesita varias rondas de aprobación interna puede tardar el doble con el mismo alcance. Por eso, antes de empezar, acordamos quién decide y con qué frecuencia.
Preguntas frecuentes
¿Hay que parar el desarrollo del producto durante el rediseño?
No. El rediseño se hace en paralelo y el handoff incluye un plan para sustituir pantallas por fases. El equipo puede seguir entregando funcionalidades mientras tanto, idealmente usando ya los componentes del nuevo design system.
¿Qué diferencia hay entre un prototipo en Figma y uno en código?
Un prototipo en Figma enlaza pantallas estáticas; uno en código es una aplicación que funciona en el navegador, con interacciones, estados y datos reales o de ejemplo. El de código permite probar la experiencia real y reduce mucho la interpretación por parte de desarrollo.
¿Cuánto tarda un rediseño UX/UI de un SaaS?
Entre 6 y 12 semanas para un producto de tamaño medio con design system incluido. Un módulo concreto puede rediseñarse en 2 a 4 semanas.
¿Cómo se mide si el rediseño ha funcionado?
Con métricas definidas antes de empezar: tasa de conversión de demos, activación de nuevos usuarios, uso de funciones clave, tickets de soporte, tiempo para completar tareas y, en B2B, el ticket medio de los nuevos contratos.
¿Trabajáis con el equipo de desarrollo del cliente?
Sí. El handoff está pensado para que el equipo de desarrollo del cliente construya el producto con el prototipo y el design system como referencia, y resolvemos dudas durante la implantación.
¿Qué necesitáis para empezar?
Acceso al producto (o una demo completa), una conversación con las personas de producto, ventas y soporte, y, si existe, analítica de uso. Con eso empezamos la auditoría.
Fuentes
- Nielsen Norman Group: 10 heurísticas de usabilidad: los principios con los que se audita una interfaz.
- Nielsen Norman Group: por qué basta con probar con 5 usuarios: cinco usuarios encuentran la mayoría de problemas de usabilidad de un diseño.
- McKinsey: The business value of design: las empresas con mejores prácticas de diseño (el cuartil superior de su índice) crecieron en ingresos 32 puntos más que la media de su sector en cinco años.
- Brad Frost: Atomic Design: el método de referencia para construir design systems por componentes.
Siguiente paso
Si quieres rediseñar tu producto, aquí tienes nuestro servicio de diseño de software y SaaS. Si tu producto ya no está a la altura de lo que vendes, agenda una reunión de 30 minutos y lo revisamos juntos. También puedes ver el resultado del rediseño en el caso de Mainder o probar su prototipo navegable.
