Modales en diseño UX: patrones, antipatrones y cuándo usarlos

Un modal puede parecer que es algo sencillo de diseñar: sencillamente es un elemento con contenido que aparece por encima del contenido de la página web o de la aplicación.

Como siempre, no es tan fácil como parece. Hay detalles que, si no se tienen en cuenta, pueden empeorar rápidamente la experiencia de usuario.

En este artículo veremos:

1. Qué es un modal y su anatomía
   1. Diferencias entre un modal y una ventana emergente
2. Cuándo usar modales (y cuándo no)
3. 5 patrones de modales con ejemplos
4. 4 antipatrones: errores comunes en modales
5. La accesibilidad de los modales
6. Apuntes finales

Los modales y su anatomía

Un modal es un elemento de la interfaz que aparece sobre el contenido principal y requiere la atención del usuario antes de continuar. En teoría se suelen utilizar para interacciones críticas o cuando se necesita que el usuario realice una acción específica.

La anatomía de un modal es simple:

1. Fondo opaco o semitransparente. Se utiliza para centrar la atención en el modal.
2. Contenido. Suelen tener un título y otros elementos como textos, formularios, botones, imágenes o iconos.
3. Acciones. Si utilizamos un modal es porque queremos que nuestro usuario lleve a cabo alguna tarea, así habitualmente incluyen botones.
4. Cierre. Generalmente se sitúa en la esquina superior derecha. Idealmente el modal debería poder cerrarse mediante la tecla «Esc».

Antes de continuar, creo que es necesario entrar un poco más en detalle con una aclaración 👀

Diferencias entre un modal y una ventana emergente (pop-up)

Ambos conceptos se usan indistintamente, pero no son exactamente lo mismo:

• Modal: Es una ventana emergente que bloquea la interacción con el resto de la interfaz hasta que se cierra. Se usa para confirmar acciones o solicitar información relevante en el contexto.
• Ventana emergente (pop-up): Es una nueva ventana del navegador que se abre de forma independiente y no siempre requiere interacción inmediata. Suelen usarse para publicidad o contenido secundario.

Ahora, continuemos.

Cuándo usar modales (y cuándo no)

Antes de diseñar un modal, hazte esta pregunta: ¿realmente necesito interrumpir al usuario?

Los modales son herramientas de interrupción. Eso no es malo en sí mismo, pero hay que usarlo con criterio. Igual que sucede con los tooltips, no siempre es fácil decidir cuándo es la solución correcta.

✅ Usa un modal para:

• Confirmaciones críticas (eliminar cuenta, cancelar suscripción)
• Captura rápida de datos (1-4 campos máximo)
• Onboarding contextual de una funcionalidad
• Decisiones que bloquean el flujo (seleccionar plan, confirmar permisos)
• Accesos rápidos tipo command palette

⚠️ NO uses un modal para:

• Contenido que requiere scroll extenso
• Formularios de más de 4-5 campos
• Decisiones que pueden esperar
• Información de solo lectura o documentación

Alternativas a considerar

• Bottom sheet: Opciones rápidas en móvil sin bloquear toda la pantalla
• Panel lateral (slide-over):
• Formularios medianos o edición con contexto visible
• Expansión inline: Información relacionada con un elemento específico
• Toast o snackbar: Confirmaciones breves sin acción requerida

5 patrones de modales con ejemplos

Veamos los patrones más comunes y cómo los implementan productos reales.

1. Modal de confirmación

Utiliza un modal cuando el usuario esté llevando a cabo acciones destructivas o irreversibles como eliminar una cuenta, cancelar una suscripción o borrar un proyecto.

Figma, por ejemplo, utiliza un modal cuando vas a eliminar un archivo. Especifica claramenteel nombre del archivo y advierte que la acción no se puede deshacer. El botón destructivo usa color de advertencia.

2. Modal de formulario simple

Si necesitas que tu usuario aporte un dato rápido, como una tarjeta de pago, cambiar el avatar, actualizar el nombre, etc. piensa en utilizar un modal, porque así tu usuario no pierde el contexto de la página y el flujo parece más sencillo y rápido.

3. Modal de onboarding

Los modales son particularmente útiles para introducir funcionalidades o para guiar en el primer uso durante el onboarding. Hay dos motivos principales por los que se utilizan.

• Como en el ejemplo anterior, el usuario no pierde el contexto
• El onboarding parece más liviano y claro, una modal = una acción concreta

4. Modal de selección

Cuando necesitas que el usuario tome una decisión antes de continuar, como seleccionar un plan de precios (Glide) o iniciar sesión para acceder al contenido. De nuevo, es un recurso que permite llevar a cabo la acción sin perder del todo el foco: la página web sigue estando visible por detrás, lo que a su vez también refuerza qué conseguirá el usuario cuando se haya identificado o registrado.

5. Command palette

Este es un caso ligeramente especial. Una command palette da acceso rápido a funcionalidades y búsqueda sin perder el foco.

4 antipatrones: errores comunes en modales

Estos son los errores que veo con más frecuencia en el diseño y la implementación de modales:

1. Modal dentro de modal

Un modal que abre otro modal. Confuso, rompe el modelo mental del usuario, y hace imposible saber cómo volver atrás.

Solución: Cambia el contenido del modal actual, usa un panel lateral, o reconsidera si necesitas esa segunda capa.

2. Sin botón de cierre visible o ESC

No asumas que todos tus usuarios sabrán que un modal puede cerrarse haciendo clic fuera de él o con la tecla ESC del teclado. Y al revés: no asumas que todos los usuarios van a hacer clic siempre en la X, algunos buscarán siempre ESC. Tener una opción y no la otra puede generar, como habrás deducido ya, problemas de accesibilidad.

Solución: Siempre incluye una X visible en la esquina superior derecha. Las otras opciones son complementarias, no sustitutas.

3. Focus que escapa del modal

Este aspecto también se relaciona con la accesibilidad. Para los usuarios que navegan utilizando la tecla Tab del teclado, el focus debe pasar por el modal. Si lo evita, eso genera un grave problema de accesibilidad, porque estos usuarios jamás podrán interactuar con él.

Solución: Implementa focus trap: el foco debe ciclar solo entre elementos del modal mientras esté abierto.

4. Lenguaje confuso

El que verás a continuación es seguramente uno de los errores más comunes. Los modales deben ser concisos y estar enfocados a una sola tarea:

• El titular del modal debe describir el propósito de forma clara
• Usar verbos específicos en los botones que describan la acción que realizarán
• Indicar claramente qué ocurrirá con cada opción disponible
• Destacar visualmente las acciones destructivas o irreversibles

La accesibilidad de los modales

Como siempre, último pero no por ello menos importante: los modales pueden generar problemas colaterales si no se han diseñado e implementado teniendo en cuenta las mejores prácticas en accesibilidad.

Navegación con teclado

• Tab: Moverse entre elementos interactivos
• Shift + Tab: Ir hacia atrás
• Enter: Activar botones
• ESC: Cerrar el modal

Focus trap

Como te explicaba unos párrafos más arriba, cuando el modal está abierto, el foco debe quedarse dentro del modal. Si el usuario pulsa Tab repetidamente, el foco cicla entre los elementos del modal, y no escapa a la página de fondo. Al cerrar, el foco debe volver al elemento que abrió el modal.

Lectores de pantalla

• role="dialog" o role="alertdialog" para confirmaciones urgentes
• aria-labelledby vinculado al título del modal
• aria-describedby vinculado a la descripción (si aplica)
• aria-modal="true" para indicar que el resto de la página no está disponible

Checklist rápido

Sé que todo esto puede resultar confuso, así que te dejo con una breve lista de verificación para que puedas hacer un repaso rápido:

• [ ] ¿Se puede navegar con Tab entre todos los elementos?
• [ ] ¿Hacer clic en ESC cierra el modal?
• [ ] ¿El foco queda «atrapado» dentro mientras está abierto?
• [ ] ¿El foco vuelve al trigger al cerrar?
• [ ] ¿Tiene los atributos ARIA correctos?
• [ ] ¿El contraste de texto es suficiente (4.5:1)?
• [ ] ¿Los botones tienen tamaño mínimo táctil (44x44px)?

Si quieres profundizar sobre la accesibilidad, tengo un artículo sobre herramientas de accesibilidad para diseñadores que te ayudará a validar tus diseños. También escribí sobre la experiencia de liderar la accesibilidad en WordPress.com.

Apuntes finales

Como conclusión, decir que aunque los modales puedan ser una solución útil, es esencial saber cuando utilizarlos y cuando no: un uso excesivo distrae, y limita la función principal: destacar una opción por encima del resto.

Un modal bien diseñado es invisible: el usuario completa su tarea y sigue adelante. Uno mal diseñado interrumpe, frustra y genera abandono.

Aprovechando que has llegado hasta aquí, te recomiendo que evalúes los modales que hay en el producto que estás diseñando, y te asegures de que sean la mejor solución posible:

1. ¿Es realmente necesaria la interrupción? Si la respuesta es no, usa una alternativa menos invasiva.
2. ¿Cumple con los patrones que funcionan? Confirmación, formulario simple, onboarding, selección o command palette.
3. ¿Está bien implementado? Botón de cierre visible, ESC funciona, focus trap activo, atributos ARIA correctos.