All the interesting technology and cool functionality in the world is meaningless if what we build doesn’t solve the problems our users need solved. To do that, we need to create experiences that make it as simple as possible for users get the output they need from our AI features and leverage it in their work.

UX Pattern: Usage Guidance

One of the biggest mistakes we can make when developing AI features is assuming that users know how to use them. As mentioned in the first article of this series: we know how to do things like provide context, specify formatting requirements, break large tasks into smaller ones, and iterate toward better results when using AI—but our users often won’t.

When we place a blank text box in front of a user and tell them to “Ask AI,” we're actually asking them to do a lot of prework before they even get to their main task. So much, in fact, that it may actually create more work for them than just completing the task themselves.

They need to understand what kinds of problems the tool can solve, how specific they should be, what information the AI needs to succeed and how to recognize when a response needs refinement.

Rather than expecting this level of AI-literacy from our users, we can help them by providing examples, templates, suggested prompts and guided workflows that demonstrate what success looks like. And if there’s existing contextual information we can leverage without making the user input it all themselves, all the better.

UX Pattern: Action Buttons

What will your users be doing with the content your AI feature generates? If they run a search or analyze a spreadsheet, what do they do with the results? If they create an image, who are they showing it to? The action itself is just the beginning of the flow for our users, who then need to do something with what they’ve received.

By including action buttons, we can make it as easy as possible to them to leverage the output of our tools in their own work. If they’re not able to act on the content that was created, it’s never going to be of much realistic use to them. And if it’s not immediately clear what they can do with what we’ve created for them, then we need to show them with real-world examples.

Once they have an idea of what they want to do, action buttons can guide them to suggested steps that help make the most of what was generated. But an application that creates content a user isn’t sure how to use is nothing more than a novelty to be used once or twice and then ignored.

UX Pattern: External Integrations

If we want to take this one step further, we can build in direct integrations with their other most-used tools. For example, generating a new document in their word processing software from an AI writing draft, pushing new code to their linked repo, opening a new ticket in their tracking system with findings from a test. The simpler we make it to get information from our tool into the rest of their workflow, the more useful it will be to them.

Can Users Trust the AI Features in Your Software?

AI can generate content, write code, analyze data, automate tasks and empower our users to do incredible work—but only if they’re willing to try it. When everything our AI tools are doing is hidden behind the curtain, it makes users feel like things are happening without their input—which is hard, especially when many of them are already feeling some level of AI skepticism and hesitation.

If we create AI experiences that take away our users’ power, understanding and autonomy, then they’ll never be interested in using what we build because they’ll never feel truly comfortable engaging with it. By focusing on patterns that reinforce those UX priorities of trust, clarity, control, transparency and meaningful benefit, we can set guardrails around our AI features that help make our users feel safe.

The technology is here. The models are already good and they just keep getting better, faster and more efficient. That means that the differentiator for AI-powered software isn’t performance, anymore. It’s the quality of the experiences that we can build around them.

The line between design and development is blurring a little more every day: how users interact with a system, how much information they see, how much control they have and how we earn their trust are now questions that developers have to consider when building AI-powered software—whether your title includes “designer” or not. The technology may be incredible, but for it to be truly successful, users still need to be at the center of everything we build.

AI tools are strongest when they integrate into the rest of a user’s workflow—referencing internal documents, sending emails, making calendar appointments, drafting and sharing content with coworkers, so on and so forth.

However, most users won’t integrate what they can’t see and understand. If the AI applications we build are going to become part of their daily lives, users need transparency into exactly what they do, what data they have access to and what it will cost them (in both time and money).

The more transparent we can make these features, the less hesitation our users will have adopting them.

UX Pattern: Permissions

The concept of asking for user permissions is certainly not AI-specific, but the stakes can feel a lot higher when you’re asking users for permission to allow AI to act on their behalf.

We need to make it easy for users to see which applications we’ve allowed our tool to access and in what ways, keeping in mind that permissions are often more than just “yes” or “no.”

Can your agent just reference data from this database, or is it allowed to delete tables? Can it only read a user’s emails, or is it allowed to send from their address as well? Can it run scripts? Search local files? Each one of these actions requires direct user sign-off.

Permissions are also not a one-and-done situation. A user might feel comfortable allowing an action to happen once under their direct supervision, but don’t want to allow it permanently. They might give access to a specific folder, but not every folder. They might approve an action, but want to be notified each time it’s taken. Consider what gray zones might exist in your permission structure, and try to accommodate as many options as you can.

Another common sticking point with AI is data collection. Often, it can be helpful to save information from past interactions, but storing this kind of data requires real attention to user permission and data management.

If you want to create a system that can “remember” things, you also need to make sure it can “forget” as well—and that the user can not only see but has final say in what exactly what gets remembered. An ideal permissions flow will not only ask for a user’s approval in the moment, but also create a space where they can see the history of what they’ve given access to and when—and allow them to revoke that access or permission at any time.

UX Pattern: Estimates and Confirmation

This one is pretty simple, so we won’t spend too much time on it, but another crucial aspect of transparency is making sure users know exactly what they’re committing to when they approve an action request. In addition to approving the actual steps and plan (as we discussed earlier in the Trust post), they also need to know how much time it’s going to take and what it will cost them in money or tokens.

Even if we can’t specify an exact amount, providing rough estimates generally gives users enough information to work with—and to potentially revise their request if it’s going to exceed what they’re comfortable with.

UX Pattern: Solo Execution Indicator

Similarly to the marking that denotes which content was AI-generated, it’s also a good idea to have some kind of visual signal for when an AI tool is acting independently. If, for example, you’re going to allow an agent to take control of the user’s browser, then there needs to be a banner, sidebar, outline or some other kind of indication that the user is no longer driving the interaction.

Not only is this a good thing to do just for transparency—so the user understands the current state of the system—but also so they don’t unintentionally interrupt or confuse an ongoing process. It’s an especially important consideration for processes that you know will take an extended period of time, where the user may step away and come back without keeping track of everything that’s happened while they were gone.

Read next: AI UX Patterns to Show Meaningful User Benefit

AI tools are often framed as being a kind of personal assistant for the user, an intelligent junior coworker they can delegate tasks to. However, as anyone who’s ever delegated a task already knows … sometimes that means things won’t get done the way you would have done them.

When users are working with our AI tools, they need to know that they are still ultimately the ones in the driver’s seat. After all, there’s very little value in being able to assign the AI tasks if you can’t step in as you like to make adjustments, corrections and fixes yourself (just like you would with a real junior coworker).

UX Pattern: User Override

Sometimes, you know something is going to be wrong before the work is even complete. The sooner a user can step in to abort an obviously incorrect process, the better the experience will be all around: fewer wasted tokens, less wasted time and less repetitive work are all good things.

Wrong responses can (of course) be the result of AI hallucinations. But just as often they’re the fault of poor prompting, changing project specs or just straight up user error (typos, forgetting to include a requirement, etc.).

Realistically, the “why” isn’t really important here, other than to show just what a common scenario it is. What matters is how we empower users to handle it that matters.

It’s important for the user to be able to stop or override an AI action at any point—whether that’s during content generation, partway through an agentic workflow, when running code or something else entirely. If the user is unable to abort the process, then they’re not truly the ones in control—and that, frankly, isn’t acceptable.

One of the most reassuring things we can offer our users is a clear and prominent “emergency brake” they can slam to bring everything to a halt for any reason. That means it can’t be hidden in a menu somewhere or involving some specific command they have to remember (which they won’t in a high-stress moment).

We need to give them the equivalent of a big red button they can slam and make everything stop when they need.

UX Pattern: Version Control

Of course, once a user has stopped a process, we can probably guess what they’ll want to do next, right? Undo the incorrect work.

Even way before AI, Nielsen’s heuristics listed “safe exploration” as one of the core principles required for a good user experience. That means that users should be able to navigate back and forth, click and unclick things, and generally just kind of mess around in a piece of software without getting stuck or unintentionally making permanent changes. Sometimes a user will try something and decide they don’t like it or it didn’t do what they thought it would—and in those cases, we want to make it as easy as possible for them to roll back to an earlier state.

This kind of safety net was always valuable, but now that we’re dealing with non-deterministic output, having some type of version history is pretty much a non-negotiable.

Of course, the level of “version history” that’s required will differ based on the task. The Git style of version control that we’re used to as developers is probably more than you’ll need in a user-facing application. If this is a simple conversational interface, you may not need this at all; the user can just rephrase their question and try again when they don’t get the results they wanted.

If your AI tool is doing something more complex, such as creating and editing a document, then simple undo and redo buttons that allow users to move back and forth within the last 10 (or so) steps might be enough. If your app is facilitating truly advanced work, then it may be worth building in the mechanisms for checkpoints, save states or true advanced version control.

Consider what kind of tasks your user will be working on with your AI tool and how significantly each step forward is likely to change the existing content.

Ideally, this will also allow users the specificity to make targeted adjustments, rather than wiping out and replacing everything that happened in a given step. It’s common for AI-generated results to have a mix of quality in the output; users may want to keep some aspects while reverting others. The more control as we can give them over that creative process, the more enjoyable it will be to collaborate with our AI tools.

This is especially true now, as the cost of tokens is starting to tick up significantly. Having granular control over what gets reworked allows for more specific and productive iteration, rather than having to just say “try again” and effectively start over from scratch each time.

Read next: AI UX Patterns for User Transparency

Hand-in-hand with trust comes clarity. Clarity is one of the most important aspects of creating a good user experience, generally—and the stakes only get higher when we start incorporating AI.

Because so much of AI still feels like an unknown our users, we need to be as descriptive and straightforward as possible about what’s happening at any given time. The more insights we can give them about what our software is doing and what they can expect to happen next, the more comfortable they will feel engaging with our AI features.

I’ve noticed that there can be a kind of impulse to position AI to users as “magic,” not only in marketing but also within the software, itself. We don’t have to look any further than the prevalence of the AI sparkle icon to see example of that. However, while that might feel mysterious and cool, it’s not accurate.

Our users deserve clarity over dramatics. They want to know what’s going on and how a given output was created, and there’s no reason for us not to pull back that curtain wherever we can.

UX Pattern: Live Generation

One of the most obvious ways for us to do this is with streaming text or similar live generation of content. Not only is this is a great way to disguise the latency issue of AI generation (after all, nobody likes to watch a loading spinner), but it’s also a fantastic way to show the user what’s happening in real time.

If we make the user wait until an entire response is generated, there’s a non-zero chance that it won’t actually be what they wanted. However, if we start showing a partial response as it’s being generated, we give our users the chance to start assessing it immediately. That means they can start coming up with followup questions, adjustments or simply stopping the process entirely if it’s not returning what they expected.

This also engages the user as an active participant in the process, helping to prevent the XKCD “code compiling” experience of pressing a button and then walking away. You’ve probably experienced how much harder it is to complete a task if you’re constantly disengaging from the workflow. Even if you know that a process only takes a minute, if there’s not something to keep you there, you’ll start checking your emails, replying to Slack messages, scrolling social media … and just like that, a one-minute wait becomes a 10-minute detour, making it much harder to pick up where you left off. The more we can prevent this for our users, the more productive they can be with our tools.

UX Pattern: Thinking Aloud

Another thing that can help remove the wall between the AI and the user is having it “think out loud” as it processes a request. Similarly to live streaming, this also improves a user’s confidence level in the output because they’re able to kind of follow the breadcrumbs and have a deeper understanding of how a given conclusion was reached.

After all, we do this all the time when talking to other people! If we’re presenting an idea, we know that it’s helpful for us to talk through the rationale behind how we got there and why we think it’s the right choice. Explaining ourselves is a very natural part of human interaction that we’ve come to expect, and when we don’t see that mirrored in the systems we use it can feel frustrating—like something is being intentionally hidden from us.

Additionally, seeing the chain of thought process allows for better, more accurate revisions when the output wasn’t what they expected. If the user can understand all the steps that happened between points A and F, they can pinpoint where things went off the rails, allowing them to give more specific instructions or clarify ambiguous requests.

UX Pattern: Highlight Changes

Some patterns are easy to adjust from their previous non-AI usage into this context. Highlighting new content is one of those: it’s not groundbreaking, but when combined with everything else, it’s immensely helpful in helping users keep track of AI actions—especially when an agent is acting autonomously.

The basic idea is that when new content appears or something is updated, it gets specially marked for the user to draw their attention to it.

Sometimes that might mean literally moving their focus up or down the page to see what’s changed—like when new messages appear in an ongoing chat and the message history automatically scrolls down to display it.

But other times, it can just mean drawing the user’s eye back to a space they might not have been actively watching, even if that doesn’t include any literal movement on the page—like changing the color of revised text, putting a box or highlight around new material, or marking lines of code that are different.

Read next: AI UX Patterns for User Control

The number one, by-far biggest hurdle that we need to overcome in order for our users to engage with the AI features we’re building is trust.

Right now, to the average user, AI is a black box. Many users simply do not understand, from a technical perspective, how AI works. When you don’t understand how something works, it makes it very, very hard to trust the output.

On top of this, just about everyone who has interacted with an LLM (large language model) before has, at some point, seen them hallucinate. Even as the models keep getting better, we’re still not at the point where we can claim that any tool will be 100% hallucination-free. There’s always a chance—even if it’s just a small one—that the AI will provide an incorrect response. How many times can a user see output that’s clearly wrong and still trust it?

It’s easy to think that the answer to this is to try to position the feature you’re launching as the exception to the rule: “Other AI tools might not be trustworthy, but ours is different—higher quality, safer, more reliable,” so on and so forth.

However, not only is this questionably true (after all, not many of us are actually training our own models, so a lot of this is simply outside our control), but it’s also an extremely difficult thing to sell your users on. In situations where we cannot promise truth, we have to go above and beyond to earn it. Our honesty about the current capabilities and limitations of AI will go a lot further with our users than the denial of any potential problems.

Rather than trying to convince users that our solution is inherently trustworthy, we can instead build in patterns that empower users to see when incorrect information is returned and give them the tools to correct or mitigate it. You know the saying “trust but verify”? That’s the goal here.

UX Pattern: Citations

By citing the references in an AI-generated response and linking users directly back to the source material, we give users the information they need to validate AI output. The more a user is able to click through and see where an answer came from, the more they’ll be able to trust the content—even if they don’t check every source, every time.

In addition to allowing our users to vet the answers, citations also have a second important purpose: they allow users to repurpose the material in their own work while maintaining a trail of accuracy. This is important for their own credibility and reputation—after all, how often would you share content from an unverifiable source if you knew any errors would be ultimately attached to your own name?

Generating output for the user might be the last step in our process, but it’s just the beginning for them. Users want to take that content and turn it into a report, an email, a campaign, a presentation. But if the output can’t be cited and trusted, then it simply won’t be used.

There are a handful of different ways we can implement this, and which one you pick will depend on the feature you’re building and the context in which it’s being used.

A few popular approaches include tooltips, in-line links and side panel reference windows. Tooltips will allow you to provide a small snippet of the relevant quote, which is great for increasing credibility. Links are, of course, ideal for when the content comes from an external source (like another webpage) as opposed to an internal source (like a document in a shared drive). If the feature you’re building is meant to support more research-oriented work, you might consider adding a side panel where the user can explore the source material in more detail, positioning the AI assistant as more of a librarian than a subject matter expert.

UX Pattern: Action Plans

The other place where trust factors heavily into AI work is agentic workflows, where the AI is “thinking” and executing work on its own. This, understandably, can be pretty concerning for users depending on the stakes of the project and how easy or hard it is to roll back incorrect actions—which is when keeping the “human in the loop” really becomes crucial.

One of the best ways to help users trust these systems enough to use them is to show an action plan to the user and allow them to approve it before the agent begins work.

This has become a fairly common flow in many foundation models. If you’re using agentic features in Claude or ChatGPT, then you will have seen it create a list of the steps it will take to accomplish a given task, then ask for your confirmation before beginning.

Of course, there are settings you can change to toggle this off or always allow it—which is important if you’re going to be repeating a particular flow over and over and don’t want to have to babysit it. (Spoiler alert: we’ll talk more about permissions in the “AI UX Patterns for Transparency” article later in this series.) However, if no plan is ever shown to the user and an action happens without them understanding why or how, it’s awfully hard for them to trust both the result of that action and the agent, itself.

UX Pattern: AI Generated Content Markers

There is understandably—and I would even argue, correctly—quite a bit of skepticism right now around whether or not content is AI-generated (and just in case you’re curious: this post was 100% handwritten, haha). You’ve probably seen exchanges online where someone shares a photo or video and another person is immediately commenting to tell them it’s not actually “real.” When we spend so much of our time and energy second-guessing and investigating the content that’s shared with us, it doesn’t exactly foster an environment of trust.

For now, AI-generated content is highly polarizing. While some users have heavily leaned into using it in their daily lives, others will react to it negatively and dismiss it as “slop.”

The ability for AI to generate text, images and video that is nearly indistinguishable from human-created work is very new, and for many users it’s something that still feels uncanny and unsettling. I don’t say this to start any kind of debate. While it seems harsh to say it, our own personal opinions on AI-generated content don’t matter much in this context. What’s more important is the awareness that our users will react to AI-generated content in a wide variety of ways, and not all of those ways will be positive.

So, if we want to include AI-generated content in our applications and we’re not entirely sure how our users will feel about that, what can we do to retain their trust?

One of the easiest things is to just mark any AI-generated content as such. This can be as simple as a disclaimer in the app store description, a watermark on a photo or an asterisk at the end of a sentence.

When we do this, we remove the potential user perception of us trying to “sneak” AI-generated content into our software or somehow pull one over on them. If we’re using AI and we think it’s the right fit for our work, then there’s no shame at all in designating where it’s been used.

Depending on where the AI-generated content is being used, it also helps clue our users into aspects they may need to manually verify—rather than having to review everything as though it was AI-generated, if that’s not actually the case.

Read next: AI UX Patterns for User Clarity

AI is a truly unique new technology: rapidly developing, and with so much potential to improve systems and software in ways that we couldn’t have even dreamed of just a few years ago.

However, along with all that potential is no small amount of risk. AI’s non-deterministic nature means that output can wildly range in quality, format, style and accuracy. On top of that, it requires entirely new types of interaction patterns to use. We’ve seen the emergence of new vocabulary, techniques and sometimes entire roles to address that need!

For those of us who live and breathe this technology every day, concepts like prompt engineering, hallucinations, retrieval-augmented generation and so much more have become a regular part of life. But for the vast majority of our users, that simply isn’t the case.

The Developer / User Gap

In any kind of technology, there’s a gap between the developer—who has, by nature, become the subject matter expert—and the user. The technical literacy of the average software engineer is always going to be higher than the average user of said software.

That’s where UX comes in. It’s how we bridge the gap between what we intended when we built the application and what the user actually … well, experiences. After all, it doesn’t actually matter what our software can do if our users hate using it so much that they avoid it at all costs.

Right now, AI has a serious UX problem. Our users are seeing AI features get added to basically everything right now—from their work software to their social media apps, right down to their computer and phone operating systems. But, as a wise technologist once said: “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

We’re pushing users to adopt these new tools and features, but we’re not making it easy to do so. It’s common to see situations where a user is presented with a poorly designed AI feature they have only the barest idea how to use. Then, when they try it and it doesn’t do what they wanted or expected it to do, they feel annoyed, off-put and negative about AI, generally.

The more times users try an AI feature and get subpar results, the less likely they are to engage with it again in the future—which means that as the creators of these features and software, we only have so many chances to get this right before our users disengage and stop trying at all.

In my personal opinion, the knowledge gap between developer and user when it comes to AI is one of the widest I’ve ever seen. That makes it extremely hard for us to build AI-powered features that our users will actually get the full benefit from.

But, thankfully, this isn’t the first time we’ve had to introduce complex new technologies to our users. We have decades of user interface design history we can learn from!

Adapting Existing Patterns

For example: when Macintosh introduced their graphical user interface, it was—like AI is now—something very different and unfamiliar to their users. A large part of their success and reputation was built on their ability to create a user experience that met users where they were. They borrowed terminology and user flows from real life, included lots of icons and visual representations, and walked users through how to get the most out of their computers.

Over time, as the average user became more comfortable and literate in the space, the UX evolved with them and we start to see more technical terms and fewer abstractions. 

Look at the difference here between the Control Panels in Macintosh System 1 and System 6:

If you’d presented a System 1 user with the words “Rate of Insertion Point Blinking” or “RAM Cache,” it would have been meaningless to them. Similarly, we see the low and high volume icons are gone in System 6, along with the turtle and rabbit speed icons—that kind of more literal depiction isn’t needed anymore.

Right now, we’re probably somewhere around System 3 in this (now very extended) metaphor of introducing AI to users. We may not need the turtle and rabbit icons anymore, but we also can’t just assume they’ll sit down with our AI software as experts.

The good news is that (unlike the System 1 Macintosh UI) we’re not starting from scratch. Our users already have mental models about software usage that will carry over to what we’re building—they just won’t always map over exactly one-to-one.

That’s where we come in. As developers, it’s our role to leverage patterns users are already familiar with, combine them in new ways and introduce them to our users gradually in a way that doesn’t feel overwhelming. A good user experience will not only provide a user with the tools, but also guide them through how to use them.

For instance, let’s consider an AI chat interface. From a purely UI perspective, chatting with an LLM is almost—but not quite—like chatting with another user. We’ll be able to borrow some familiar patterns, like having the user’s chats show up on one side and the AI’s chats on the other, messages appearing above an input field with a send button, a scrollable message history and more. That gives our users a great jumping-off point as well as a lot of visual clues about how to start interacting with our AI chat.

However, the experience isn’t quite close enough that we can just lift an existing interface for direct messages and repurpose it wholesale—a chat interface that was built for two people won’t have the accommodations we need for things like adding reference sources, pausing or stopping an in-progress reply from the LLM, leveraging agentic tools or integrations, and more.

Those are the kinds of places where we need to adapt existing UX and UI patterns into something new. We have to be the bridge, helping our users transition into familiarity with AI experiences.

We can see the difference here. Compare this Copilot Research Agent new chat with the new Teams chat below:

Both have familiar aspects such as text boxes, the “plus” to attach files and so on, but the Teams chat assumes a much higher level of familiarity. It doesn’t spell out any of the iconography used, and we don’t see some of the elements intended to lower the barrier of entry (such as the examples, large text buttons or voice interaction options).

Can’t We Just AI-Generate This?

Before we really dive in, though, I think we have to address the elephant in the room: why not just have the AI create these solutions for us? Why do we have to be the ones who design and build these new patterns when we have technology that can generate interfaces for us now?

The problem with that is that an AI can only “create” things that already exist. It’s fantastic for looking at existing common patterns and replicating them—but (as discussed) the new patterns for AI interfaces just don’t exist yet. Or, at the very least, they’re still being rapidly developed and changing all the time as the technology advances.

There’s not a long history of standardized and familiar AI-related interfaces that can be referenced to solve this problem, so (at least for now) we have to solve this one on our own. Maybe that will change down the road—but for the time being, this is still a very human problem.

Additionally, as many folks (including our users) have begun to notice, the design an AI creates will be … well, a lot like every other design out there.

AI can reference and remix, but you’re not going to get brand new concepts from it. An AI-generated UI tends to look pretty darn average—and while that can be a good starting point, it’s not usually a good ending point. If you just need a quick landing page, it will probably do the trick. But since we’re dealing with a whole new interaction mode that needs more attention paid to the UX rather than less, it’s just not going to be enough to get us where we need to go at the quality level our users deserve.

The Five Categories of AI UX Priorities

So: if we’re going to build new patterns and new interfaces to help our users get the most value out of this technology, where do we start?

Well, like most things in design, it’s best to start with the user—specifically, the user’s problems. That means that when we’re thinking about building our AI features, we need to be thinking about what challenges our users have with AI and the user flows that will mitigate those issues as much as possible.

From the user research I’ve been doing and the users I’ve spoken to, I’ve grouped the main priorities into five categories:

1. Trust
2. Clarity
3. Control
4. Transparency
5. Meaningful Benefit

In this blog series, we’re going to discuss each of these in depth—understanding the problems our users have when using AI, and looking at some examples of patterns or techniques we can employ to address them. By addressing each of these, we can create AI experiences that support our users through the introduction of this new technology and empower them to use it to its fullest potential.

Read next: AI UX Patterns for User Trust

When my daughter spills her drink, she comes to me to tell me it happened.

In that moment, I have two options:

• Act: “Go grab a towel and clean it up.”
• Ask: “How do you think we can fix that?”

The first gets the mess cleaned the fastest. The second takes longer but lets her think.

She grabs paper towels, maybe uses her shirt. She asks for help, or she figures it out herself. Either way, she’s not just following instructions. She’s solving.

It’s a small moment, but it captures something important about how we approach problems.

When we turn a problem into a question, something shifts. Our brains respond differently to questions than to instructions. We get more creative and more motivated. We find solutions we wouldn’t have reached if we’d just executed.

The Push for Execution

In fast-moving product teams, that shift doesn’t always happen naturally. We’re under pressure with tight deadlines, sprints and bugs to fix. There’s a push for execution. The problem gets defined, and a solution shipped. This is efficient but not necessarily effective.

I see it with clients too. There’s a tendency to jump straight to conclusions. Create something, move to the next thing.

We’ve manufactured the wrong sense of progress. We’ve flattened our thinking to activity-based monitoring. We measure work done, not impact made.

And the systems we operate in make us fear being punished for slowing down. But slowing down doesn’t have to be negative. It’s adding depth and establishing foundations to build on.

I’ve seen it happen more than once. A team delivers exactly what was asked. On time and according to spec. But the problem isn’t solved. Not because of poor execution, but because questions were not asked.

The solution was locked in before the problem was understood.

Diverge Before You Converge

This is where design thinking offers something valuable. Divergence and convergence.

Divergence is expanding. You open up the problem space, explore possibilities, challenge assumptions and resist the urge to settle too quickly.

Convergence is getting to the point. You bring constraints back in. Budget, technical feasibility, timeline. And you shape your exploration into something actionable.

Most teams are good at converging. They ship.

But divergence? That takes discipline. It means staying in the question longer than feels comfortable.

How Might We ... ?

A practical tool for divergence is the how might we method. It’s simple. Take any problem and reframe it as a question starting with “how might we.”

The phrasing matters. How might we is optimistic without being naive. It assumes a solution exists but leaves the how open.

Here’s what it looks like in practice.

• “Users keep dropping off at checkout.”
  How might we reduce the friction between cart and payment?

• “Our onboarding takes too long.”
  How might we get new users to their first success faster?

• “Admins can’t manage permissions at scale.”
  How might we make it easier to give multiple people the right access?

Each reframe does the same thing. It takes a complaint or observation and turns it into a space you can explore.

The problem stays the same. But the number of possible solutions grows. That expansion is where the real value lives.

The Question Before the Prompt

This matters even more now that AI has become part of how teams work.

AI is good at execution. Like generating code or drafting copy. It’s a powerful convergence engine. But that’s also the problem.

AI defaults to answers. Give it a problem, it will solve it immediately. It won’t ask if it’s the right problem. It won’t explore alternatives.

That doesn’t keep the frame open. Convergence without divergence is just fast guessing. You end up with the wrong sense of progress again. Shipping solutions to problems nobody questioned.

So the skill that matters most right now is one AI doesn’t default to. Asking more questions. Keeping the frame open longer. Resisting the pull to converge before you’ve explored.

Give AI a vague problem, you get a vague answer. Give it a sharp question, you get a sharper solution.

Takeaways

The question mark might be the most underrated tool in your workflow. Not because questions slow things down. But because they open things up.

Before you assign, build or prompt, ask the question that reframes the problem: How might we?

Because the quality of your answer will never exceed the quality of your question.

Question everything. On purpose.

A customer threatened to cancel. Full panic. A board meeting to discuss how to retain him, budget approved and allocated to honor his demands. A scrum team started fixing. I flew to the UK to sit with him.

We had redesigned the entire UI. Not a small fix. We completely overhauled the user experience. From a very old tool with toolbars to an application with a strip.

We didn’t just move buttons to ribbons with tabs. We restructured the entire information architecture. Fixed, opinionated workflows that guided users through the critical steps to model complex geological concepts.

He hated it. He demanded a rollback.

I reserved time to interview him. Asked questions. Listened. Tried to sense his reality, his context, where he was coming from. How he was perceiving the changes.

What I discovered changed everything.

He wasn’t even using the latest version. He hadn’t tried the new UI at all. He had simply refused. While we moved on and developed the next generation of our software, he had not. He was still way behind. And somewhere at the back of the queue, feeling ignored and dismissed.

That feeling made him rage. But it also highlighted a bigger problem.

In the room next door, two junior geologists were being trained on the exact same concept. They loved it. The design was exactly what the team needed. What he needed too.

He was desperate for a transformation in his company. A way to step back from his expert role and become a guide for the younger generation. Once I explained the concepts, he understood. He was appreciative of the work. He was on board.

We almost rolled back an expensive, fundamental shift based on an emotional rant from a customer speaking from expired context.

It was never about the concept. It was about misunderstanding context.

The Linearity Trap

A backlog is not a queue. It’s a context-sensitive collection.

Every item in it was written at a specific moment, about a specific reality. That reality changes. The backlog doesn’t update itself.

The linearity trap is treating it like a queue anyway. Adding new requests. Reorganizing. Managing delay. Shipping. Without ever asking: does this still belong in the collection?

The customer had been reporting improvements and bugs for a long time. But we moved on. We shipped. And while we did, he stood still. By the time his feedback reached the top of the queue, the context it was written in had long since changed.

The problem wasn’t that we were behind. We were committing to work that was already outdated.

Delay Is Not the Problem. Decay Is.

A lot of backlog management is really about managing time. Managing delivery. Focused on shipping as much high-quality work as possible by the promised date.

Managing delay is a conscious decision. It’s about choosing when to push something back. That’s prioritization. That’s what I wrote about in the previous article.

But the bigger problem is decay.

Decay is what happens to the work you’re not doing. While you’re waiting, while you’re delaying, what has been written down is eroding. Rusting. Because context expires.

It’s like the best-before date on a package. By the time you grab it from the shelf, you need to check the date before you consume it.

A lot of backlogs are just queues constantly filled with requests, feedback and bug reports. Nobody checks the date. Nobody asks: is this still valid?

I’ve seen old backlog items treated as still true when the context they described no longer existed. They were no longer worth pursuing. The more context you capture when you write them, the easier it is to later assess whether they still fit.

Something can be very old and still be good. But developing the sense to distinguish that is the work. Understanding whether it’s expired or not. Whether it’s still safe to consume.

In the UK, the right response would have been to delay any work on his requests. To first discover whether his feedback was based on expired context. Instead, urgency won. And decay nearly cost us everything.

Urgency vs. Timing

The urgency that came up was really signaling a demand. Someone pushing. Pressure.

And under pressure, you don’t always make the most strategic decisions. The board panicked. Money appeared. Time was freed up. Nobody stopped to check the return on investment, whether it was worth it. It was an emotional response.

That happens. We’re humans. And that emotion is sometimes also why we close amazing deals and do great things for loyal customers. So it wasn’t all wrong. Part of the response was also recognizing the loyalty of a customer who had been with us through harder times.

But urgency gets the attention. It drives the emotion. And what we need underneath it is judgment.

Timing is a readiness signal. It’s not driven by pressure. It’s driven by context.

• Is the customer ready?
• Is the market ready?
• Is the team ready?
• Is the moment alive?

Those are timing questions. Urgency can’t answer them.

Compound vs. Corrosion

We’re always looking for momentum. Shipping as much as we can, as fast as possible, without compromising quality.

But without sensing whether the time is right, we create progress without compounding.

Compounding is making sure what you ship ties into the next thing and builds over time into the desired version of your software aligned with your vision. Creating conditions so that what comes next makes sense.

The opposite is corrosion. Work that sits in the backlog long enough starts to corrode. And when you finally act on it, you might ship something that corrodes the foundation of your software rather than building it. Hurting not just momentum but overall quality.

When we made that big shift to the UI, we should have reassessed the entire backlog. Diagnosed it. Made sure there was no outdated work hiding in the queue because of it.

We didn’t. And a decayed issue almost corroded the core concept.

Context Sensitivity

Why did feedback and previous user requests corrode? Because the timeframe wasn’t short. That concept developed over multiple months. We should have been capturing the context shift and using it as a filter on our backlog to stay ahead of it.

But capturing context is the hard part.

The world moves on. Your market, client and economic reality change constantly. The technical reality shifts the moment you upgrade systems and build with new technologies. The context you’re shipping into is constantly moving.

And on top of that, emotional states. Not everybody handles change well. Not everybody’s personal context is aligned with where you’re going.

You need to develop a sense to see those shifts.

Keep a Human in the Loop

AI is very good at capturing context. Writing it down. Cross-referencing it. Flagging patterns. It can help us see and track everything we can’t manage on our own.

But the moment context is written down, it’s already outdated. And managing that expiration date is a collaborative effort. AI can help cross-check against captured context, flag a customer as a potential churn risk, surface old backlog items that conflict with new ones.

What it can’t do is sit in the room.

What I did with that customer—reserving time, asking questions, listening—that’s a nuance. A human sense that becomes more important as we connect more and more data at greater and greater speed.

AI can read the signal. It can’t always hear what’s between the lines. The emotional rage that looks like a high-priority request but is really a loyalty problem. The developer who goes quiet in sprint planning. The feedback that reads as a bug report but is actually a cry for better onboarding.

That’s not in the data. It’s in the room.

Closure

Timing isn’t about managing deadlines. It’s about reading whether the moment is right. Priority tells you what matters. Timing tells you whether now is the moment to act on it or not at all.

The backlog or data alone won’t tell you that. You need to read the room. Develop that sense. Check the expiration date. Keep humans in the loop for the context AI can’t capture.

We ship when it matters. We shred when it’s expired.

On purpose. By design.

It depends.

If you ever ask a design question, most likely this is the answer. It depends.

It’s true. Everything depends on something else. There’s no black or white, right or wrong answer, because it always depends. This is the context you’d need to understand. How it’s related.

This applies to your backlog as well. In previous articles, we covered priority and timing. When does something deserve attention, and in what order do you pick up work. And even when you know what to pick up, when matters.

So let’s say you know what work to pick up and when to pick it up, the question still worth asking is: what does it depend on, and is anything else depending on it?

We call this “dependency management.” I think that means more than a dependency graph. It’s about relationships and context.

The Regulatory Reflex

We often manage dependencies well as part of backlog management to mitigate or address risk. And there’s a reflex, a regulatory reflex, that makes us lean toward risk avoidance.

A dependency gets seen or projected as a negative thing. That risk, the thinking goes, can then be mitigated by reducing dependencies.

I’ve seen this a lot in product development. “Dependency management” became a synonym for reducing dependencies. Avoid the vendor. Build it yourself. Own the code, own the outcome. Right?

It sounds strategic. But it rests on the wrong definition of independence.

Does True Independence Actually Exist?

Here’s the question to ask yourself: Does true independence actually exist?

The word independence literally means “not to hang from.”

In (not) + pendere (to hang).

The whole concept is built on negation.

But you always depend on something. A framework, team, budget or a market. Even the time you have in a day.

The question isn’t whether you depend. It’s what you depend on and whether that dependency works.

Fortunately, there’s another way to read that same prefix.

The in- in independence has another root. The one in include, inject, integrate, insight. In as into, within, part of. Not negation. Integration.

Read that way, independence doesn’t mean “not hanging from.” It means “hanging in.” Being part of something. Integrated into a larger system. Intentional.

That’s a very different idea than avoidance.

You’re not running from dependencies. You’re choosing which ones to integrate into. Seeing them clearly. Selecting them deliberately. Keeping the freedom to shift them when the system needs to evolve.

Not the absence of dependencies. The presence of deliberate ones.

A purposeful assembly of parts. That’s what we should mean when we say “independent.”

A New Definition: Clarity, Choice, Change

True independence is about intentional integration, based on three requirements:

• Clarity: You can see what you depend on.
• Choice: You can select your dependencies deliberately.
• Change: You can shift them when you need to adapt to reality.

Dependencies you see clearly, chose on purpose and can shift aren’t risks. They’re the assembly.

The risky ones are those you can’t see, didn’t choose and can’t change. And those are often the ones created by chasing the wrong definition of independence in the first place.

The Pain of the Wrong Definition

I worked on an edge connectivity ecosystem for remotely operating oil rigs. The goal was to standardize how software ran at the edge. Authentication, data access, data streaming, etc. All the foundational components every new project needed.

We built those components once, so other software teams wouldn’t have to rebuild them every time.

It was a strategic bet. I did a lot of the narrative work, high-stakes pitches, executive alignment, the whole thing. The argument was simple: consolidating common parts saves money, reduces waste and lets the company move faster.

The numbers worked. But the adoption didn’t.

A lot of product teams resisted. Some flat-out refused. The cost-saving argument was easily offset by something they felt more acutely: the fear that being tied to a centralized platform would hold them back later. That when they needed to solve a new problem or make a different strategic choice, this dependency would be in the way.

They heard the pitch as: Give up your freedom to build, and we’ll give you efficiency.

And under the old definition of independence (the negation one), they were right to resist. We were asking them to depend on something they didn’t fully control.

But that’s not what was actually happening.

We weren’t asking them to give up independence. We were asking them to redefine it. To stop measuring freedom by what they built themselves, and start measuring it by what they could deliberately depend on. Clearly, on purpose, with the ability to change.

The pain wasn’t the dependency. The pain was the wrong definition.

What the Ecosystem Actually Offered

Before the platform, every team built authentication, data access and streaming from scratch. They depended on their own budget, their own developers, their own expertise. Their speed, their skill and their security were limited by what each individual team could pull off.

The result was scattered software. Reinventing the wheel. From a company perspective, it was waste: the same work, done badly, in parallel.

What the ecosystem offered wasn’t fewer dependencies. It was better ones.

A centralized team with deep expertise. A dependency the company could see, manage and improve. The freedom to shift the underlying technology when something better came along, because the contract was clear and the boundaries were defined.

The product teams’ dependencies didn’t shrink. They grew. But they became something the company could actually manage.

A purposeful assembly, with each part chosen.

The Same Pattern, Smaller Scale

The same pattern showed up in our design system work.

Teams had been forking and falling out of sync, maintaining custom code originally built by an external agency. When the agency engagement ended, we kept the code, but not the expertise. Internal teams were on the hook for something they hadn’t built.

The fix was the same shape as the platform shift: move from custom in-house code to a well-documented third-party framework. We migrated to Progress Kendo UI. The license fee was new but visible. The hidden internal cost, buried in cross-charges and undocumented maintenance, went away.

We even ran a hybrid model. Kendo UI for most components. Different libraries for charting and mapping if Kendo UI wasn’t the best fit. More dependencies, technically. But each one chosen on purpose. Each one we could see and could change if needed.

Different definition.

What Independence Actually Looks Like

The question was never how do I become independent? It’s what am I depending on, and does it work?

Independence isn’t escape from dependence. It’s intentional integration. Clear. Chosen. Changeable.

A purposeful assembly. That’s what independent should mean. On purpose. By design.

Design systems have long been cornerstones of building consistent user interfaces. They provide teams with a shared vocabulary for colors, typography, spacing and more, so that every aspect of a product feels cohesive and consistent.

Creating and maintaining these systems has traditionally involved a significant amount of manual work, including defining hundreds of token values, keeping them in sync across codebases and navigating lengthy review cycles.

AI is starting to change this. Tools now exist that can generate cohesive token sets from natural language descriptions, refine individual components without disrupting an entire theme and reduce the overhead of managing design systems at scale.

In this article, we’ll explore how AI integrates with design systems and tokens, what the workflow looks like in practice and what this means for teams building products today.

Design Systems and Tokens

A design system is a collection of reusable components, guidelines and assets that enable a unified user experience across a product. Design tokens, on the other hand, are the smallest building blocks within that system. They are named values that store visual design attributes like colors, font sizes, spacing and borders in a central location.

Instead of hard-coding values throughout our CSS, we reference tokens (with the help of CSS custom properties, for example) that can be updated from a single source of truth:

:root {
  --color-primary: #0058e9;
  --color-secondary: #666666;
  --color-success: #37b400;
  --color-warning: #ffc000;

  --font-size-sm: 0.75rem;
  --font-size-md: 0.875rem;
  --font-size-lg: 1rem;

  --spacing-sm: 8px;
  --spacing-md: 16px;
  --spacing-lg: 32px;
}

These CSS custom properties act as our token layer. When we need to change the primary color (e.g., color-primary in the example above) across an entire application, we update the token in one place, and the change propagates everywhere it’s referenced. For a deeper look at how tokens work and the different types (global, alias, component-specific), check out our previous article on design tokens.

The Traditional Workflow and Its Challenges

The typical process for creating a design system would look something like this:

• Designers define a set of tokens and visual guidelines in tools like Figma.
• Frontend engineers then translate those values into code (SASS variables, CSS custom properties or JSON token files).
• Teams iterate through review cycles to make sure everything aligns.
• When the design system needs to support a new brand or product variant, much of the above process starts over.

This workflow has served teams well, but it comes with friction. Keeping tokens synchronized between design tools and codebases requires constant attention. Starting a new theme from scratch means confronting a blank canvas of hundreds of variables that all need to work together, and as design systems grow to support multiple products or teams, the maintenance burden grows with them.

These are the kinds of challenges that AI is well-positioned to address. Not by replacing the decision-making that goes into a design system, but by handling the mechanical work of generating, adjusting and maintaining the token values themselves.

How AI Changes the Design System Workflow

With AI, the shift is moving from “manually define every value” to “describe intent, then refine.” Instead of opening a blank stylesheet and deciding what --color-primary should be, then figuring out what --color-primary-hover and --color-primary-active need to be relative to that base, we can describe the aesthetic we’re going for and let AI generate a cohesive set of tokens that all work together.

What makes this especially compelling is that modern AI tools, though not perfect, understand design principles! Instead of picking random hex values, these tools can apply color theory to create palettes with appropriate contrast ratios. Spacing scales follow consistent rhythms, and typography hierarchies keep heading sizes balanced relative to body text. The resulting token systems aren’t just technically valid; with some guidance, they can be designed to work as a coherent whole.

This doesn’t mean we hand off all creative control. The AI handles the heavy lifting of producing a complete, internally consistent token set, while we focus on the strategic decisions:

• Does this palette match our brand?
• Does the typography hierarchy support readability for our audience?
• Are the contrast ratios meeting our accessibility standards?

AI shifts our energy from the tedious work of defining individual values to the more meaningful work of evaluating and directing the system as a whole.

AI-Powered Theme Generation

To see what we’ve discussed above looks like in practice, we’ll walk through an example using Progress ThemeBuilder: a visual styling tool for customizing the theme of Telerik and Kendo UI components.

In the ThemeBuilder Generate panel, we can describe a theme in plain English. For instance, we might enter: “Generate a dark theme for an internal operations dashboard with charcoal surfaces, muted gray borders and subtle blue highlights for interactive elements. Keep the overall feel minimal and easy on the eyes during long work sessions.”

Within seconds, the AI analyzes the description and produces a complete design system. It doesn’t just set a few colors. It generates a full set of tokens spanning global values (the core palette), alias tokens (contextual mappings like info, success, warning) and component-specific tokens (button backgrounds, input borders, grid header styles). All of these tokens reference each other in a structured hierarchy, so a change to a global value cascades through the system in a predictable way.

The result is a production-ready set of tokens that we can export as CSS or SASS and bring directly into our project.

In the exported output, we’ll be able to see how the AI has generated a set of interconnected tokens. For example, the primary color would have corresponding hover and active states that maintain visual cohesion, and the base and on-base colors will enable readable contrast throughout the interface.

Design Tokens as the Integration Layer

At the core of this entire workflow is a simple but important idea: design tokens are the integration layer between AI tools and our component libraries.

When AI generates a theme in ThemeBuilder, it isn’t just producing abstract styling ideas; it produces concrete token values that flow directly into our CSS or SASS files, which our component library consumes.

.button-primary {
  background-color: var(--kendo-color-primary);
  color: var(--kendo-color-on-primary);
  border-radius: var(--kendo-border-radius);
  font-size: var(--kendo-font-size);
}

.button-primary:hover {
  background-color: var(--kendo-color-primary-hover);
}

In the above snippet, the button component doesn’t know or care whether the token values were defined manually or generated by AI. It references the same custom properties either way. This separation is what makes AI-assisted design systems practical. The tokens act as a contract between the theming layer and the component layer, so the source of those values (human or AI) doesn’t affect how they’re consumed.

This also means we can mix approaches freely. We might generate a baseline theme with AI, manually override specific tokens for brand alignment, and then use component-level AI theming to refine individual components (a workflow supported by ThemeBuilder). The token layer absorbs all of these inputs into a single, consistent system.

Wrap-up

For enterprise teams that maintain design systems across multiple products, teams and technology stacks, AI compresses the time between a design decision and its implementation. Instead of manually auditing hundreds of tokens when a brand update happens, teams can regenerate or adjust themes from a central tool like ThemeBuilder and export updated tokens to each project.

Governance still matters since teams still own the decisions around brand direction, accessibility compliance and cross-product consistency. But AI handles the mechanical work, so we can spend more time on strategy and less on manual token management.

Tokens remain at the center of it all. They are the shared language between AI generation tools and component libraries (i.e., the contract that keeps everything consistent regardless of how the values were produced).

Ready to see this in action? Explore Progress ThemeBuilder and see how AI-powered theme generation can streamline the way we create and manage design systems. For more details on design systems and ThemeBuilder, check out some of the previous articles we’ve written on this topic:

• The Role of Frontend Engineers in Design Systems, Part 1
• The Role of Frontend Engineers in Design Systems, Part 2
• AI Won’t Replace Design Engineers, But It Will Change How We Work
• Styling Telerik UI with AI in ThemeBuilder
• New in ThemeBuilder: Typography and AI Theming Enhancements

You know the feeling. Another feature. Another bug. Another stakeholder request that can’t wait. You fight the fire.

And somewhere at the end of the week, you look at your changelog and realize you’re no closer to where you wanted to be.

That feeling is the ER mindset. And if you’re building software, managing a product or owning a business, there’s a good chance it’s running your backlog.

The ER Is Not the Problem

The emergency room excels at prioritization under pressure. Triage nurses make life-or-death decisions in under 60 seconds. They sort by urgency and severity. They don’t treat the loudest patient first. They treat the one who needs it most.

But here’s what often gets missed: the ER is part of a bigger system.

A hospital doesn’t only treat emergencies. It prevents emergencies before they happen and treats patients who need real care. The ER is one room in a much larger building. A dedicated room with a purpose.

The problem isn’t the ER. The problem is when your entire backlog becomes one.

When everything is urgent, nothing is. You respond. And respond. And respond. And the work that deserves real attention—the strategic work, the preventive work, the work that would stop the emergencies from happening in the first place—never gets done.

What the ER Gets Wrong

The ER triages everyone who walks through the door. That’s by design. It has to.

But your backlog shouldn’t.

Most prioritization frameworks—like the Eisenhower Matrix, MoSCoW and RICE—jump straight to scoring. Urgency. Importance. Effort. Impact. They assume that everything entering the system deserves to be evaluated.

That is an expensive assumption. Because most backlogs are approached from an operational perspective. What’s urgent. What’s important. What’s next. Useful, but it skips the bigger picture. The vision, the version you’re building toward.

And that’s exactly what you need to ask: Should this be in the system at all?

The 3P Triage Framework

This is what I call the 3P Triage Framework. Purpose. People. Profit. Three-stage triage. Each one a filter before the next.

Purpose

Purpose is the viability check.

“On purpose” means the work is intentionally aligned with where you’re going. Not just relevant. Directional. Walking the line toward what you’re actually building.

“By design” means you have a clear version defined that you’re building today. Not someday. Not “we could.” Clarity on what version of the vision you are releasing next. One check. One big question:

• Is it on purpose and by design? Yes / No

If the answer is no, the item doesn’t fit. It gets filtered out before it’s ever scored. You assign it to a future version or remove it altogether.

This is an important step to add in backlog triage and the one often skipped. Without it, you triage everything. And when you triage everything, you’re back in the ER.

People

People is the desirability check. This is where urgency and importance come in.

How critical is this right now? What’s the impact if we don’t act? Who needs it? What does it unlock or block?

This is the proven system. The meat of prioritization. Eisenhower had the right instinct here. The problem wasn’t the framework. It was applying it without context.

When every item in your backlog has already passed a purpose check, urgency and impact become meaningful signals. When they haven’t, everything feels urgent.

Score both on a simple scale:

• Urgency: Low / Medium / High / Critical
• Importance: Low / Medium / High / Critical

Profit

Profit is the feasibility check. The final lens of reality.

Can we actually do this? What’s the effort? What’s the risk? What might we break, slow down or delay by taking this on? What do we gain? What’s the return on investment?

Not just “can we build it?” but “can we afford to build it right now, given everything else?” And is it profitable to do so?

Size up all three:

• Effort: S / M / L / XL
• Risk: S / M / L / XL
• Revenue: S / M / L / XL

I’ve seen teams spend a sprint fixing a bug that affected three users, while a performance issue slowing down everyone quietly compounded in the background. I’ve seen initiatives invented to add capabilities to a part of the product our vision was trying to make obsolete in the industry.

Sometimes the most strategic move is removing something entirely. Maximize work not done.

With this 3P Triage Framework, you now know the value, the priority of a task. But when do you work on it?

Priority Is Not Order

This is the distinction that changes how you use all of this.

• Priority is an understanding of value. It tells you what matters most.
• Order is a commitment to act. It tells you what’s next.

They are not the same thing.

A low-priority item can hold a high order position, because of timing, dependencies or readiness. A high-priority item might sit lower in the order because the conditions aren’t right yet. Confusing priority with order is where backlogs fail.

When they’re treated as the same thing, urgency drives execution. Again. Technical debt never gets solved. Prevention never gets resourced. You’re back building a response system instead of a product.

And the emergencies keep coming. Because nothing is preventing them.

Closure

The ER isn’t the problem. The ER mindset is. The emergency room responds to urgency. Your backlog shouldn’t.

Real triage starts with a check: Is this aligned with our purpose? Does it fit the design we have? Only then does urgency and impact matter. Only then does feasibility make it worth it.

That’s the difference between a team that responds and a team that builds. On purpose. By design.

Wiring up an LLM endpoint takes an afternoon; the harder engineering problem is building a UI layer that can absorb the inherent unpredictability of AI without introducing layout thrashing, inconsistent interaction patterns or sprawl that a small team can't maintain.

That's the problem Icanpreneur solved with KendoReact.

“The hard part with AI is not just calling a model – it’s designing complex, trustworthy workflows around it. That’s where KendoReact helped a lot.”

Icanpreneur’s platform orchestrates guided, AI-assisted workflows that blend business logic, structured data and real-time feedback into a familiar, approachable experience. Users move through Lean Canvas modeling, validation flows and strategic planning steps with AI augmenting their thinking along the way. They’re now used not only by early-stage founders but also by accelerators, innovation hubs and product teams inside organizations such as Founder Institute, Campus X, Science Park Graz, ABLE Activator, Sofia Tech Park, Visa Innovation Program Europe and Telerik Academy’s Upskill Product Management program.

Raw AI output can be unpredictable. Without a stable, consistent UI foundation, that translates into friction and mistrust. The consistency, predictability and performance of KendoReact in the UI layer turned the output of Icanpreneur’s AI assistant, IVA, into something usable and trustworthy. For Icanpreneur’s six-person team, KendoReact was the infrastructure that made AI usable at scale.

Icanpreneur’s Architecture

At a high level, Icanpreneur’s platform is structured as a layered system that separates UI composition and user interaction, server / API management and LLM orchestration.

KendoReact is the core of the Icanpreneur UI layer, allowing them to guide users through complex multi-pane screens, support long-running workflows with consistent UI patterns and handle advanced multi-step journeys without overwhelm. Every major module (Lean Canvas, conversational interview console, go-to-market editor, persona builder) is composed from the same KendoReact primitive set, themed consistently and governed by the same layout contracts. That decision paid compounding dividends as the product scaled.

In an AI-first platform, it can be tempting to start thinking about the UI as set dressing; just a thin layer over the APIs to make things “look pretty” for the users. However, AI interaction patterns are still very new and unfamiliar to many users. A UI that naturally folds AI into the user experience can be a real differentiator in the competitive market.

“Founders in partner programs started telling us that the interview, insights and go-to-market flow ‘feels like one tool – simple and intuitive, not five stitched together.'”

AI technology is impressive but UI engineers are still the ones who translate that potential into true value for the user. In Icanpreneur’s case, they needed stable layout primitives, reliable form controls and high-performance data visualization components – all of which had to present AI output reliably (while responses were streaming, partial or evolving) without triggering unnecessary re-renders or layout shifts. KendoReact provided that and more, empowering the team to focus their effort on user experience, business logic and AI orchestration.

Composability as a Force Multiplier

One of the most important architectural decisions was treating KendoReact not as a collection of finished widgets or mere building blocks to be combined but as true UI infrastructure. KendoReact powers everything from research dashboards and conversational interview consoles to mini-CRMs and multi-step go-to-market editors.

Foundation pieces were combined to create higher-order workflows that guide users through their interactions with IVA. Rather than building custom UI for each flow, the team defined composable patterns built on KendoReact primitives. For example, the multi-step validation flow reused the same layout + navigation structure, AI feedback panels reused consistent container and typography patterns and interview summaries reused standardized layout and card structures. Because the Icanpreneur team didn’t need to design complex new interaction patterns for each additional feature, they were able to implement quickly and iterate fast – smoothly layering their AI workflows on top of KendoReact’s component system.

Consistent UX for Novel AI Workflows

For Icanpreneur users, this meant that they never had to open a page and feel unsure of where to go or what to do next – even though the AI-powered technology may be new, it leveraged familiar and consistent patterns to guide them through the experience.

“Because all the AI-driven experiences reuse the same KendoReact components as the rest of the app, they behave in a predictable way. Users don’t have to ‘learn' a new interface just because AI is involved – it feels like one coherent workspace.”

Design-to-Code Fidelity

With KendoReact, Icanpreneur designers and engineers worked from the same component language, which meant no translation layer between design and implementation, no pixel-chasing and no divergence between what's mocked and what ships. Designers also created a custom design system using the Kendo UI Figma Kits and the Progress Design System Kit, which greatly reduced the time needed to create mockups and new pages.

“Using the Kendo UI Figma Kits and a custom Kendo theme, we aligned design and development from day one. Most new features now start as a quick sketch in our KendoReact-based design system and turn into a working screen in days instead of weeks.”

Increased Development Speed

AI-assisted workflows evolve quickly: new steps get added, feedback formats change and validation criteria expand. Because KendoReact components are extensible and themeable, the Icanpreneur team could meet these challenges while still preserving UX consistency. As workflows grew, the UI layer remained adaptable; less time debugging or re-writing UI logic meant faster revision cycles and more shipped features.

“New workflow-style features (such as a new research flow or AI-assisted editor) now typically go from idea to shipped version in days instead of weeks, because we mostly compose existing KendoReact patterns instead of building UI from scratch.”

The UX of AI

Some of the biggest challenges in AI-first applications are handling uncertainty (usually in the form of partial / still evolving responses) and guiding users through new workflows. The Icanpreneur team leveraged KendoReact’s design tools to create UX patterns that integrate AI feedback into existing, structured UI flows, so users are never left wondering “what now?”.

One of the most unique features of Icanpreneur is their Synthetic Customer Interview feature, which allows their AI assistant, IVA, to answer questions as though it was a potential customer in their target market. Not all teams have easy access to customers to run interviews with, so this allows founders to “stress-test” their hypotheses quickly across multiple scenarios. That output helps them refine their questions and assumptions before talking to real people. Afterwards, IVA reviews all the data (across both real and synthetic customer interviews) to summarize, highlight patterns and extract quotes and evidence that can be leveraged in personas and further market research.

“When we designed IVA, the conversational interview console and the research workspace, we could prototype and ship quickly because we already had chat-style layouts built from existing KendoReact Layout and Form components, multi-step flows for things like research setup and go-to-market editors and reusable Panels, Drawers, Dialogs and Data Grids for displaying AI outputs, suggestions and insights aggregation”

Using KendoReact meant that not only could they leverage these familiar user patterns – but also that common AI concerns (such as slow, partial or unexpected responses) could be handled with UI structures and error responses that users already knew how to interact with.

Performance and Scalability

Icanpreneur workflows are complex, multi-stage journeys. Moving from idea to hypothesis, validating with AI or human-led interviews, identifying patterns and extracting valuable feedback, generating personas and finally creating landing pages or pitch decks – any one of these alone would be demanding but all together they offer a true development challenge. Each step builds upon the previous and the context must be preserved as the user moves between them. Without careful performance engineering, rendering and re-rendering these views would quickly degrade the user experience.

AI workflows can introduce frequent state updates as responses stream in or evolve - for example, when IVA synthesizes interview insights or drafts positioning. In poorly structured UIs, this can lead to layout thrashing or lag. However, these updates render inside structured, well-optimized KendoReact components, so the Icanpreneur UI remains stable.

As features accumulate, custom CSS and one-off component implementations are a common source of bundle bloat and regression risk. At Icanpreneur, new features and modules all plug into the same KendoReact UI system (rather than introducing new patterns and components). That allows even a small team to control UI sprawl and manage bundle growth. Custom CSS – a common pain point for fast-growing applications – is significantly reduced and centralized, because the UI is themed consistently. This kept initial load times reasonable even as the feature surface expanded.

“When we introduce new AI-driven experiences, they use the same KendoReact components, so we see far fewer UI regressions. That made it much easier to roll out new AI features without exploding our QA surface.”

That smaller, bounded QA surface meant faster turnaround and faster time to ship, while the lower complexity means that the small team was able to manage the expedited growth without being overwhelmed. New features that reuse existing KendoReact components inherit known-good behavior, so regression risk didn't scale with feature additions.

KendoReact’s components are designed for high-density, data-heavy enterprise applications; no reinvention (or re-optimization) was required even for complex components like grids, forms and dialogs. KendoReact reduced the need to solve hard performance problems manually, allowing Icanpreneur to access enterprise-level quality with a startup-size team.

Icanpreneur: Powered by KendoReact

Icanpreneur began as a structured way to guide founders from idea to product-market fit. Today it operates as a full AI co-founder, with IVA empowering entrepreneurs to ideate, validate and grow their companies as a trusted partner.

By treating the UI layer as infrastructure and building on KendoReact from day one, the team was able to:

• Scale complex, AI-driven workflows with consistency

• Ship new features rapidly without fragmenting UX

• Deliver a coherent experience across classic and AI-powered screens

For teams building AI-driven workflows, the UI layer is crucial: it's what determines whether AI output becomes a usable, trustworthy product or a source of friction. Icanpreneur's architecture is a case study in treating that layer seriously from day one. Or, as the Icanpreneur team said themselves:

“A six-person core team is able to maintain and evolve a fairly large, AI-first product (research, interviews, personas, positioning, landing pages, sales decks, etc.) without a separate “component team” or design system squad – KendoReact is that system for us.”

For teams building AI-driven applications with complex workflows, treating the UI layer as infrastructure can dramatically reduce friction as the product evolves. For Icanpreneur, KendoReact became that foundation: explore how KendoReact could become that foundation for your team, as well.

If you want to master one thing in design, master this.

Not layout, color or typography. Contrast.

Because every design decision you’ll ever make is a decision about contrast. Managing the differences.

A Dashboard With Sliders

Designing is a bit like a mixing board. Every element has properties you can dial up or down. Size. Weight. Color. Spacing. Position.

When you move a slider, you’re changing its relationship to everything around it. That is contrast.

And like any relationship, it only works when the differences serve a purpose.

Slide everything to the center and you get a flat design. Slide everything to the extremes and you get noise.

But find the right positions—some high, some low, some barely there—and the design works.

The best designers I’ve worked with don’t follow all the rules. They play with contrast the way a musician plays with sounds. They know when to push a slider up and when to pull it back.

Differences That Mean Something

Here’s what most people miss about contrast: it’s not about making things look different. It’s about making differences mean something.

• A bigger heading isn’t just bigger. It means, this matters first.
• A muted label isn’t just subtle. It means, this can wait.
• Extra whitespace isn’t just empty. It means, breathe here.

Without intent, contrast is noise. With intent, contrast is communication.

That’s the difference between a designer who arranges and a designer who composes.

The Thread Through This Series

In this series, we’ve unpacked principles that designers use every day. Alignment. Hierarchy. Affordance. Balance.

Each one looked different on the surface. But underneath, they’ve all been about the same essence: contrast.

Alignment is about orienting to a guideline. When elements align, their differences become manageable. The chaos reduces. You can start to see the structure. Alignment works by reducing contrast—bringing things closer to a shared reference so the design feels cohesive.

Hierarchy does the opposite. It introduces difference on purpose. It separates what matters first from what can wait. A bold heading next to body text isn’t just styling—it’s a decision about priority. Hierarchy works by increasing contrast so the eye knows where to go.

Affordance makes purpose visible. A button that looks pressable, a handle that looks pullable—these work because they stand out from their surroundings just enough to signal what they’re for. Affordance works by emphasizing contrast so action becomes obvious.

And balance—or rather, harmony—composes all of it. It doesn’t flatten differences. It manages them. It asks whether each element is contributing to the whole, not whether everything has settled down. Harmony works by orchestrating contrast so differences collaborate instead of compete.

Every principle in this series has been a different way of using contrast. Reducing it. Increasing it. Emphasizing it. Orchestrating it.

Contrast is the key to good design.

Beyond Design

The more I design businesses, the more I see it: Good design is about managing change. The delta. The difference.

Every improvement is a contrast. Where you are versus where you want to be. The current state versus the intended one.

That’s what designers do. We don’t just make things look good. We make decisions about difference. We move sliders. We create the contrast that communicates purpose.

The people who stand out aren’t louder than everyone else. They’ve learned to leverage contrast. When to emphasize. Or when to step back. Conscious contrast.

That’s design.

The Wisdom in Contrast

Design is the art of managing differences on purpose.

That’s the sentence I keep coming back to. Because it doesn’t just describe what designers do. It describes what thoughtful people do.

So the next time you look at a design—a layout, a team, your life—don’t just look at the elements.

Look at the differences between them. That’s where you play with it.

On purpose. By design.

Balance is one of those principles everyone talks about, but few question. To be honest, it might be the most subjective principle designers use. It’s definitely the one where I’ve said in the past: “balance feels off.”

And balance matters. It reduces chaos and creates stability. Without balance, design becomes overwhelming and distracting.

So balance isn’t wrong. But I think it’s incomplete.

Because balance focuses on stability. Reducing tension between elements until everything feels still.

And that focus on stillness is costly. It ignores the reason why you’re designing. It can dismiss the goal in favor of calmness.

The Value of Balance

So, balance does a lot of things well.

Balance is the principle that keeps design from falling apart. It gives structure. It prevents visual distraction. It makes layouts feel polished.

When a design feels chaotic, balance is usually what’s missing.

In life, it’s the same. Balance is what keeps a team from burning out. What keeps a conversation from becoming a monologue.

Balance is necessary. But it’s not enough.

The Limit of Equilibrium

I worked on simulation software for production optimization in the oil and gas industry. Specifically, a feature to model how fluids move through earth formations. I remember the day a wise petrophysicist gave me a masterclass in fluid dynamics. One term stuck with me: hydrostatic equilibrium.

It’s the theoretical state where all fluids have settled into still, horizontal layers. Nothing moving. Everything at rest.

We used it as a mathematical baseline—a zero-state from which we could calculate actual movements. But the truth is, we needed that zero-state because there’s no way to calculate without one.

And that’s the limit. The zero-state is useful as a reference point. But chasing it as a goal dismisses reality. There is always movement. It never settles.

The same is true in design. When we focus only on balance, we treat every element as if it should settle into place. We calm things down. We reduce tension. And that works—until it flattens too much.

A heading doesn’t serve the same purpose as a caption. A warning isn’t the same as a confirmation.

Balance can reduce the differences between elements. But that can reduce the effectiveness as well. That’s a problem.

From Balance to Harmony

So if balance alone isn’t enough, what’s the next step? Harmony.

Balance focuses on stability. Harmony focuses on purpose.

Where balance settles the elements, harmony connects them. Not by making them the same, but by making them resonate.

A harmonious layout isn’t one where everything is calm. It’s one where every element contributes to a shared whole. Where differences aren’t flattened, but intentionally leveraged.

In a balanced layout, the logic is: reduce the tension. In a harmonious layout, the logic is: make it work together.

One calms things down. The other connects them.

What I Learned About Sound Waves

Years ago, I spent a few weeks at the Royal Conservatory in The Hague. I was studying sonology, chasing my dreams. That didn’t last long—I dropped out. But I learned something about sound that changed how I think about design.

Sound is made of waves. Every note is a frequency. A vibration with its own character, its own behavior. They are moving elements.

Low frequencies are deep and wide. High frequencies are sharp and precise. They’re fundamentally different.

And that’s exactly why they work together.

The beauty of composition—in music—is the art and science of making different waves serve a shared goal. You don’t flatten a bass line to match the treble. You don’t mute the high notes to let the low ones dominate. You compose them. You give each frequency its own space, its own role and its own moment.

When you compose, something happens. The sound becomes beautiful. Purposeful.

Each wave keeps its own characteristics. But together, they form something none of them could produce alone.

This principle extends far beyond interfaces and sound.

Harmony also means giving each person room to contribute what only they can contribute. Not by flattening their differences, but by connecting them toward a shared purpose.

When that happens in a team, the same thing happens as in music.

When Balance Feels Off

So when balance feels off, there is dissonance. Two elements are in each other’s way.

The instinct is to calm things down. To settle it. And sometimes that’s the right call.

But sometimes the answer isn’t less tension. It’s better connection. Finding how two things that look too different can compose into a relationship that serves a larger objective.

Each in their unique role. Some loud, some soft. Some long, some short. All playing their part.

Takeaways

Balance is valuable and stable. But balance alone can lead us to settle. Settle for stillness when we should be composing for purpose.

Harmony does that. It doesn’t just ask: Are we stable? It asks: Does it serve the goal?

Harmony is about working together by leveraging uniqueness. Not settling for order alone, but differentiating with intent.

So the next time you’re designing a layout, building a team or even navigating a relationship, don’t stop at balance. Ask whether everything resonates.

Because when elements are composed—not just balanced—the result is harmony. On purpose. By design.

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