User Experience During Degradation

Transparent vs Hidden Degradation
Some degradation should be invisible. Serving cached product catalog instead of real time data? Users should not notice unless actively looking for recent changes. Other degradation requires transparency. Search returning limited results? Show "Showing partial results, full search temporarily unavailable." The principle: hide degradation when quality difference is minimal, communicate when users might be confused by different behavior. Never pretend full functionality when delivering reduced service that affects user decisions.
Progressive Disclosure
Complex pages should render progressively, showing critical content first. Load product image and price immediately. Lazy load reviews, recommendations, and social proof. If recommendation service is slow or failed, the page appears complete with critical information. Failed secondary sections show graceful placeholders: "Reviews loading..." that timeout to "Unable to load reviews" rather than breaking page layout. Progressive loading naturally implements degradation, each section independent of others.
✅ Best Practice: Design UI components with explicit loading, success, error, and degraded states. A recommendation panel should handle: loading (skeleton), success (full content), error (friendly message), degraded (popular items fallback). Each state maintains consistent layout.
Error Messages and Recovery Guidance
When degradation affects user actions, provide actionable guidance. "Payment processing unavailable. Try again in 5 minutes or complete purchase by phone: 1-800-XXX-XXXX." Include retry suggestion with specific timing, not vague "try again later." Offer alternative paths: "Search is unavailable. Browse by category instead." Track degradation status and proactively notify users when service recovers: banner saying "Search is back! Click to retry your query."
Skeleton Screens and Placeholders
Visual placeholders maintain layout during degradation. Skeleton screens (gray content shaped placeholders that animate while loading) indicate loading rather than error. When content fails to load after timeout, skeletons transform to explicit unavailable states. Preserve page structure: a three column layout with one failed column should show empty placeholder, not collapse to two columns. Users develop spatial memory; changing layout during degradation confuses navigation.
Queueing User Actions
For non-critical actions, queue locally and process when service recovers. User adds item to wishlist but wishlist service is down? Store action in browser local storage, retry when connectivity restores. Show optimistic UI: "Added to wishlist" with subtle pending indicator. Sync status with server when available. This pattern works for favorites, preferences, cart updates. Not suitable for actions requiring immediate confirmation like purchases or reservations. Cap local queue size to prevent memory issues on long outages.

💡 Key Takeaways

✓Hide degradation when quality difference is minimal; communicate when it affects user decisions

✓Progressive loading naturally implements degradation - critical content first, optional content lazy loaded

✓Provide specific recovery guidance: retry timing, alternative paths, contact options

📌 Interview Tips

1Discuss skeleton screens maintaining layout during degradation

2Mention optimistic UI with local queueing for non-critical actions

3Show awareness of transparency trade-offs: when to hide vs communicate degradation

← Back to Graceful Degradation Overview