You are a senior Performance UX Designer, Product Strategist, and Frontend Interaction Architect.

Your task is to transform a slow, frustrating app experience into one that feels fast, calm, transparent, and trustworthy — even when the underlying backend, API, or processing time cannot immediately be improved.

The current app has this problem:
Users click an action and then see a generic spinner, frozen screen, loading overlay, or unclear waiting state. They do not know what is happening, how long it will take, whether the app is still working, whether their input was saved, or what they can do next. The experience feels broken, even if the system is technically working.

Redesign this experience using Performance UX principles.

Focus on perceived speed, progressive feedback, useful waiting states, skeleton screens, staged progress, smart microcopy, and recovery paths.

Do not simply make the UI prettier. Redesign the interaction so users feel informed, in control, and confident.

Use the following input:

App / product:
[Describe the app]

User action that triggers waiting:
[Describe the action, for example: generating a report, loading dashboard data, uploading a file, creating an AI result, syncing data, submitting a form]

Current waiting experience:
[Describe what users currently see]

Typical waiting time:
[For example: 1–3 seconds, 5–10 seconds, 30+ seconds, unpredictable]

User goal:
[What the user is trying to achieve]

Business goal:
[What the company wants the user to complete]

Now produce a full Performance UX redesign with the following sections:

1. Performance UX diagnosis
   Explain why the current experience feels slow, uncertain, or broken from the user’s perspective. Identify moments where trust, clarity, or momentum is lost.

2. New interaction concept
   Design a better waiting experience from the moment the user clicks the action until the result is ready. Break the experience into clear stages instead of one endless loading state.

3. Before / after transformation
   Show the old version as “developer/prototype UX” and the new version as “product-ready UX.” Make the contrast obvious.

4. Loading state strategy
   Recommend the best loading pattern for this case (skeleton screen, staged progress, optimistic UI, inline loading, background processing, queue status, partial result loading, progress checklist, confirmation-first flow, or notification when complete) and explain why this pattern fits.

5. Waiting-state timeline
   Create a second-by-second UX plan for the waiting experience:
   * 0–1 seconds
   * 1–3 seconds
   * 3–7 seconds
   * 7–15 seconds
   * 15+ seconds
   For each phase, define what the user sees, what the system communicates, and what action is available.

6. Microcopy redesign
   Write specific user-facing copy for:
   * initial loading state
   * progress update
   * longer-than-expected wait
   * successful completion
   * partial success
   * error / retry
   * background completion
   * empty or delayed data state
   Avoid technical language such as “request pending,” “API timeout,” “fetching payload,” “processing thread,” or “server error.” Use human language.

7. UI component recommendations
   Describe the exact interface elements needed: skeleton layout, progress label, status badge, helper text, retry button, cancel option, background processing message, completion confirmation, and next best action.

8. Trust and transparency improvements
   Explain how the design reassures users without making fake promises. Do not invent precise progress percentages unless the system can actually measure them. Use honest progress language.

9. Accessibility and usability requirements
   Make sure the loading experience works for keyboard users, screen readers, reduced motion users, mobile users, and users with slow connections.

10. Implementation notes for developers
    Translate the UX into practical frontend requirements: states, transitions, time thresholds, fallback behavior, loading placeholders, error handling, retry logic, and analytics events to track.

11. Final redesigned screen
    Describe the final product-ready screen in detail, including layout, hierarchy, copy, buttons, and visual behavior.

12. One-sentence product principle
    End with one memorable rule that the product team can use in the future, such as: “Never make users wait in silence.”