Give users appropriate loading feedback for the AI process going on. Here are some patterns aligned to the wait time, with implementation ideas for Blazor.

AI-driven applications introduce a new set of challenges for user experience design. Traditional web applications operate within predictable boundaries, where requests complete in a consistent and measurable way. AI features change that dynamic, with response times ranging from near-instant to long-running operations that can take minutes. Designing for that variability is no longer optional, it is a core part of building reliable AI-powered applications.

The challenge extends beyond implementation into perception. Users do not experience time objectively; they react to how it feels. A blank screen creates doubt, while visible progress keeps the experience grounded. When feedback aligns with the effort required, the interaction feels natural. When it does not, friction builds quickly. Thoughtful loading design addresses this gap by communicating progress, setting expectations and reinforcing the value of the task in motion.

This guide focuses on practical loading UI patterns for AI scenarios, organized by real-world wait times. Each pattern is implemented with Blazor and Progress Telerik UI components, keeping the discussion grounded in tools developers already use. The goal is simple: create loading experiences that do more than fill time, improving perceived performance and building confidence in the system behind the scenes.

Understanding AI Application Loading Patterns

AI applications introduce a different class of loading behavior. Traditional web requests are relatively predictable, but AI workloads are not. Inference, natural language processing and computer vision all introduce variability based on model complexity, input size and system load. As powerful as these capabilities are, they require a more deliberate approach to how progress is communicated.

Effective loading experiences center on managing expectations through clear, continuous feedback. Every loading state should communicate what is happening now, what has completed and what comes next, keeping users oriented as the system works. With this foundation in place, loading patterns can be tailored to specific wait times, keeping the experience responsive and understandable regardless of how long processing takes.

Near Instantaneous Responses (Less Than 1 Second)

For interactions under one second, traditional loading indicators often add more friction than value. Quick flashes of spinners or progress bars create a visual glitch that feels broken rather than helpful. Instead, the interface should respond immediately with subtle visual feedback that confirms the action without interrupting flow.

One exception stands out: when a fast action represents the final step in a longer workflow. In these cases, introducing a brief, intentional delay can create a sense of completion, giving users a moment to recognize the result of their effort before moving on.

AI Task Examples

AI tasks that typically complete in under one second include:

• Real-time text suggestions and autocomplete
• Simple sentiment analysis on short text
• Basic image classification with lightweight models
• Cached AI responses
• Rule-based chatbot responses
• Simple recommendation filtering

Blazor Implementation Strategy

Implementing instantaneous feedback in Blazor requires careful coordination between state changes and visual cues. The goal is to reflect user actions immediately while avoiding flicker from overly brief loading states. In practice, this often means enforcing a minimal display duration for indicators so that interactions feel smooth and intentional.

Try the A/B samples below by clicking the “Zoom and Enhance” buttons twice. The A sample should feel smoother on short intervals because of the intentional delay.

UX Strategy

Instant interactions benefit from confirmation rather than explanation. Subtle cues like button state changes, input highlighting or lightweight animations signal that the system has responded, keeping the experience fluid and uninterrupted. When these signals are consistent and immediate, users stay oriented without feeling like they are waiting.

Short Wait Times (1–3 Seconds)

Short waits call for lightweight, indeterminate indicators that acknowledge progress without interrupting flow. Simple spinners or skeleton screens work well because they provide immediate feedback while keeping the interface responsive. More elaborate animations tend to work against this, as users do not have enough time to process them and the interaction can feel slower than it is.

Skeleton screens are especially effective in AI scenarios because they establish structure upfront. By rendering a placeholder version of the final layout, the interface maintains continuity and gives users a clear sense of what is coming next as content is generated.

AI Task Examples

AI operations in the 1–3 second range include:

• Text generation for short responses
• Image enhancement or basic filtering
• Summarizing a document of moderate length
• Translation of short to medium text
• Basic data analysis and insights generation
• Voice-to-text conversion for brief audio

Blazor Implementation Strategy

Chat Progress and Thinking

The Telerik UI for Blazor Skeleton component provides a straightforward way to mirror final layouts while AI-generated content is loading and the agent is thinking.

Smart Paste Loading

The following demo shows a smart paste interaction that incorporates loading indicators to signal the process taking place. The Loading Container is displayed over the form fields being populated, while a button loader indicates the action is taking place once the button is clicked.

UX Strategy

Short waits benefit from clarity without added friction. Contextual messaging that reflects the task in progress, such as “Thinking” or “Generating recommendations,” helps users understand what is happening without slowing the experience down. When combined with progressive disclosure, where partial results are rendered as they become available, the interface stays active and responsive, reducing perceived wait time while making the system’s work visible.

Medium Wait Times (3–10 Seconds)

Users begin to question responsiveness, and a lack of visible progress quickly turns into doubt. Multi-agent workflows or agentic workflows with multiple indeterminate steps can be difficult to navigate. Agents can make requests to external tools that have asynchronous processes. While these processes run, it is important to report the activity in a manageable way without losing focus of the main content.

Blazor Implementation

Provide feedback for AI operations that expose measurable progress. The example below shows a chat process where the agent uses external tools. Loading indicators are exposed in a collapsible panel to allow the user to see the progress but also hide it when the details are no longer necessary.

UX Strategy

Medium waits benefit from a balance of clarity and momentum. Directional time estimates, even something as simple as “This may take about a minute,” help users decide whether to stay engaged or return later, while continuously moving progress indicators reinforce that the system is still working. When paired with contextual messaging that explains the current step or highlights what is being processed, the experience shifts from passive waiting to a guided interaction that keeps users oriented and informed.

Extended Wait Times (10+ Seconds)

Extended wait times require a different approach. Clear visibility into progress matters, but so does the freedom to move on without losing track of what is happening. Combining progress indicators with background processing patterns allows the system to stay transparent while keeping the rest of the application usable.

Percent-complete indicators play a central role here by giving users a sense of scale. Seeing measurable progress helps them judge how much work remains and whether it is worth continuing to wait. At the same time, providing cancel or abort options keeps users in control rather than locked into a long-running process.

Step-based indicators work especially well for multi-stage AI operations by breaking the process into clear, understandable phases. Even when exact timing is uncertain, each completed step provides direction and reinforces forward movement.

Blazor Implementation

The following example uses a grid format to display and manage agent activity. Each element displays important information about the task’s state. In addition, failure modes are included and made actionable from the interface. This type of UX is great for dashboard-like scenarios where users can launch agent workflows and return later to see the task completion status.

If the user may encounter a long and undetermined loading state, a looping indicator can be used to communicate the overall steps that are running in the background, without labeling exactly what stage the process is at now. This nondeterministic progress indicator displays a carousel of information while the user waits.

With agentic applications, long processes can give the impression of wasted time, even though a process that takes minutes for an agent may have taken a human hour to complete manually. This loading pattern reminds users of the work going on behind the scenes. While some consider this a “dark pattern” when used to obscure the process details, it can be quite useful when used correctly to share honest information about the value the process provides.

Extended waits benefit from a design that prioritizes flexibility and user control. Background task patterns, such as persistent status panels or drawers, allow users to continue working while keeping progress visible, reducing the friction of being forced to wait in place. When paired with notification systems that signal completion, the need to actively monitor progress is removed entirely, giving users confidence that the system will follow through.

Longer waits create space to surface meaningful insights, explain processing steps or provide guidance for improving future results. When these elements are combined effectively, the experience shifts from a blocking delay to a managed, transparent process that keeps users informed without interrupting their workflow.

Advanced Patterns for AI Applications

Contextual Loading Messages

AI applications benefit from contextual loading messages that explain current processing steps. Replace generic “Loading...” text with specific descriptions: “Analyzing image composition,” “Generating creative variations” or “Cross-referencing knowledge base.” These messages build user understanding of AI capabilities while setting realistic expectations for output quality.

Streaming and Incremental Results

Many modern AI applications support streaming responses, particularly for text generation. Implement progressive disclosure patterns that display AI outputs as they generate, reducing perceived wait time while demonstrating active processing. This approach works particularly well for conversational AI interfaces and content-generation tools.

Summary

Designing loading experiences for AI applications is no longer about handling delays. It is about shaping how users understand and interact with the system. When feedback aligns with the work being performed, users stay engaged and in control regardless of how long processing takes.

By matching loading strategies to expected wait times, developers can move beyond generic indicators and deliver feedback that is intentional and informative. From immediate visual confirmation to multi-stage progress tracking, each pattern helps make AI interactions feel predictable and responsive.

Blazor and Telerik UI components provide a practical foundation for implementing these patterns, enabling teams to build consistent loading experiences without introducing unnecessary complexity. The advantage comes from how these tools are applied, not just their availability.

As AI continues to shape modern applications, loading design becomes a defining part of the user experience. Applications that communicate clearly during processing will feel faster and more reliable, regardless of the work happening behind the scenes.

Get Started with These Examples

Use any of the Telerik UI for Blazor components shown above, plus the Blazor MCP servers free with the 30-day trial.

Try Now

A peculiar kind of pride runs through the technology industry. Many leaders believe their problems are unique, their scale unprecedented, their requirements so specific that only a custom-built solution will do.

This belief is also one of the most expensive mistakes your organization can make.

The Hidden Cost of “Building It Ourselves”

Every custom solution your team builds is a solution your team must maintain. Forever. Or at least until someone finally rips it out, usually years after the original developer has moved on, leaving behind a legacy that no one fully understands and everyone is afraid to touch.

If you have spent any time in technology leadership, you have inherited one of these systems. You know the feeling: the documentation is sparse, the original author is unreachable, and the thing is somehow load-bearing for your entire operation.

Ask yourself honestly: how much of your engineering budget goes toward maintaining problems that someone else has already solved?

The “Use What Works” Philosophy

The Use What Works vision offers a direct principle: organizations should generally use existing, proven, and sustainable solutions to common problems rather than developing, maintaining, and running their own.

This philosophy emerges from recognizing where your organization’s differentiation actually lies.

Your authentication system is probably not your competitive advantage. Neither is your deployment pipeline, your logging setup, or your database management tooling. These are solved problems. Teams whose entire focus is solving them have solved them well.

Five Reasons This Matters for Your Business

1. Your Best Engineers Should Be Building Your Product

Every hour a talented developer spends building a custom caching layer is an hour they are not spending on the features that differentiate your product in the market. Proven solutions let your team focus on value creation rather than infrastructure reinvention.

2. Turnover Is Inevitable. Plan for It.

People leave. When they do, who maintains the custom solution they built? If documented at all, it reflects their style, their assumptions, their understanding. Established technologies come with community knowledge, third-party documentation, and a hiring pool of people who already know how they work.

3. Battle-Tested Beats Theoretically Elegant

Linus’s Law observes: “Given enough eyeballs, all bugs are shallow.” Software deployed across thousands of organizations, at every conceivable scale, has encountered and resolved problems your custom solution has not even discovered yet. You benefit from the collected experience of an entire community.

4. Predictability Reduces Risk

Proven solutions come with documentation, case studies, and communities. When something breaks at 2 AM, there is likely a Stack Overflow thread, a support agreement, or a consultant who has seen it before. Your custom solution has none of these things. Just an on-call engineer reading code they did not write.

5. AI Assistance Works Better with Established Tools

If your teams are using AI coding assistants, those tools perform dramatically better with well-documented, widely used technologies. The models have seen thousands of examples of proper implementation. They have not seen your custom internal tools.

The Sustainability Argument

A broader consideration exists here too. Maintaining quality software costs money. When organizations cluster around proven solutions, the cost of that maintenance is distributed across everyone who benefits. This creates sustainable systems where even smaller organizations can access enterprise-grade infrastructure.

The alternative, where everyone builds their own, fragments effort, duplicates cost, and delivers worse outcomes for everyone.

When Custom Makes Sense

This is not absolutism. Legitimate cases exist for building custom solutions: when your requirements genuinely are unique, when the existing options do not meet your needs, or when the problem space is so central to your business that you need complete control.

But those cases are rarer than most technology organizations believe. The only honest question worth asking: should we build this ourselves?

The Bottom Line

Stop waste. Reduce risk. Focus your engineering talent on the problems that actually differentiate your business.

Use what works.

Use What Works is an open initiative encouraging organizations to embrace proven, sustainable solutions. Learn more about what this means for business leaders on our homepage: https://usewhatworks.org/.

The post The Strategic Case for “Use What Works”: Why Smart Tech Leaders Stop Reinventing the Wheel first appeared on Chris Woody Woodruff | Fractional Architect.

Say you want to have the functionality of a reader/writer lock, but have it work cross-process. The built-in SRWLOCK works only within a single process. Can we build a reader/writer lock that works across processes?

For convenience, let’s say that you want to support a maximum of N simultaneous readers, for some fixed value N. We can do this:

• Create a semaphore with a token count of N. Share this semaphore with all of the processes, either by giving it a name or by duplicating the handle into each of the processes.
• To take a read lock, claim one token from the semaphore. To release the lock, release the token.
• To take a write lock, claim N tokens from the semaphore. To release the lock, release N tokens.

The idea for the write lock is that it’s accomplished by claiming all the read locks, thereby ensuring that nobody else can get a read lock.

#define MAX_SHARED 100
HANDLE sharedSemaphore;

void AcquireShared()
{
    WaitForSingleObject(sharedSemaphore, INFINITE);
}

void ReleaseShared()
{
    ReleaseSemaphore(sharedSemaphore, 1, nullptr);
}

void AcquireExclusive()
{
    for (unsigned i = 0; i < MAX_SHARED; i++) {
        WaitForSingleObject(sharedSemaphore, INFINITE);
    }
}

void ReleaseShared()
{
    ReleaseSemaphore(sharedSemaphore, MAX_SHARED, nullptr);
}

Since we are using Wait­For­Single­Object, we can also add a timeout, so that the caller can decide to abandon the operation if they can’t claim the lock.

bool AcquireSharedWithTimeout(DWORD timeout)
{
    return WaitForSingleObject(sharedSemaphore, timeout) == WAIT_OBJECT_0;
}

bool AcquireExclusiveWithTimeout(DWORD timeout)
{
    DWORD start = GetTickCount();
    for (unsigned i = 0; i < MAX_SHARED; i++) {
        DWORD elapsed = GetTickCount() - start;
        if (elapsed > timeout ||
            WaitForSingleObject(sharedSemaphore, timeout - elapsed) == WAIT_TIMEOUT)) {
            // Restore the tokens we already claimed.
            if (i > 0) {
                ReleaseSemaphore(sharedSemaphore, i, nullptr);
            }
            return false;
        }
    }
    return true;
}

Exclusive acquisition is tricky because we have to call Wait­For­Single­Object multiple times, with decreasing timeouts as time passes. If we run out of time, then we need to give back the tokens we had prematurely claimed.

There’s still a problem here. We’ll look at it next time.

The post Developing a cross-process reader/writer lock with limited readers, part 1: A semaphore appeared first on The Old New Thing.