Respuesta breve
El diseño de producto SaaS cubre los roles y permisos que deciden quién ve qué, los flujos que la gente repite a diario, y cada estado posible de una pantalla: vacía, cargando, con error, de sólo lectura, parcial, densa y desbordada. Especifica el comportamiento de los componentes y no su apariencia, cubre el teclado y la tecnología asistiva, y termina en una entrega con la que desarrollo puede construir. No cubre pantallas fuera del alcance.
Hechos verificados
- Revisión de fuentes
- 7 de septiembre de 2026
- Necesidad del lector
- requisitos de diseño de producto SaaS
Qué produce realmente el encargo
Pregunta qué entrega un proyecto de diseño SaaS y la respuesta honesta no es un número de pantallas. Es un conjunto de situaciones decididas: quién mira, qué intenta terminar y qué hace la interfaz en cada condición en la que el sistema puede estar de verdad. La pantalla llena y con el camino feliz es la que todo el mundo revisa y la que menos problemas causa después.
La mayor parte del trabajo está en los siete estados siguientes. Enumerarlos es mecánico, y ahí la preparación con asistencia de IA resulta rápida y barata. Decidir qué debe ocurrir en cada uno no lo es, porque la respuesta depende de cómo falla tu sistema y de qué pueden permitirse perder tus usuarios. Esa parte necesita a alguien que responda por la respuesta.
Vacía
Se ve así: la pantalla antes de que existan datos, con la única acción que crea el primer registro y una descripción llana de qué aparecerá después. Si se salta: las cuentas nuevas abren sobre una tabla en blanco y soporte responde la misma pregunta cada semana.
Cargando
Se ve así: un comportamiento decidido para respuestas lentas —filas esqueleto, relleno progresivo o un indicador bloqueante— y qué cambia pasado un umbral declarado. Si se salta: cada pantalla lleva el indicador que prefirió su desarrollador y lo lento se lee como roto.
Con error
Se ve así: qué ve la persona cuando una acción no se completa, qué puede reintentar y qué se conserva mientras tanto. Si se salta: un guardado fallido descarta en silencio lo que alguien escribió, que es la queja que más se recuerda.
Sólo lectura
Se ve así: la misma pantalla vista por quien puede mirar pero no cambiar, con ocultar y desactivar elegidos a propósito y no pantalla por pantalla. Si se salta: los permisos aguantan en el backend y se filtran en la interfaz.
Parcial
Se ve así: cómo la pantalla admite que una fuente falló o que una cifra es más antigua que el resto. Si se salta: una pantalla a medio cargar parece tan fiable como una completa, y la gente actúa con ella.
A escala
Se ve así: la misma tabla con mil filas —paginación o virtualización, orden, filtros y qué columnas sobreviven en una ventana estrecha. Si se salta: la maqueta funciona en la demo y no en el segundo mes.
Desbordada
Se ve así: cada etiqueta y cada valor en la longitud más larga que puede alcanzar de forma plausible, incluida una cadena traducida. Si se salta: los botones se parten, el recorte esconde lo que importaba y el arreglo llega tras el lanzamiento.
Los roles y permisos van antes que las pantallas
Una pantalla no es una sola maqueta si dos roles la ven distinta. Lista cada rol —incluidos los de operación y soporte que nunca salen en una presentación— y di para cada uno qué puede ver, qué puede cambiar y a qué no debe llegar nunca. Esa tabla decide cuántas maquetas existen de verdad, y escribirla cuesta mucho menos que descubrirlo.
Decide a propósito si una acción prohibida se oculta o se ve desactivada. Ocultar deja la interfaz más limpia y deja a la gente sin poder descubrir qué podría solicitar; desactivar explica el límite y admite que la capacidad existe. Ambas se defienden. Elegir distinto en cada pantalla por accidente es cómo un producto acaba haciendo las dos.
Los datos reales rompen maquetas que los de prueba favorecen
Pide una exportación anonimizada antes de la primera maqueta. Diez filas inventadas hacen que cualquier tabla parezca equilibrada; los registros reales traen nombres largos, campos vacíos, casi duplicados, idiomas mezclados y muchas más filas que cualquier demo. Esas son las condiciones que el diseño tiene que aguantar, y todas se conocen el primer día.
Dos números importan más que el resto: el valor más largo que un campo puede contener de verdad y cuántas filas acumula una cuenta normal en un año. Diseña contra ellos y la interfaz aguanta. Diseña contra la demo y tu primer cliente real se convierte en el primer informe de error.
Los flujos que merecen diseño son los que se repiten
La mayor parte de una jornada dentro de una herramienta son dos o tres tareas hechas una y otra vez. Ésas merecen el detalle: cada paso, cada bifurcación, qué pasa cuando alguien se interrumpe a mitad y vuelve, y cómo deshace lo que acaba de hacer. Una página de ajustes que se abre dos veces al año no pide lo mismo, y fingir que sí es cómo el alcance se duplica en silencio.
Di en voz alta qué flujos se eligieron para esa profundidad y cuáles se dejaron a propósito más ligeros. Una diferencia de acabado no declarada se lee en revisión como trabajo sin terminar, cuando en realidad fue una decisión sobre dónde poner el esfuerzo.
Especifica comportamiento, no sólo apariencia
Un componente no se describe por cómo se ve. Se describe por lo que hace: dónde cae el foco, qué significa desactivado, cuándo salta la validación y qué dice, qué pasa con una respuesta lenta y cómo se mueve el teclado por él. La apariencia se copia de una imagen. El comportamiento se inventa en el código si nadie lo escribió, y luego cambia de pantalla en pantalla.
Esto no es lo mismo que construir un sistema de diseño. Especificar el comportamiento una vez y reutilizarlo es un entregable de este trabajo; levantar un sistema que varios equipos mantienen durante años es otra decisión, con su coste y su propia pregunta de madurez, y merece plantearse aparte en vez de darse por incluida.
El teclado y la tecnología asistiva son aquí requisitos funcionales
La gente trabaja dentro de la herramienta todo el día, y eso cambia el cálculo. Operar con teclado deja de ser una casilla de cumplimiento y pasa a ser la vía rápida de quien introduce datos, y es además lo primero que se rompe cuando un control propio sustituye a uno nativo. WebAIM documenta qué comportamiento de teclado necesitan los elementos interactivos y cómo probarlo.
Los controles propios necesitan su semántica declarada, no sobreentendida. Un div con estilo que se comporta como un desplegable no comunica nada a la tecnología asistiva mientras no reciba un rol, un estado y una etiqueta, y MDN documenta qué espera ARIA de cada uno. Decídelo mientras diseñas, porque añadirlo después suele significar rehacer el componente.
Qué necesita desarrollo en la entrega
La entrega está terminada cuando alguien que no estuvo en la revisión puede construir una pantalla sin hacer una pregunta. Eso significa cada estado en su propio marco, los textos reales para el caso vacío y el fallo en lugar de relleno, espaciado y tipografía como valores reutilizables y no como números medidos sobre una imagen, y las reglas que la interfaz debe hacer cumplir escritas como reglas.
Incluye lo que a propósito no está especificado y nombra quién lo decide. Los desarrolladores tomarán esas decisiones igualmente cuando llegue la fecha; la diferencia entre una buena entrega y una mala es si sabían que las estaban tomando.
Qué cubre un plazo de 15–30 días y qué no
Un encargo de esta duración cubre la tabla de roles, los flujos repetidos de principio a fin, los estados de las pantallas dentro de esos flujos, el comportamiento de los componentes que usan y la entrega. No cubre todas las pantallas de un producto maduro, un sistema de diseño completo, la iteración continuada tras el lanzamiento ni una investigación que nadie encargó.
La pregunta honesta de alcance no es cuántas pantallas, sino cuántos estados en cuántos roles. Dos roles y ocho pantallas por siete estados es un proyecto distinto de cinco roles con esas mismas ocho pantallas, y el segundo no es un poco más de trabajo: es otro presupuesto.
Escribe las exclusiones
Lista lo que queda fuera de alcance en el mismo documento, antes de empezar. No como descargo, sino como mapa compartido de lo que existe y todavía no se hace, con la condición que devolvería cada punto al alcance. La mayoría de disputas al final de un encargo de diseño de producto no son desacuerdos sobre calidad: son dos memorias distintas de lo que estaba incluido.
Esa lista de exclusiones es además el artefacto de planificación más barato que sacarás del proyecto. Es el backlog de la siguiente fase, ya discutido y con los motivos adjuntos, que es más de lo que lleva la mayoría de backlogs.
Lista práctica
- Cada rol listado con qué puede ver, qué puede cambiar y a qué no debe llegar nunca
- Cada pantalla especificada en los siete estados, no sólo en el lleno
- Maquetas comprobadas contra una exportación real anonimizada, no contra diez filas
- Los dos o tres flujos diarios diseñados de principio a fin, interrupciones incluidas
- Comportamiento de componentes escrito: foco, desactivado, validación, respuesta lenta, teclado
- Operación por teclado y semántica asistiva cubiertas en cada elemento interactivo
- La entrega lleva estados, valores reutilizables, textos reales de vacío y fallo, y reglas
- Exclusiones listadas de forma explícita, cada una con la condición que la devolvería al alcance
Preguntas frecuentes
¿Qué se entrega realmente al final de un proyecto de diseño SaaS?
Flujos para el trabajo que se repite, cada pantalla en todos sus estados, el comportamiento de componentes por escrito, los textos de vacío y de fallo, y una entrega con la que desarrollo construye sin adivinar. El número de archivos de imagen importa mucho menos que si el comportamiento está especificado.
¿Por qué piden datos reales antes de empezar?
Porque los datos de prueba esconden los problemas. Diez filas ordenadas hacen que cualquier tabla parezca correcta; una exportación real trae nombres largos, campos vacíos, duplicados y mil entradas, y son ésos los que deciden la maqueta. Con una exportación anonimizada suele bastar.
¿Cuántas pantallas deberíamos esperar?
Menos de las que esperas, en más estados de los que esperas. Ocho pantallas por siete estados son cincuenta y seis situaciones diseñadas, y tanto el trabajo como el riesgo están en los estados. Contar pantallas subestima el encargo de forma sistemática.
¿Necesitamos un sistema de diseño para esto?
No necesariamente. Este trabajo necesita el comportamiento de componentes especificado una vez y reutilizado, que es distinto de construir y mantener un sistema de diseño. Si varios equipos van a construir en paralelo durante años, ésa es una pregunta aparte que merece hacerse sola.
¿Qué conviene preparar antes de que empiece el proyecto?
Una exportación de datos anonimizada, la lista de roles con sus permisos, las dos o tres tareas que la gente hace a diario, y alguien que pueda responder qué debe pasar cuando una acción falla. Esas cuatro cosas desbloquean casi todo el encargo.