Un diseñador junior entrega una pantalla: la versión "perfecta", con contenido ideal, usuario logueado, todo cargado. Luego el desarrollador la implementa y descubre dos días después que el diseño solo sirve para el 5% de los escenarios reales. Faltan todos los demás: cuando no hay datos, cuando hay un error, cuando está cargando, cuando el usuario está offline, cuando una acción se completó con éxito.
Los estados del diseño — design states — son la respuesta metódica a este problema. En lugar de diseñar una pantalla, diseñas todas las configuraciones posibles de esa pantalla, cada una con su tratamiento visual y su mensaje. Este artículo cubre los 5 estados clásicos codificados por Scott Hurff en su libro Designing Products People Love y los 2 estados que casi nadie diseña pero que en 2026 son imprescindibles.
Qué vas a aprender:
- Qué son los estados del diseño y por qué importan
- Los 5 estados clásicos: ideal, empty, error, partial, loading
- Los 2 estados olvidados: success/celebrative y offline
- Cómo diseñar cada estado con ejemplos reales
- Cómo integrarlos en el flujo de trabajo de diseño
Qué son los estados del diseño
Cada pantalla de cualquier producto digital existe en múltiples estados posibles, según el contexto del usuario y los datos disponibles. Una lista de pedidos tiene un estado para "sin pedidos", uno para "con pedidos", uno para "cargando", uno para "error de red", uno para "filtro sin resultados". Son todas "la misma pantalla" pero visual y funcionalmente diferentes.
El diseño "completo" de una pantalla es la suma de todos esos estados. Ignorar uno deja un hueco en el producto — un escenario que, cuando ocurre en la vida real, produce una experiencia rota (pantalla en blanco, mensaje técnico incomprensible, carga infinita).
Scott Hurff codificó en 2015 los 5 estados principales como base de un diseño robusto. Desde entonces forman parte del vocabulario estándar del UX moderno — y cualquier design system serio (Polaris de Shopify, Atlassian, Material, Primer de GitHub) documenta cada uno explícitamente.
1. Ideal State
El estado ideal es el que todo diseñador ama: contenido rico, usuario logueado, todo cargado, sin errores. Es la pantalla perfecta de los mockups que se presentan al cliente.
Características:
- Todos los datos disponibles
- Layout visualmente óptimo
- Contenido en cantidad y calidad ideal
Ejemplo real: la timeline de X (Twitter) cuando sigues a 100 cuentas activas — siempre hay posts nuevos, imágenes, interacciones. La pantalla "vive" y muestra el producto en su mejor versión.
Error típico: diseñar solo este estado. El 70% de los usuarios reales nunca está en el estado ideal — son nuevos, tienen pocos datos, están explorando. El diseño tiene que funcionar también para ellos.
2. Empty State
El estado vacío es la pantalla cuando no hay datos que mostrar. Es el caso del nuevo usuario que acaba de instalar la app, del usuario avanzado que borró todo, del filtro que no produce resultados.
El empty state es el más subestimado de los 5 porque, en productos de consumo, representa la primera impresión para la mayoría de usuarios. Un buen empty state:
- Explica qué falta ("Todavía no tienes pedidos")
- Propone una acción concreta para salir ("Explora el catálogo →")
- Ilustra visualmente el concepto con un icono o ilustración
- Educa si el producto es nuevo para el usuario, mostrando qué esperar
Ejemplo real: cuando abres Notion por primera vez, el empty state muestra una plantilla ya rellena como ejemplo. En lugar de una página en blanco que paraliza, ves de inmediato qué puedes construir.
Casos a manejar por separado:
- Nuevo usuario (nunca tuvo datos): tono educativo, invitación al onboarding
- Usuario avanzado (borró todo): tono neutro, no paternalista
- Filtro/búsqueda sin resultados: propón quitar filtros o modificar la query
- Error vs. vacío legítimo: deben distinguirse claramente
3. Error State
El estado de error aparece cuando algo falla: servidor caído, formulario inválido, recurso no encontrado, acción fallida. Es el momento más crítico de la UX porque el usuario se siente defraudado.
Un error state bien diseñado:
- Dice qué pasó en lenguaje humano, no técnico
- Explica por qué pasó (cuando sea útil)
- Ofrece una salida (reintentar, contactar soporte, volver atrás)
- No culpa al usuario de errores del sistema
Mal ejemplo: "Error 500: Internal Server Error"
Buen ejemplo: "Algo salió mal de nuestro lado. Nuestros servidores están teniendo un problema — estamos en ello. Inténtalo de nuevo en unos minutos."
Para errores de formulario:
- Error específico por campo, no genérico para toda la página
- Mensaje que diga exactamente qué corregir
- Visible junto al campo, no apilado arriba
- Rojo + icono + texto, no solo color (accesibilidad WCAG 2.2 — el European Accessibility Act y la norma UNE-EN 301 549 exigen que la información no dependa solo del color)
Lee la guía sobre UX login para ejemplos específicos en formularios de autenticación.
4. Partial State
El estado parcial es aquel en el que algunos datos están y otros no. Es el perfil de usuario con nombre pero sin foto, el formulario a medio llenar, la app con algunos contenidos y otros que faltan.
Es el estado más frecuente en la realidad cotidiana — más común incluso que el estado ideal — y, sin embargo, el que menos se diseña conscientemente.
Cómo diseñarlo bien:
- Señala lo que falta con pistas visuales (badge "perfil incompleto", progress bar)
- Propone completar con acciones inline ("Añade una foto de perfil →")
- No rompas el layout: la pantalla debe funcionar también con huecos
- Placeholders significativos para las partes que faltan (no simples vacíos grises)
Ejemplo real: LinkedIn muestra una progress bar "Perfil al 65%" cuando faltan secciones, con sugerencias contextuales para completarlas. Transforma un estado parcial en motivación para actuar.
5. Loading State
El estado de carga cubre el tiempo entre una acción del usuario y el resultado visible. Es uno de los elementos más críticos para la percepción de velocidad de un producto.
Principios de un buen loading state:
- Feedback inmediato: dentro de 100ms del clic debe aparecer algo (aunque sea solo un cambio de estado del botón)
- Indicación de progreso cuando sea posible (1/5, 2/5, 3/5…)
- Skeleton screen en lugar de spinner para cargas de layout (reduce la percepción de espera)
- Umbral: por encima de 3–4 segundos hay que comunicar activamente (no solo spinner)
- Fallback pasados 10+ segundos: algo salió mal, pasa al error state
Skeleton screen vs. spinner:
El spinner es adecuado para acciones concretas y breves ("enviando mensaje…"). El skeleton screen — una versión gris de la página con los contornos de los elementos por cargar — es mucho mejor para cargas de layouts complejos, porque da inmediatamente un sentido de estructura. Facebook, LinkedIn y YouTube los usan en todas partes.
Para profundizar en las animaciones en loading states lee la guía de animaciones UI.
Estado olvidado #1: Success / Celebrative State
Además de los 5 clásicos, hay un estado que casi nadie diseña explícitamente: el success state, el momento en el que una acción importante se ha completado con éxito.
No todos los "éxitos" requieren celebración — un mensaje enviado no merece una animación cada vez. Pero acciones importantes (checkout completado, objetivo alcanzado, curso terminado, logro desbloqueado) son momentos en los que el producto debería reconocer la victoria del usuario.
Cómo diseñar un success state celebrativo:
- Visual fuerte y distintivo: animación, confeti, gráfico, color de marca saturado
- Confirmación explícita: "Pedido confirmado", "Pago realizado", "Perfil al 100%"
- Próximo paso sugerido: "Ver pedido", "Compartir resultado", "Empezar el próximo curso"
- Brevedad: 2–3 segundos, no 15. La celebración no debe bloquear el flujo
Ejemplo real: Duolingo, al terminar una lección, muestra una animación celebrativa corta con el progreso de XP y la racha. Refuerza el comportamiento sin ralentizar en exceso. Platzi y Coderhouse usan patrones similares al completar módulos de sus bootcamps.
Úsalo con moderación: un success state celebrativo cada vez que se guarda un campo es molesto. Resérvalo para los logros reales.
Estado olvidado #2: Offline State
Desde 2020, con la explosión de las progressive web apps y las apps móviles nativas, el offline state se ha vuelto imprescindible. Los usuarios pueden perder conexión en cualquier momento — y el producto debe saber reaccionar. Esto es especialmente crítico en LATAM, donde la conectividad móvil inestable es parte del día a día de productos como Rappi, Kavak o Mercado Libre.
Cómo diseñar el offline state:
- Detección automática: saber cuándo el usuario está offline (API del navegador
navigator.onLine) - Banner persistente: "Estás sin conexión — tus cambios se sincronizarán cuando vuelvas a estar online"
- Caché inteligente: mostrar los contenidos ya descargados, deshabilitar los que requieren red
- Acciones en cola: permite al usuario seguir trabajando; sincroniza al recuperar la conexión
- Transición fluida: cuando la conexión vuelve, informa y sincroniza sin interrumpir el flujo
Ejemplo real: Google Docs permite seguir escribiendo offline, muestra un badge "Cambios sin guardar" y sincroniza automáticamente en cuanto vuelve la conexión. El usuario nunca pierde su trabajo.
En los productos 2026-ready, el offline state es parte integral del diseño desde el principio, no un añadido posterior.
Cómo integrar los 7 estados en tu workflow
Tres técnicas para no olvidar ningún estado durante el diseño:
1. Checklist por pantalla
Al final de cada pantalla diseñada, completa una checklist:
- Ideal state
- Empty state
- Error state (red, servidor, validación)
- Partial state
- Loading state (skeleton + acciones)
- Success state (si aplica)
- Offline state (si aplica)
Si un estado no aplica, anota el porqué. Nunca saltes por despiste.
2. Un frame separado en Figma para cada estado
En lugar de un solo frame "Pantalla X", crea una cuadrícula de frames por estado. Verlos todos a la vez ayuda a detectar incoherencias visuales y a mantenerlos coherentes.
3. Testea con usuarios los estados críticos
Cuando hagas usability tests, fuérzate a probar al menos el empty state (como nuevo usuario) y al menos un error state (interrumpiendo la conexión durante el test). Son los estados que en la vida real marcan la diferencia entre un producto que aguanta y uno que se derrumba al primer imprevisto.
Preguntas frecuentes
¿Cuántos estados debo diseñar por pantalla?
El mínimo son los 5 clásicos (ideal, empty, error, partial, loading). En productos modernos añade offline y success celebrativo donde sea relevante. Algunos productos tienen estados adicionales específicos (ej. "modo mantenimiento", "bloqueado por política"), a gestionar caso por caso.
¿Puedo saltar el empty state si mi producto "nunca estará vacío"?
No. Incluso productos con contenido garantizado tienen empty states: filtros sin resultados, búsquedas sin coincidencias, secciones que el usuario aún no ha explorado. Tratar el empty state como "improbable" significa descubrir demasiado tarde que era frecuente.
¿Skeleton screen o spinner, qué es mejor?
El skeleton screen es mejor para cargas de layouts complejos (dashboards, listas, páginas con varios elementos). El spinner es adecuado para acciones breves y específicas (envío de formulario, subida de archivo). Usarlos combinados, cada uno en su contexto, es la decisión correcta.
¿Cómo comunico los error states a los desarrolladores?
Documenta cada posible error con: el mensaje que verá el usuario, la condición que lo dispara, el comportamiento del botón de recovery. Figma + Notion funciona bien para esto. Los desarrolladores deben saber exactamente qué mostrar en cada caso.
¿Los estados del diseño aplican también a interfaces conversacionales?
Sí, con adaptaciones. Un chatbot tiene un estado "está pensando" (equivalente a loading), un estado "no entendí" (error), un estado "¿qué quieres saber?" (empty para nuevo usuario). El principio es universal aunque la expresión cambie.
¿Los estados del diseño forman parte del design system?
Sí. Los design systems maduros (Material, Polaris de Shopify, Atlassian, Primer de GitHub) incluyen componentes para cada estado estándar: plantillas de empty state, plantillas de error state, skeletons de loading predefinidos. Esto garantiza coherencia y velocidad entre productos distintos de una misma empresa.
Próximos pasos
Diseñar los estados es una de las disciplinas más prácticas del UX Design, la que más separa los diseños "de portfolio" de los "production-ready". Para profundizar:
- Lee las animaciones UI que viven a menudo en los estados de transición
- Estudia las heurísticas de usabilidad aplicables a los estados de error
- Profundiza en el wireframe que debería incluir todos los estados desde el principio
En el Curso de Interaction Design de CorsoUX practicamos el diseño sistemático de los estados con casos reales, con feedback de mentores que verifican la cobertura de todos los escenarios.
