Roles, permisos y estados de usuario en la UI: qué mostrar cuando no se puede
Si un rol o permiso impide una acción, la interfaz puede ocultar, deshabilitar o explicar. Criterios de Nielsen, SAP y OWASP, con accesibilidad y seguridad.
¿Ocultar o deshabilitar?
Jakob Nielsen recomienda mantener visibles, como controles deshabilitados, los comandos que no están disponibles, y ocultar solo como excepción lo que el usuario nunca podrá usar, por ejemplo por su nivel de suscripción o sus permisos. Su argumento es que ocultar perjudica el descubrimiento: quien no encuentra una función puede concluir que no existe, y un control oculto no da pistas de qué lo desbloquearía. Como ejemplo cita los menús adaptativos de Microsoft Office: la gente buscaba las funciones que “desaparecían”, y versiones posteriores volvieron a mostrar todas las opciones, con las no disponibles deshabilitadas.
La pregunta práctica es: ¿esta persona podrá usar la función algún día? Si podría hacerlo con otro permiso, otro plan o más adelante, muéstrala deshabilitada. Si nunca podrá, ocultarla es razonable.
El sistema de diseño de SAP para Engagement Cloud sigue una lógica parecida: si el elemento forma parte del flujo principal, debe mostrarse deshabilitado. Ocultarlo solo se recomienda para funciones secundarias que solo ciertos usuarios usan. La diferencia importa porque un control oculto no enseña nada, mientras que uno visible deshabilitado indica que la función existe y cuándo podría estar disponible.
¿Cómo se explica el motivo?
Nielsen es directo: hay que explicar con claridad por qué la función no está disponible. Un control deshabilitado sin explicación se convierte en un callejón sin salida de comunicación. Puede hacerse con un tooltip o con un enlace visible que diga qué se necesita para acceder.
SAP propone un patrón concreto: al pasar sobre el elemento deshabilitado, aparece un tooltip que explica por qué la función no es accesible. Y cuando toda una pantalla está fuera del alcance del usuario, la pantalla muestra un estado vacío de “Permiso denegado” con un botón para volver. Eso evita redirigir a la persona a un lugar que no puede usar sin contexto. Según SAP, la descripción de esa pantalla nombra el permiso requerido; si ese dato es sensible, usa en su lugar el mensaje genérico de la sección siguiente. Para el diseño general de este tipo de pantallas, mira estados vacíos.
El texto de la explicación debe ser concreto. “Permiso denegado: Segmentos / Crear” dice qué falta. “No tienes acceso” obliga a adivinar.
¿Qué pasa con la seguridad?
Explicar el motivo puede filtrar información. Si un usuario sin permiso ve “Esta función requiere el rol de administrador de facturación”, ya sabe que existe un rol que no tiene. Si la información es sensible, SAP recomienda mostrar solo un mensaje genérico como “Acceso denegado” o “No autorizado”, sin revelar razones técnicas.
La regla práctica es distinguir dos casos. En funciones que no son sensibles, la explicación es útil y ayuda a la persona a pedir acceso. En datos sensibles o no autorizados, el mensaje debe ser genérico. Esa decisión la toma quien conoce el riesgo, no quien diseña el botón.
¿Ocultar un control equivale a protegerlo?
No. Lo que muestra la interfaz es experiencia de usuario, no seguridad. La guía de autorización de OWASP indica que los controles de acceso deben aplicarse en el servidor (o en una pasarela, o en funciones serverless), que los permisos deben validarse en cada petición y que la aplicación debe denegar el acceso por defecto. Según esa guía, las comprobaciones en el cliente pueden mejorar la experiencia, pero nunca deben ser el factor decisivo para conceder o negar el acceso.
En la práctica, diseña el estado de “sin permiso” para que sea claro y pide a ingeniería que el servidor rechace la acción aunque alguien llegue a ella por una URL directa o por la API.
¿Y la accesibilidad?
Un control deshabilitado debe seguir siendo legible y comprensible para quienes usan tecnologías de asistencia. Nielsen advierte que un estado deshabilitado demasiado tenue suele tener bajo contraste, lo que afecta a personas con baja visión, y propone un color atenuado con mayor contraste. Para los criterios de contraste de componentes, revisa la nota sobre identidad visual accesible.
Smashing Magazine señala un problema técnico frecuente: los botones deshabilitados suelen no ser enfocables con teclado. Recomienda usar aria-disabled en lugar de depender solo del atributo disabled, y advierte que pointer-events: none en CSS no impide el foco ni la navegación con teclado. Así, la persona puede llegar al control, escuchar su estado y leer la explicación.
Smashing también sugiere regiones en vivo de ARIA para anunciar cambios de estado. Si un botón se habilita después de completar un formulario, quien usa un lector de pantalla debe enterarse.
¿Qué alternativas hay al botón deshabilitado?
Vitaly Friedman advierte que un botón deshabilitado señala que algo anda mal pero casi nunca dice qué, y que a menudo no se puede enfocar con teclado. Aunque su artículo trata sobre todo de formularios, sus alternativas sirven también para permisos:
- Dejar el botón activo y explicar el error al intentar la acción, con un resumen de errores que guíe a la persona.
- Reemplazar la opción no disponible por contenido informativo, como un aviso de “avísame cuando esté disponible”.
- Mostrar una pista o un tooltip que explique el motivo.
- Ofrecer una salida, como un enlace a soporte o a quien administra los permisos.
- Reservar el estado deshabilitado para casos acotados, como evitar un doble envío.
Para permisos, la regla de Nielsen y de SAP sigue en pie: si se deshabilita, se explica.
Ejemplo
Ejemplo ilustrativo: una plataforma de facturación tiene tres roles: lectura, edición y administración. Un usuario de lectura ve el botón “Anular factura” deshabilitado, con un tooltip que dice: “Solo los administradores pueden anular facturas. Pide acceso a tu administrador.” Ese mensaje le permite entender el límite y saber a quién pedirlo. La pantalla de configuración de facturación, que no le corresponde, no aparece en su menú. Si intenta llegar a ella por una URL directa, ve un estado de “Permiso denegado” con un botón para volver, y no el contenido; además, el servidor rechaza la petición aunque la interfaz fallara. Los datos de los clientes no aparecen en ningún momento, porque el usuario no tiene permiso de verlos.
Para tu próxima pantalla: enumera los roles del producto y, para cada control, anota si el rol que no lo puede usar lo usará algún día. Esa lista decide entre ocultar y deshabilitar.
¿Cuándo NO conviene deshabilitar?
- Cuando el botón deshabilitado genera confusión porque la persona no entiende por qué no responde y no hay forma de saberlo.
- Cuando la acción es sensible y mostrarla, aunque deshabilitada, revela información.
- Cuando la desactivación es temporal por un proceso en curso. En ese caso, un estado de carga suele comunicar mejor, como explica la nota sobre estados de carga.
- Cuando la acción se puede intentar y el sistema puede dar un mensaje útil al fallar. Entonces conviene dejarla activa y explicar el error.
Errores comunes
- Deshabilitar sin explicación, dejando un control que no responde.
- Ocultar funciones que el usuario sí necesitará, lo que le impide descubrir cómo acceder.
- Mostrar el motivo técnico en datos sensibles.
- Confiar en ocultar el control como única barrera: la validación debe estar también en el servidor.
- Usar
pointer-events: nonepara simular un botón deshabilitado. - Redirigir a una pantalla sin permiso sin contexto.
- No anunciar los cambios de estado a quienes usan lectores de pantalla.
Relacionado en la wiki
Para decidir qué mostrar en los casos de error, lee patrones de estados de error; esta nota se limita a los errores por rol y permiso. Para la carga de complejidad que suelen traer los roles, ley de Tesler explica por qué no siempre conviene esconder decisiones. Y para la forma en que los lectores de pantalla leen el estado de un control, el árbol de accesibilidad es la referencia.