SaaS Patterns

Las settings organizadas alfabeticamente o por fecha de implementación crean confusión. Agrupar por función del usuario: Perfil, Notificaciones, Seguridad, Integraciones, Facturación, Equipo. Cada grupo debe tener un proposito claro y mutuamente excluyente. Si un setting encaja en dos grupos, esta mal nombrado o mal diseñado.

Las tablas de comparación de planes con 30 filas de features no funcionan, el usuario no lee el 80% de ellas. Mostrar máximo 5-6 diferencias clave entre planes, agrupadas por valor (no por feature técnica). El plan actual debe estar claramente marcado. El CTA de upgrade debe especificar exactamente lo que se obtiene: "Desbloquear reportes avanzados" no "Upgrade a Pro".

Mostrar el consumo de recursos (almacenamiento, llamadas API, usuarios) como barras de progreso con color que cambia al llegar al 80%: verde <80%, amarillo 80-95%, rojo >95%. En el 80% mostrar una notificación no intrusiva de upgrade. En el 95% mostrar un banner persistente. Al 100% bloquear con un modal de upgrade, nunca silenciosamente dejar de funcionar.

Mostrar un feature gate (upgrade prompt) cuando el usuario intenta usar una funcionalidad bloqueada, no como banner permanente ni en el onboarding. El gate debe explicar exactamente que desbloquea el upgrade y en cuanto tiempo tendría acceso. Nunca bloquear features completamente visibles pero inaccesibles sin explicación: eso genera frustración, no conversión.

Un estado vacio (0 proyectos, 0 integraciones, 0 reportes) es la mejor oportunidad de onboarding contextual. Incluir: ilustración o icono relevante, título que describe el estado, descripción breve de que permite hacer esa sección, y un CTA primario que inicia la acción. El empty state no es un mensaje de error, es una invitación.

El default de notificaciones debe ser útil desde el primer día: activar las criticas (asignaciones directas, menciones, alertas del sistema) y desactivar las de bajo valor (resumenes semanales, actividad general del equipo). El usuario que quiere más notificaciones las activa; el que recibe demasiadas las desactiva, y ambas acciones son igualmente accesibles desde un mismo centro de notificaciones.

Una matriz de permisos con 20 checkboxes por rol paraliza la configuración inicial. Ofrecer primero 3-4 roles predefinidos con nombres en lenguaje natural (Admin, Editor, Viewer, Guest). Si el usuario necesita algo más específico, ofrecer "Rol personalizado" como opción avanzada. Mostrar ejemplos de que puede hacer cada rol en términos de tareas reales, no de flags técnicos.

Un feed de actividad que muestra "Maria edito el documento", "Maria edito el documento", "Maria edito el documento" 12 veces consecutivas es ruido, no información. Agrupar eventos repetidos del mismo usuario: "Maria realizo 12 ediciones en el Documento Q4". Priorizar eventos que requieren acción del usuario sobre eventos puramente informativos. El feed vacio es mejor que el feed con ruido.