If you watch Clarkson’s Farm, you’ve heard the catchphrase “I did a thing!” when Jeremy has performed a miracle by successfully executing a relatively basic farmer’s task. That’s how I feel right now.

I’m building my own app using AI and I feel pretty lost and under-equipped to do this properly. Like in Clarkson’s Farm, I know that if I handed the same work to someone like Kaleb, who actually knows what he’s doing, it would be in a better state.

I’m at a crossroads. On one hand, I want to go back to the way I’m familiar with. On the other, I know I need to continue transforming the way I work.

The Pull to Go Back

I want to go back to drawing. Back to sketching things out myself, by hand, where I have control over the outcome and the output with my own skill set.

It feels easier. Give it to me, I’ll do it.

But I want to be careful here, because this is the part where a lot of people stop and conclude that the agentic workflow doesn’t work. I don’t believe that. If I said, “I can’t make decisions, so I’m going back to the way it was,” I’d be dismissing the whole value proposition, and that would be wrong.

The problem isn’t that the agentic workflow is broken. The problem is that I lack the experience and the understanding to build products this way. I can choose to retreat or to redesign the way I work.

The value I bring needs a new way to be released.

I Have Been in This Transition Before

What makes this recognizable to me is that I’ve experienced this role shift before.

When I moved from being an individual contributor to being a design leader, it was a similar shift. Not the same shift, but a similar one. I had full control over outcomes with my own hands. Then I needed to let that go.

I remember the exact pull I feel now. Just give it to me and let me do it.

What I had to do instead was unlearn. And in place of that, I had to reinvent myself. I had to train and educate myself into being a better leader, a servant leader. I had to articulate and transfer my know-how to the people I was now handing my work over to. And I had to put systems in place to set them up for success, so that the whole way of working improved.

That’s exactly what I’m facing right now, except the people are agents.

The Part I’m Actually Losing

The biggest lesson I took from moving into agile development was three words: transparency, inspection and adaptation. The empirical pillars. You make the work visible, you look at it thoroughly and you change course based on what you saw. It’s how you lead something you’re not personally executing.

All three are breaking for me.

How the agents got to the decisions they made is pretty hard to see. You throw an assignment into a black box and something comes back. You lose control of the overview. You lose the continuity. You lose the clarity about how we’re building this and why we’re building this.

Because I don’t understand a lot of the code, I hand off work to something I can’t properly judge. It does take away the risk of micromanagement, which is a positive side-effect, but it also means I have very little to inspect.

What surprised me is that it happens in my design too. Design is my own domain. I know this work. And still I find myself over-explaining, and still I can’t rely on the same level of output. I haven’t properly instructed the agents with the skills, prompts and libraries to really work and think like me.

This results in constant adaptation and reattempts, but without transparency and inspection. And without those two, adaptation isn’t really adaptation. I’m not changing course based on what came back. I’m just asking for it again.

I’m losing agility.

Left or Right

Being agile isn’t about being fast. With agentic workflows your time is compressed, your own thinking gets rushed. You’re constantly facing decisions and outputs from agents that come back so fast. The time to think in between is just gone.

And it feels like I’m moving fast. But when I look at my actual progress, I find myself looping and losing control. Agility is about delivering value sustainably. Definitely not about burning tokens rapidly.

The hardest part is that I know I’d actually be faster if I stepped away from the generation for a moment. Sketch things out. Give a proper drawing as input. Create a better frame for the agents to operate in.

But that’s in direct conflict with the time I have available.

There’s this constant intersection. I can go right and generate more, or I can go left, stop doing and think a little. My brain says go left. And then right there is the dopamine shot, the next generation, something new, something potentially better, maybe this one is the fix.

Going right feels like it takes me exactly where I want to be. It usually doesn’t.

It’s almost like a casino. I’m constantly choosing red or black. I’m gambling my time and my tokens with a lot of hoping.

What This Is Really About

I’ve generated a lot of iterations. I keep looping. And underneath all of it is something simpler than a tooling problem.

You can’t lead, challenge or guide people and agents in the right direction if the direction itself is ambiguous.

That’s what I’m struggling with. I know that I’m responsible and need to guide something I don’t comprehend enough myself. So the question becomes: do you double-down on the workforce you’ve paid for, in this case agents, and just trust them and give them more? Or do you stop and build your own clarity first?

I’m not going to hand you a technical answer here, because I’m too early in this process to advise on that. Many of you reading this are further along than I am. Some are not.

But I do know the leadership version of this answer, because I’ve had to learn it before.

As a leader you have to develop the skill and the character to accept that you don’t know. And then to tell the people you need some time to formulate your thoughts, your vision, your direction, so you can properly guide them and send them the right way. If you don’t develop that part, and if you’re not creating room for it, you end up directing people in directions without the honest answer about what it should be.

That applies to agents too. Maybe even more.

Closure

Maybe the thing to do isn’t to take advice from me. Maybe it’s just to reassess your own point of view.

Are you gambling, or are you creating clarity?

Take a break. Create the room to think, to not know, to doubt, to figure things out. And then treat developing your leadership skills as part of your agentic experience, not as something separate from it.

Create that clarity, build the systems and make room for the thinking that lets you guide both people and agents. Guide development in a direction you can actually see, inspect and adapt.

I’m still going to be the guy on the tractor shouting that “I did a thing.” But there’s more work to be done to make this field yield.

Say the word “polish” and people hear “aesthetics.” The final coating. Something you add once the real work is done.

I don’t see it that way. Polish serves a purpose.

Why We Polish Metal

Think about why we polish metal in the first place.

A rough surface needs treatment, otherwise it traps moisture and dirt. That’s to prevent the metal from corroding. A polished surface is smooth, safer to handle, easier to clean and therefore it will last longer.

We don’t polish metal to make it shine. The shine is just what happens along the way.

The real reason is protection.

Fidelity Is Not Quality

In software development, it is common to create designs with sketches. These are called prototypes or low-fidelity wireframes.

Low-fidelity means the design has minimal visual detail and is usually quick and easy to make.

But somewhere along the way we started treating fidelity and quality as the same thing. Fidelity should be how much you show. Quality is how well you show it.

Low fidelity became an excuse for low quality. Quick and dirty sketches with misaligned boxes and typos. “Don’t look at the details, it’s just a wireframe.”

But people always look at the details.

My wireframes were always pixel-perfect. Sounds like a contradiction, since wireframes are supposed to be quick and rough. But an unpolished wireframe corrodes your results.

Show someone rough work, and they react to the roughness. I noticed the reaction to these imperfections became the feedback. Entire meetings derailed because of a misspelled label or inconsistent spacing.

Feedback that has nothing to do with the concept you actually wanted to test.

Polish protects that concept. Low fidelity, high quality. To me that’s not a contradiction, but a way to get results you can trust.

What Rough Software Corrodes

When low fidelity leads to lowering quality standards, you get rough software.

Rough software has serious corrosion risk worth polishing for:

Test

Put rough work in front of someone and they respond to the roughness, not the idea.

Like I mentioned, I’ve sat in reviews where a broken button or an inconsistent label hijacked the whole conversation. Everyone had opinions about the mistake. Nobody talked about the concept underneath it.

The test doesn’t find the answers you were looking for.

Tech

Unpolished increments don’t stay small.

An inconsistency here, a shortcut there. Each one looks minor by itself. But rough edges compound as the system grows. A death by a thousand cuts.

What started as a small patch becomes the pattern everyone else builds on top of. Debt paid later, with interest, instead of avoided with a bit of attention.

Trust

Trustworthiness is the big reason we should care about quality. It isn’t only about what people can see.

One misaligned label, one inconsistent flow, and people start doubting. From the part they noticed to the parts they can’t. What about the logic then? If they don’t care about this, do they care about data security? It can bring into question everything under the hood they’re trusting you got right.

Polish is about product and perception protection, about being trusted.

Beyond Software

I see the same polish pattern outside of software.

When I build a business blueprint, low fidelity by design, or a simple core story on a slide, and when the quality is there—when it’s polished—the content and intent lands.

People receive and perceive it better. It’s easier to maintain. Easier to expand later.

I recently presented a core story and brand manifesto to a client. It was a well-written paragraph, shown on a polished slide. The client actually commented that the slide showed quality and it delivered the message more strongly. It resonated.

When people trust it more, they value it more.

Purposeful polish.

The Mirror Trap

There’s one catch: you could polish forever.

Keep polishing, and metal becomes a mirror. A mirror only reflects you.

At some point polish stops protecting your software and starts serving you, the maker. You’re admiring your own craft, instead of removing noise for the user.

Polish has a purpose. And that purpose defines the boundary.

Good enough for now isn’t an excuse to ship rough work. Good enough for now still means good. You just need to know when to stop.

Closure

Forget the gloss at the end. Polish is the protection on purpose.

So don’t confuse fidelity with quality.

Do what you do well, in increments. Make it good enough for now. But make it shine.

We’re all running one big experiment right now.

Organizations are placing bets they can’t fully calculate. And somewhere in between, developers and designers are shipping agents, redesigning workflows and implementing systems at a speed that would have been unthinkable five years ago.

We’re all wearing lab coats.

The problem is most of us aren’t actually running experiments. We’re changing things. Replacing processes. Spinning up agents. We’re just playing around. Which feels like we did a thing.

Feels like progress.

But change is not the same as experimentation. And in the AI era, that distinction has never mattered more.

The New Formula Trap

You may have seen this on supermarket shelves. A product you’ve bought for years as a loyal customer suddenly has a badge on the packaging: New Formula. Sounds like a good thing. So you hope for better ingredients and improved results.

But when you try it, it tastes the same. Maybe even worse.

What actually changed was the profit margin. The company found a way to alter the formula so it benefits the bottom line. Cheaper sourcing, different ingredients—same packaging, just with a new badge. They optimized internally and called it innovation. But they didn’t test whether the outcome improved for you. Most of the time, they tested whether you’d notice.

The gesture of value replaced the value itself.

This happens in software constantly. A team adopts AI tooling, automates a handful of tasks, watches output increase and declares the experiment a success. But often without a definition of success before starting. No baseline set. No asking whether the delta—the measurable difference between before and after—justified the investment.

The feeling of improvement replaced the proof of it.

The Ingredient Most Teams Skip When Running Experiments

The formula for running a real experiment isn’t new. It’s not waiting to be invented. Every serious framework that exists already contains it.

PDCA: Plan, Do, Check, Act. The scientific method: hypothesize, test, measure, conclude. Lean Startup: Build, Measure, Learn. Strategyzer’s experiment approach from Testing Business Ideas.

Every single one has the same ingredient baked in with different names—the same thing: a solid test.

Strategyzer builds it into what they call the Test Card. A simple tool that forces four things explicit before any experiment runs: what you believe, how you’ll test it, what you’ll measure and, most importantly: “We are right if ...”

That last field is the one that gets skipped.

“We are right if ...” is written before the experiment starts. It defines the delta upfront—the specific, measurable difference that would tell you whether the change actually worked. Not whether something changed. Whether it improved. For whom. By how much.

A simple but powerful example: before you deploy a new AI agent into your support workflow, the Test Card asks you to complete the sentence. We are right if response time drops by 20% without increasing error rate. We are right if customer satisfaction scores hold or improve. We are right if the cost per resolved ticket decreases.

That’s the ingredient. Without it, you’re not running an experiment. You’re making a change and hoping it becomes progress.

The Willingness to Be Wrong

Science can afford to be wrong. A negative result is still a result. It advances knowledge. The experiment that disproves the hypothesis is just as valuable as the one that confirms it. Being wrong is not the same as failure.

Business doesn’t work that way. Being wrong has a direct consequence. Your reputation or career affected. A budget or a project cut. There is a pressure to show results and when the cost of being wrong is high enough, people will always find a shortcut. Teams stop running experiments and start building the appearance of them. They find the metric that confirms it worked, declare success because usage went up or retrofit the proof.

It’s not dishonesty. It’s success obsession without enough depth.

In science, the evidence has to support the hypothesis. In business, success is often measured by the bottom line result. If the result looks good enough, the quality of the evidence doesn’t get questioned. That is where experiments become changes with a good story.

The “We are right if ...” field on the Test Card is designed to close that gap. It forces success criteria to be set before anyone knows the result. It makes retrofitting impossible. And it requires something business culture rarely demands: the genuine willingness to find out you were wrong.

In the AI era, that willingness is more expensive than ever. You’ve shipped the agent. The team is invested. Leadership is running around with slide decks about the initiative. The last thing anyone wants is an experiment that comes back negative.

But that’s exactly why you need one.

What Skipping the Experiment Actually Costs

Law firms are a useful case. In 2024, legal professionals predicted AI would significantly improve efficiency, raise quality and transform how they bill. Technology spending rose 9.7% in 2025—the fastest growth the industry had ever seen.

But nearly 60% of in-house counsel reported they had seen no noticeable savings from outside counsel using AI.

Usage went up. Client improvement did not.

Kinda like a new formula in the supermarket.

Here’s what actually happened. Firms optimized for efficiency inside a billing model that punishes efficiency. They built tools that compress work from hours to minutes—then stayed trapped in billable hour structures that reward time consumption, not outcomes. They measured what changed internally. They never asked we are right if from the client’s perspective.

Legal AI vendors moved from flat-seat pricing to consumption-based models, a shift that also requires attention to data privacy and compliance obligations alongside cost implications. The costs that had been subsidized to get firms hooked started landing on the balance sheet. And firms had no evidence base to fall back on—because they had never built one.

They had tested whether clients would notice. Not whether quality improved. Just like the supermarket. The moment costs rose, the margin argument collapsed. And without a quality story, there was nothing left to defend.

According to RAND Corporation research, more than 80% of AI projects fail to reach meaningful production—roughly twice the failure rate of traditional IT projects. The most common reasons: the wrong problem being solved, poor data foundations and a tech-first focus that chases tools instead of outcomes. In other words, experiments without a clear hypothesis and measurement.

By the time you realize you needed that baseline, you’ve been spending for months with nothing to compare against.

Closure

Before you deploy the next agent, redesign the next workflow or ship the next feature—stop and complete one sentence.

We are right if…

If you can’t finish it, you’re not ready to run the experiment. You’re ready to make a change. And that change might look like progress, feel like progress—but get you nothing.

In a world where building has never been faster, measuring has never mattered more.

The formula is not new. It’s just the ingredient most teams skip.

“We are right if ...”

And I’m ready to be wrong.

When people talk about software, they usually talk about the technology. In 2026, we talk about AI, cloud services, programming languages, frameworks and the latest tools that help us build faster than ever before.

But software doesn’t create itself.

Behind every application you use, every website you visit, every game you play and every service that helps you get through your day is a developer who cared enough to build it. Someone saw a problem, imagined a better experience and spent their time and energy bringing that idea to life.

That’s one of the things I’ve always loved about the developer community. Developers are naturally curious people. We’re constantly learning, experimenting and asking, “What if?” We enjoy solving puzzles, but we also care deeply about the people who use the things we create. Whether it’s helping a customer or coworker accomplish a task more easily or contributing to an open-source project, our work is ultimately about helping others.

For me, one of the most rewarding parts of being a developer has been the opportunity to connect with other developers. That’s a big part of why I enjoy live coding so much. The code is just the vehicle. What really matters is the conversation. Whether I’m building something new, experimenting with a feature or debugging a problem in real time, there are always developers sharing ideas, asking questions, offering suggestions and teaching me something along the way. After all these years, that’s what still excites me most about this profession. The technology changes constantly, but the opportunity to learn from and collaborate with smart, passionate people never gets old.

For World Developers Day, I wanted to take a moment to celebrate that human side of software development. The technologies we use will continue to evolve. The languages, frameworks and platforms will change. What won’t change is the passion that drives people to create, innovate and share their work with others.

My Progress colleagues and I asked a group of developers a simple question:

What do you love most about being a developer?

The answers were thoughtful, inspiring and as diverse as the community itself. Some talked about the joy of learning. Others shared how much they enjoy solving problems or collaborating with teammates. A few spoke about the satisfaction of building something that makes someone’s day just a little bit easier.

Take a few minutes to watch the videos below. I think you’ll find a common thread running through all of them: software development isn’t really about code. It’s about people. And behind every great application is a developer who cares.

Follow us on LinkedIn to continue to hear stories like this.

When a product or tool is a crucial part of your application, support is more than just a nice-to-have. For enterprise development teams, support issues could mean anything from a single blocked developer to an entire delayed release. The larger and more critical the application, the more important predictable access to technical expertise becomes.

So rather than simply saying Progress provides strong Telerik and Kendo UI support, here are the numbers behind it—customer satisfaction, response and resolution times, escalation rates and the technical resources available beyond a simple or individual support case.

Support at a Glance

• 98%+ customer satisfaction on case closure
• 95.5%+ customer satisfaction per interaction
• 24-hour response-time Service Level Agreement (SLA)
• 50%+ of cases resolved within 14 hours
• <14 hours median time to first response
• ~99.8% of tickets resolved without escalation
• New AI-powered chat embedded in ticket submission and documentation to provide instant answers

What Does Enterprise-Grade Support Mean?

Enterprise-grade technical support combines predictable response commitments, access to technical expertise, efficient issue resolution and self-service resources that help teams resolve problems without creating prolonged development blockers.

Technical Support from Technical Engineers

We believe that good support is part of the product experience. Our technical support engineers bring hands-on expertise, helping teams get from problem to solution without unnecessary delays or layers of escalation. Telerik Technical Support Engineers are technical specialists with software development expertise, equipped to investigate implementation-level issues rather than simply triage and route them. Approximately 99.8% of support tickets are resolved within Technical Support without requiring escalation to product engineering.

Fast Turnaround

We also understand that when a project is blocked, timing is of the essence. That’s why our support teams provide a 24-hour response-time SLA—but most of the time, you won’t even have to wait that long. Our median time to first response is under 14 hours.

In fact, over half of support cases are resolved within 14 hours, helping teams move from problem to solution quickly. Most issues also stay with the support organization rather than requiring engineering escalation. And by “most,” I mean “very nearly all”: approximately 99.8% of tickets are resolved without escalation.

Exceptional Customer Satisfaction

More than 98% of customers report satisfaction at case closure, and a 95.5%+ CSAT score (Customer Satisfaction) per interaction reflects high quality throughout the support experience.

What About Support Beyond Tickets?

Support is about more than just answering one-off tickets, though. That’s why we offer a massive collection of technical knowledge that helps developers across the community—whether they’re troubleshooting a problem, learning a feature, evaluating an API or looking for implementation examples. Those resources mean that developers may not even need to open a support ticket in the first place! The vast library of public technical knowledge empowers developers with the knowledge they need, saving direct technical support for unique and specific edge case instances.

Available Public Technical Knowledge

• 290K+ answered forum threads
• 6.5K+ knowledge base articles
• 10K+ demos
• 24K+ conceptual documentation articles
• 29K+ API reference articles.
• 100+ answered community questions each month

These resources are publicly searchable and indexable, which allows the impact of our excellent support to scale far beyond what could be offered via tickets alone. Developers can benefit from solutions documented through years of customer and community interactions, while organizations can build their own expertise on top of a large, accessible body of technical knowledge.

What Our Customers Say

The numbers are impressive, but what matters more to us is what our customers have to say about their support experiences. These are just a small sample of quotes from users who have worked with our support teams and had wonderfully positive experiences.

Clear Instructions

“I’m incredibly grateful for the technical assistance I received. The support was not only timely but also highly effective—resolving my issue quickly and professionally. The guidance was clear and spot-on, helping me identify the missing step and implement the correct solution without delay. Thanks to this help, everything is now working perfectly. I truly appreciate the responsiveness and expertise. This kind of support makes a huge difference!”

High-Quality Responses

“Your developer support is AWESOME! I can’t imagine moving to another control suite. You guys are the best!”

Fast and Detailed

“Prompt and on-point with all of our communications. I appreciate the detailed responses and explanations!”

Going the Extra Mile

“Spent extra time making sure I had the resources and information to fix my problem […] created an example project and code snippets. Thank you so much!

Better Support Means Better End Products

Faster access to expert assistance can reduce delivery risk by helping developers resolve blockers before they become prolonged delays. Strong technical support and a comprehensive knowledge base also reduces engineering time spent troubleshooting, searching for answers, going in circles with AI chatbots or developing brittle workarounds—lowering the total cost of ownership over time. Support is, therefore, not simply a service attached to the product; it's part of the risk assessment that teams should evaluate when choosing a partner they expect to rely on for years.

Enterprise teams working with Telerik and Kendo UI can have confidence that when a problem arises, there’s a reliable solution—and an experienced team behind the technology, just waiting to help.

FAQ

How Quickly Does Telerik Technical Support Respond?

Telerik Technical Support includes a 24-hour response-time Service Level Agreement (SLA), but our median time to first response is less than 14 hours.

How Quickly Are Telerik Support Cases Resolved?

Over half of cases are resolved within 14 hours, with less than 1% requiring escalation.

Are Telerik Support Cases Handled by Technical Experts?

Yes, Telerik Technical Support Engineers are technical specialists with software development expertise, equipped to investigate implementation-level issues rather than simply triage and route them.

What Self-Service Support Resources Does Telerik Provide?

Our library of self-support technical knowledge resources includes extensive community forums with over 290k answered threads, over 6.5k Knowledge Base articles, over 10k demos, over 24k conceptual documentation articles, over 29k API reference articles and more than 100 new community questions answered each month.

Want to See for Yourself?

Our 30-day free trials include access to support. The Telerik DevCraft suite lets you pick your favorite flavor, so check it out:

Try DevCraft

When you’re not feeling emotionally or mentally well, there are a plethora of ways in which you can self-soothe. The only problem is that when you’re at work, some of those practices aren’t always the most feasible.

But you don’t have to wait until you clock out to start feeling mentally well again.

Sound can be a very useful and practical tool in the workplace when you’re looking to improve your mood and mental health overall. Different kinds of sound can:

• Ease physical tension
• Slow the breath
• Quiet the mind
• Mask noise pollution and other distractions
• Decrease sensory overload
• Improve focus
• Increase energy

By leveraging audio to decrease stress and manage your mood, you can also help prevent burnout.

In this post, we’re going to take a look at what the research says about the following types of audio on mental health: binaural beats, ASMR, nature sounds and color noises.

Audio You Can Use to Improve Your Mental Health and Mood

One of the reasons why we get stressed is because of external pressure. Looming deadlines, overly demanding clients, unanticipated change orders and so on.

But because we often can’t control what’s happening outside of ourselves, we have to just roll with it. And while we may be able to put our heads down and get the job done, our bodies and minds often hold onto that stress so we can deal with it later (if at all).

To better process the various stressors you encounter while working, consider bringing audio into your workspace. Here are some ways in which these different types of audio can help:

Binaural Beats

Binaural beats are an auditory illusion that’s created when two different frequencies are played simultaneously. If you’re wearing headphones, you’ll hear a different frequency in each ear.

What makes these binaural beats special is that your brain doesn’t hear both sounds at once. Instead, it hears the difference between the two tones.

Binaural beats can target certain frequencies and thus be designed to align with our natural brain waves. As Psychology Today explains:

“Some evidence suggests that the tone being perceived can alter brain waves through a process called entrainment, in which brain waves align themselves to an outside beat or frequency. Since different brain wave patterns are associated with certain states of mind, from relaxed to anxious to productive, binaural beats have been theorized to impact mood, focus and sleep by altering brain waves.”

For example, a binaural beat between 8 and 12 Hz aligns with our natural Alpha waves. These are the ones our body produces when we’re in a calm, relaxed state.

Here is an example of a 40 Hz binaural beat:

This is the frequency that’s said to improve one’s ability to learn.

There is a lot of research being done on binaural beats and their effect on our bodies and minds. That said, the results seem to be a mixed bag.

For instance, Lake Forest College shared the results from two very different studies.

In one study, patients about to undergo surgery were given binaural beats to listen to, regular music, or they could watch TV or read a book. The binaural beats segment experienced a 26.3% decrease in anxiety compared to only 11.1% in the music group and 3.6% in the no-audio segment.

But this could just be a case of context. With nerves super high in anticipation of surgery, binaural beats can be incredibly helpful even if they don’t get the person back down to a grounded state.

Contrast that with the 2020 study where they measured the neural activity of everyday people. In that study, they found that binaural beats did sync with their participants’ brain waves. However, it didn’t have much of an impact on their mood.

While binaural beats might not be a cure-all for stress or anxiety, they may be able to help if you’re experiencing these feelings at a higher level and/or for an extended period of time.

According to Healthline, different binaural beats can help with anxiety, stress, focus and even creativity. If you’re interested, experiment with targeting different frequencies based on how you’re feeling.

ASMR

ASMR stands for autonomous sensory meridian response. This refers to experiencing a sensation in response to audiovisual stimuli or even the touch of another person. The physical response is often equated with a tingling at the back of the head and an ensuing sense of calm.

Here are some stimuli considered ASMR:

• Whispering
• Tapping
• Scratching
• Crinkling
• Rustling
• Repetitive movements

According to Healthline:

“Not everyone experiences ASMR—some find such stimuli have no influence on them or may even have a negative effect, such as annoyance.”

So if my descriptions here feel like that, please skip down to the next point!

Now, for those of you who are receptive to ASMR experiences, this is an interesting type of audio to bring into your workday.

You could go to a site like Instagram and get a quick dose of ASMR. There are millions of videos with slime, soap, eating, crunching, tapping, cooking, crushing, cutting and other relaxation-inducing sounds, which are often paired with bright-colored visuals.

For instance, this one from @alla_asmr_youtube combines crunching and slime.

You’ll also find lengthy soundtracks on places like YouTube. For example, this one goes through a mixture of tactile experiences:

These show hands performing tasks like:

• Running through/along sand
• Playing with small objects in water
• Sifting through gelly balls
• Playing with popcorn
• Touching soft fabrics

While ASMR has shown to have a relaxing effect on those who experience it, there are other kinds of conditions it may be helpful for as well.

For instance, the Healthline article suggests that ASMR can be a good tool for people who have ADHD. If you’re having a hard time maintaining your attention while you work, ASMR sounds may be able to induce a flow state.

That same article also said that ASMR has helped people with autism.

“They found that it may help with anxiety and stress as they relate to emotional self-regulation. ASMR may also help with calming and soothing after a ‘meltdown’ or period of overstimulation.”

Again, it depends on how receptive your mind and body are to ASMR sounds. If this style of audio doesn’t bring you a sense of calm, then there are a couple of other types of audio you can listen to.

Nature Sounds

If you listened to that YouTube of the ASMR sounds, you may have noticed that some of them mimicked the sounds of nature. And that was likely intentional.

Psychology Today rounded up various studies that looked at the healing power of nature sounds like ocean waves, bird songs and forest sounds. Here are some of the health perks these studies revealed:

• Improved health
• Decreased stress
• Enhanced mood
• Improved cognition
• Improved attention
• Increased positivity
• Reduced anxiety

As for why these sounds are so effective, researchers suggest that sounds of nature can lower our heart rate. This in turn helps to bring us into a parasympathetic state (rest-and-digest) versus sympathetic (fight-or-flight).

In addition, nature sounds take us out of our heads. Rumination is what allows stress and anxiety to build. The sounds of nature invite us to pay attention to something external.

While a walk out in nature is the most effective way to reap these benefits, it’s not always the most feasible option depending on where you live/work or what time of the year it is. The good news is that you’ll find ambient soundtracks and nature sounds all over the place online.

YouTube, for instance, has free videos like this one which combines the sound of the wind with bird songs:

And this one which has flowing water and other natural sounds from the forest:

If you subscribe to a music service or a relaxation app (like Calm), they also have plenty of nature soundtracks to choose from.

One thing to be aware of is that one study found that people who were already feeling calm experienced a slight spike in their sympathetic (stress) response when listening to nature sounds. This could be due to the type of sound they were exposed to. If it was something they were unfamiliar with or didn’t enjoy, it may have been more distracting than calming.

So, when looking for nature sounds to listen to, give different ones a try. For instance, I had a sound machine I used to use to help me sleep at night. It had about a dozen sounds on it. I absolutely loved the water sounds, but anything with animals (like frogs or birds) kept me wide awake.

Color Noises

Color noises are another type of audio that’s based on certain healing frequencies. But unlike binaural beats which combine two frequencies to form a new one, color noises combine various frequencies. And they’re called color noises because of where they land on the spectral density chart.

White noise is the one that people are most familiar with. In fact, Bloomberg discovered in 2023 that Spotify users consume about 3 million hours of white noise every day.

White noise combines all noise frequencies that we humans are capable of hearing. This one is good for:

• Blocking out ambient noise
• Lulling to sleep
• Enhancing concentration (especially if you have ADHD)
• Creating a soothing environment

This is what white noise sounds like:

Pink noise also combines various frequencies. However, the power and volume of higher-end frequencies are dulled. This leads to benefits like:

• Improved memory recall
• Feelings of tranquility
• Deeper sleep

This is what pink noise sounds like:

Brown noise is the other color noise we commonly hear about. This one takes the volume of higher frequencies down even lower than pink noise. This results in:

• Improved concentration
• Reduction of stress and anxiety
• Improved creativity

This is what brown noise sounds like:

Green noise isn’t as talked about since it’s still being researched. It is similar to white noise as it’s a bit harsher in terms of high-end frequencies (it’s reminiscent of ocean waves or rushing water). This one is good for:

• Masking ambient noise
• Improving productivity
• Creating a relaxing and meditative flow state

This is what green noise sounds like:

Because each color sound is associated with different benefits, I’d suggest having a line-up of different soundtracks based on how you’re feeling on any given day. For instance, green noise might be best for when you’re already feeling productive and want a soundtrack to enhance your focus. But then you could switch to brown noise if you start feeling stressed or like you’re in a fog.

Wrapping Up

Stress management is absolutely crucial. If you don’t find a way to manage and release the stress, anxiety or other negative feelings that accumulate throughout the workday, over time it will have a negative impact on your mental and physical health as well as your ability to work.

While you can always wait until after work to unwind, listening to audio is one of the simplest ways to bring calm and control over your nervous system, body and brain. And there’s no need to wait. You can listen to the kinds of audio mentioned above while you work, even if it’s within a bustling work setting.

By the way, if you’re interested in other ways to use audio to improve your workday, here are different kinds of music that can help improve productivity.

We’ve all done it. We look at our calendar and list of tasks and think, “There’s plenty of time to get everything done.” But next thing you know, you have a client breathing down your neck about a milestone or a coworker wondering where an asset is.

Where did the time go?

In many cases, it’s not as simple as someone lacking time management skills. Often, there’s something about the nature of the work in web design that prohibits focus and efficiency. Like being responsible for creative design work and administrative tasks. Or having to navigate all the competing wants and needs of everyone else involved.

In this post, we’ll take a look at some of the more common time wasters and how to deal with them so you can be more efficient and effective with the time you have.

Common Time Wasters in Web Design and Development

Let’s have a look at the kinds of things that have a tendency to pull you away from the work you should be doing:

Administrative and Operational Tasks

I used to run a design agency where we installed time tracking software on everyone’s computers. The goal was to find out why we were constantly running over budget and missing deadlines.

Aside from a few stragglers who used social media during work, what I found was that the biggest time wasters weren’t from external distractions. Instead, I saw employees getting caught up in non-design tasks, including things like:

• Prepping for meetings
• Attending meetings
• Drawing up proposals
• Replying to emails
• Managing and organizing files
• Troubleshooting technical issues within the company
• Trying out new software/apps

This 2025 survey from freelancermap asked freelance designers about how many working hours they spent each week on “non-billable” tasks like these.

On average, around 5 of their 40 hours went to non-billable work.

Here is the full breakdown from the report:

• 14% spent more than 20% of their time on non-billable work (more than 8 hours)
• 43% spent 10% to 20% (between 4 and 8 hours)
• 43% spent less than 10% (less than 4 hours)

A 2025 Atlassian report found that developers were losing even more time.

According to their research, 90% of developers lose 6 or more hours a week to administrative or operational tasks. A whopping 50% lose over 10 hours. This is attributed to organizational inefficiencies.

Five or six hours of a 40-hour workweek essentially means you’re going to lose more than half a day to non-design work. If that number is closer to 10 hours, you can kiss an entire workday (and maybe even more) goodbye.

What’s worse is that these operational time wasters don’t usually happen in big chunks.

Instead, you have to jump from design/dev work to administrative tasks, and back again. Recent research suggests that this doesn’t hugely impact the amount of time it takes to complete your work. However, it does greatly increase the stress, frustration, effort and time pressure. This can then impact your focus, motivation and energy levels—which can slow things down for you overall.

So, how do you fix this issue? It’s not like you can start saying “no” to meetings, proposal generation, responding to client emails and so on.

Here are some practical time and project management solutions you can try:

• Use a task management tool to oversee and control your workload.
• Add small time blocks to your schedule each day to handle things like checking emails as well as time-sensitive tasks.
• Add a big time block to one or two days that allow people to schedule meetings with you or to ask for help with bigger research/prep tasks.
• Avoid multi-tasking/task-switching as much as possible.
• Set a priority level for each task and tackle the most important stuff first.
• Automate where you can—like creating canned responses to send to clients.

Although administrative tasks may be part of the job, you can’t allow them to get in the way of the work clients are actually paying you to do. You also have to be careful about how you manage them as they can increase stress and anxiety, which can lead to burnout.

Collaboration Challenges

Unless you’re a solopreneur building websites and apps on your own, collaboration is an inherent part of the work you do as a web designer or developer.

On any given project, you might collaborate with management, coworkers, clients, vendors or third-party service providers. As you weave in between these different parties and interactions, the hope is that it will increase your momentum and not hinder it.

Unfortunately, collaboration can lead to some challenges when it comes to design and development. Here are some examples:

The under-deliverer: Your client agrees to a lower project cost in return for providing you with all of the images and copy for the website. Without that content, you cannot begin working on the project. It’s now been three weeks and the client continues to promise you’ll have it soon.

If you continually run up against people who under-deliver, then change your process. With the example of the client who fails to deliver content, you could remove that as an option altogether. Instead of negotiating a lower project price (which is sometimes a red flag in and of itself), you offer a flat fee that covers the cost of creating content internally. And apply it to every client.

You could also work something into your contract about this kind of thing. For clients who fail to deliver what you need (e.g., content, feedback, milestone payments), you’re entitled to put the project on hold and resume it at a later date.

The micromanager: Your manager insists that every iteration of the app be reviewed by the design and development team before it’s sent to the client. However, you’re now three rounds into revisions internally and likely to have a few more once it reaches the client.

A 2022 Forbes article reveals why management are so often the bottleneck when it comes to collaboration:

“Unfortunately, some business leaders assume that ‘collaboration’ simply means spending time communicating back and forth with other team members. While email, video calls and meetings can certainly facilitate some collaborative efforts, too much of a focus on these can become a distraction from actually performing collaborative work.”

If you have managers or clients getting over-involved and spending more time talking about the work instead of doing it, then a conversation needs to be had. Suggest trying an approach that doesn’t involve a collective review or constant oversight to see if the end result remains positive.

You of course want your entire team to be on the same page about everything. However, if these additional check-ins, meetings or review rounds are doing nothing but increasing tension within the team and wasting time, then they’re not serving you well.

The inefficient tech stack: In some agencies, design and development teams don’t use the same platforms. Because of this, design handoff can take a while as specifications need to be drawn up for the developer. You might also end up with multiple rounds of questions to get clarity on what was mocked up and how it needs to be executed.

This may be the most difficult collaboration bottleneck to address as management will have to sign off on any changes. While you might not be able to change your design and development tech stack or handoff process, you could ease the situation and save time in other ways.

For example, digital collaboration tools can help increase team productivity by 30%. So, even just finding a way to simplify and speed up communication between team members or clients could help you take back some of that wasted time.

As you can see, there are so many different reasons why collaboration can become a big time suck for designers and developers. To address these issues, you’ll have to pinpoint which ones your agency suffers from the most and tailor-make a solution for it.

Rushing or Overcomplicating Projects

I think of this as a problem of extremes.

The problem with rushing projects: On the one hand, you have projects that get pushed too quickly through the pipeline (or with too many other projects competing for priority). For whatever reason, the deadline is set and the creative team is left having to make it work.

So, what likely happens? They cut corners.

Maybe they do a whole lot of vibe coding and don’t spend as much time reviewing, rewriting and repairing the code as they normally would.

Maybe they rush through design and development, not bothering to draw up a style guide or design system. And while the client is mostly satisfied with how the app works, they hate the color palette. So now every element needs to be reskinned and it’s difficult to keep things straight without a set style guide.

Or it could just be the problem of completing every step at two or three times the usual speed. The product was built in record time, but now you have to make up for it with tons of revisions.

This is something called technical debt.

Technical debt is the idea that the time and money saved upfront when cutting corners will eventually have to be repaid later. You’ve compromised the integrity of your process, which usually means making up for it by spending time debugging and revising.

Not only does technical debt tack on extra time after you’re “done,” it creates added stress and also hurts team morale.

The solution to this? Pushing back on unreasonable timelines.

The problem with overcomplicating projects: Now let’s look at this from the other end of the spectrum. Instead of rushing through the job, you go overboard with it. This could be due to a perfectionist mindset and not wanting to ship the product off until you’re 110% satisfied with it. It could also be due to someone dreaming way too big and being unable or unwilling to start small.

Now, perfectionism has its advantages. By paying close attention to details, you are less likely to get the dreaded email or call from the client to let you know they discovered a bunch of bugs, broken links and the like.

At the same time, perfectionism eventually stops being a benefit. There’s this 2024 post called Perfectionism - One of the Biggest Productivity Killers in the Engineering Industry that was co-written by Pinterest software engineer Jordan Cutler.

At the very top is this graph:

It’s a spot-on depiction of how perfectionism so often gets in the way.

As you spend more time working on the design and development of a product, it naturally follows that what you build will turn out good. However, you’re eventually going to reach a point where the product and experience is good enough. When ego and perfectionism push you past that point, the value you get in return will be negligible.

Similar time wastage happens when trying to fulfill someone’s lofty dreams. But not for the same reasons.

Let’s say you’re building a new social media app. Your agency pitched the concept to the client as the old school Facebook experience. However, now that the project is underway, the client wants to know why there aren’t Reels, Stories and Lives. And why there isn’t a Marketplace area or a place for Dating. They insist that you build all these features in.

Instead of running with a minimum viable concept (MVP) to see if your target users want a scaled-back, old-school social media experience, you spend tons of time building out a Facebook lookalike. And guess what? Your users don’t want all of that … because they already have it. So, now you have to cut out the features you hadn’t initially included in order to see if your original concept works.

MVPs allow you to be smarter with your time. By starting with something basic, it gives you the time and space to incrementally enhance the experience over time. And it allows you to slowly trickle out new concepts and features to users, using their valuable input to carefully shape the experience to their actual needs.

Wrapping Up

In many cases in web design and development, you’re working on a strict time table. It’s very rare that a project will fall in your lap and the assignee or client says, “Take your time.”

The problem is, there are some aspects of your job that inherently “waste” time. By that I mean tasks that contribute to the success of your projects as well as the organization, but that somehow slow down your web design or development work.

And with wasted time comes unfortunate consequences like:

• Missed deadlines
• Loss of client trust
• Lower profit margins
• Increased stress and burnout
• Lower team morale

If you find that any of the things I mentioned above have become an impediment to getting things done on time, there are ways to lessen the side effects. Setting aside time for administrative chores is one way. Streamlining communications is another. And taking a more realistic approach to project completion is yet another.

Job titles and design. It’s an interesting, never-ending quest for clarity.

I started my design career as a graphic designer. My boss didn’t even know what to call it, honestly. For him, it was: I need someone who makes graphic work. And I started without a degree, so I didn’t know either. Graphic designer. Whatever. I relabeled it later when cleaning up my resume to visual designer—because in essence I was focused on the visual side of things. Wrong icons, PowerPoints, booth designs, brochure work, DTP, stuff like that.

But I was getting more and more involved in interface design. So I started studying communication and multimedia design. At that point, it wasn’t necessarily about chasing a job title. I did have a subject called interaction design—one of the best subjects I had, taught by one of my greatest teachers, Ferry den Dopper. He really showed the deeper layers of designing software. And that’s pretty much where it started. From visual designer, I became an interaction designer.

At the time, that was the common way to look at UX design. UX design wasn’t even the label yet. Interaction design was common, and so was user researcher. Then UX design became a thing. So I relabeled again. I became a UX designer, and later a UX/UI designer—because most hiring managers had no clue. Companies had no clue. Our whole design community was just trying to figure it out. UI designers were moving into UX work. User researchers were suddenly responsible for visual design too. Interaction design became old school, and information architect became an even more dying trade. Eventually we became experience designers, design systems engineers or product designers.

The titles kept shifting.

And more and more, the focus moved to output: great-looking user experiences. I noticed—working in very complex environments—that UX researchers were still fighting in boardrooms for budget just to talk to users. But in the end, the systems took over.

What has happened now is that those systems are powered by AI to generate the screens as well. Once the tokens are in place, once the rules and guidelines are set, generation becomes easier. The output we drifted toward is no longer what we need humans for.

The designers doing well in this shift are the ones going back to the roots. Back to the essence of design.

Information architecture.

AI Needs Good IA

Everyone is prompting now. Developers, designers, business owners and product managers. You describe what you want and the system generates it. Fast and impressive.

But most people just throw raw information at AI and hope for the best. No structure, no curation, no defined relationships. Just input and whatever comes out.

Think about how your brain filters sound. Walking down the street, your ears pick up everything—traffic, a dog barking, voices around you. But your brain decides what to hear. Not because it has better microphones. Because it has context. It knows the car passing is a risk for the kid holding your hand. It knows the dog might be your neighbor’s and you want to say hi. Your brain knows what matters because it understands relationships.

That’s information architecture. Built into human intelligence by default.

AI doesn’t have that by default. It has to be given it. When you dump raw, unstructured information into a chat window, the model does its best—but its best is a statistical average. A plausible answer built on assumptions. Without structure, without relationships, without context, there’s no way to know what actually matters.

Great intelligence—artificial or human—runs on well-structured information.

How to Architect Information

Information architecture is a serious discipline. There are entire books, frameworks and careers built fully around it. I won’t be covering all of that here.

What I want to cover is where to start. Two things you can do today that will immediately improve the quality of your AI output, your designs and your systems.

The essence of design. Drawing boxes and drawing lines.

I call them reframe and relate.

Reframe

Every piece of information has a name. Most of the time, you don’t even realize it. You chose a label that felt logical or felt obvious, and it stuck. Now the whole team uses it, it’s in the system, it’s in the class naming, it’s everywhere. And now the AI is getting trained on it too.

Bad names become a bad foundation.

Reframing means stopping and asking: what is this, actually? What do we call it, and does that name carry the right meaning for everyone using it? This is what reframing is about—consistent vocabulary, shared definitions and metadata that makes information findable, searchable and more important than ever: machine-readable.

Take a simple example from an engineering dashboard. A field shows a value from a sensor on a piece of equipment. Someone called it “reading” when they built it. It made sense at the time. But across the system, the same concept gets called “value” in one place, “measurement” in another and “output” in a third. The AI getting trained on this data has no way of knowing these are the same thing. Neither does the new engineer onboarding. Neither does the search index.

Reframing means stopping and agreeing: this is a measurement. That’s what we call it, everywhere, always. You update the label, the metadata, the tags. Now the system can find it. Now the AI can reason about it correctly.

But a measurement on its own still means nothing.

Relate

Once the boxes are named and defined correctly, it’s time to draw the lines.

That measurement only makes sense in relation to the equipment it came from, the threshold it’s being compared against and the operational phase it belongs to. A vibration reading of 4.2 during drilling startup means something completely different than the same reading during steady-state operation. The number is the same. The meaning is not.

When you relate that measurement to its context, you give the AI what it needs to interpret correctly. Not guess. Interpret.

That’s the difference between structured information and raw data.

How does this connect to that? Why? In what order and with what priority? Those relationships turn a collection of content into a system that actually makes sense. This is where most people stop. The taxonomy is solid, the data is curated and they call it done. But without the logic that connects one thing to another, the structure is static. It doesn’t move when applied.

Information that relates is information that works—for users navigating a product, for a team maintaining a system and for an AI that needs to understand not just what things are but how they belong together.

Draw the boxes. Connect them. That’s your architecture.

Closure

Information architecture never went away. It got buried under the pressure of shipping more screens. We knew this once. Then we let it go. Now it matters again.

Now the screens are being generated. We finally have the time back to think, to provide structure and to build real foundations.

This is old school. Designers and developers were doing this long before AI made it a necessity. If you have that background, dust it off. This is your differentiator.

And if you’re new to it, start simple. Two questions before you prompt, before you build anything:

• What are the boxes? Reframe them.
• What are the lines? Relate them.

That’s your foundation. That’s how you make AI work better. And that’s how your work gets better too.

Blazor has become a serious platform for building modern web applications with .NET. As the framework has matured, commercial UI component libraries have become an important part of the Blazor development experience.

Instead of building every Grid, Chart, Scheduler, Form, Editor, and navigation component from scratch, teams can rely on mature component suites to accelerate development, improve UI quality and reduce long-term maintenance effort. Two of the most common options for Blazor development are Progress Telerik UI for Blazor and Syncfusion Blazor.

Both are mature. Both provide large component collections, commercial support, documentation, examples and tooling for .NET developers. Both can be used to build complex business applications.

The decision is rarely about whether one product is objectively “better.” A more useful question is: “Which library better matches the way your team builds, maintains, upgrades and scales Blazor applications over time?”

At a high level, Syncfusion Blazor is attractive for teams that want a very broad component catalog, access to many specialized controls and a Community License for qualifying users. Telerik UI for Blazor is a strong fit for teams that value a cohesive developer experience, predictable APIs, strong theming workflows, product polish, support reputation and long-term maintainability.

This comparison looks at both products through practical evaluation criteria: onboarding, component coverage, grid capabilities, theming, accessibility, performance, support, AI readiness and long-term project fit.

Quick Decision Summary

Choose Telerik UI for Blazor if…

• You are building a long-lived application that will be maintained for several years.
• Multiple developers or product teams will contribute to the same UI codebase.
• You value predictable APIs and standardized implementation patterns.
• You need strong theming, design-token management or designer-developer collaboration.
• You care about upgrade experience, support quality and long-term maintainability.
• You want a component suite that is easy for both developers and AI coding assistants to reason about.

Key Differences at a Glance

What Most Teams Eventually Optimize For

When teams first compare component libraries, they usually start with feature lists.

That makes sense. Component count, available controls, Grid features, Scheduler options, chart types, templates, exporting and documentation examples are easy to compare.

But once a Blazor application moves into production, different questions become more important:

• How easy is the application to maintain?
• Can new developers understand the UI code quickly?
• Are component APIs predictable?
• How painful are upgrades?
• Can we apply the same branding across multiple applications?
• Can designers and developers work from the same design system?
• How reliable is support when something breaks?
• Can AI coding assistants generate correct and maintainable UI code?

This is where the distinction between breadth and cohesion matters.

Syncfusion has a strong case when a team wants access to a broad collection of components, related document libraries and specialized controls. Telerik has a very strong case when a team wants a more unified development model, mature theming workflows and a polished component experience across the core UI scenarios that most business applications depend on.

Neither priority is wrong. The better choice depends on what your team values most.

Time to First Value

Feature comparisons are useful, but the first developer experience is usually more practical:

• How do I install the package?
• How do I configure licensing?
• How do I set up NuGet access?
• How do I create the first Blazor project?
• How quickly can I render a real component?
• How many manual steps are required before I can start evaluating the library?

This is where time to first value becomes important.

Time to First Value: Telerik UI for Blazor

Telerik puts a strong emphasis on guided onboarding. The product experience includes getting-started documentation, templates, licensing guidance, CLI-based workflows and integration with Telerik tooling.

Telerik focuses heavily on onboarding and guided setup, and this includes:

• Structured getting-started documentation
• Starter project guidance
• Project templates and configuration assistance
• Consistent setup patterns across components

The Telerik CLI can help reduce setup friction by assisting with project creation, package configuration, licensing-related setup, templates and related tooling.

This matters because early evaluation is not only about installing a NuGet package. It is about reducing the number of small setup decisions that slow teams down before they can assess the actual components.

The setup becomes as simple as:

For larger teams, this kind of guided setup can be useful because new developers do not need to rediscover the same configuration steps independently.

Time to First Value: Syncfusion Blazor

Syncfusion also has a strong onboarding story. Its ecosystem includes product documentation, sample applications and a large collection of examples. The Syncfusion Blazor samples repository describes demos for Blazor Server and Blazor WebAssembly apps, including project files targeting modern .NET versions.

That breadth of examples can be valuable when a developer is looking for a specific scenario or specialized component behavior.

Time-to-First-Value Takeaway

For a small proof of concept, both products can get developers started quickly.

The advantage of Telerik UI is more about guided setup and a cohesive path from installation to production-style usage. Syncfusion’s advantage is the large ecosystem of samples.

Component Coverage

Component count is one of the most visible comparison points.

Syncfusion Blazor is known for broad component coverage. Its Community License page describes access to 145+ Blazor components for eligible users and organizations. Syncfusion’s broader product line also includes UI components, document SDKs and standalone UI SDKs under the Community License description.

That breadth is a legitimate advantage. Teams that need niche controls, document processing capabilities, PDF-related libraries, Office document support or specialized UI scenarios may find Syncfusion difficult to overlook.

Telerik UI for Blazor takes a somewhat different approach. It provides a large suite of core Blazor components, but its strongest value proposition is not simply the number of controls. Telerik UI is strongest when the application depends heavily on polished core components such as Grid, Charts, Scheduler, Forms, Inputs, Editors, Layout, Navigation, Upload and theming.

For many business applications, both libraries cover the essential requirements. The practical difference is often not “Does a component exist?” but:

• How predictable is it to configure?
• Does it follow familiar patterns from other components in the same suite?
• Does documentation match real development scenarios?
• Is the component easy to theme and maintain?
• Does it fit into a shared UI platform?

Component Coverage Takeaway

Syncfusion has the advantage in overall breadth and specialized coverage.

Telerik has the advantage when teams want a cohesive suite focused on core business application scenarios, polished UI behavior and maintainable implementation patterns.

The Grid: The Component That Often Decides the Evaluation

If one component influences UI library decisions more than any other, it is usually the grid.

Business applications spend a large amount of time displaying, filtering, grouping, sorting, editing, exporting and analyzing data. For many teams, the grid is not just one component. It is the center of the application.

Both Telerik UI for Blazor and Syncfusion Blazor provide capable Grid components with support for common business scenarios such as:

• Sorting
• Filtering
• Grouping
• Paging
• Virtualization
• Inline editing
• Batch editing
• Templates
• Aggregates
• Exporting
• Hierarchical data
• Large dataset scenarios

Both vendors can support serious data-heavy applications. In practice, grid performance depends not only on the component itself but also on data access strategy, rendering mode, server communication, virtualization configuration and application architecture.

Telerik UI for Blazor Grid

The Telerik UI for Blazor Grid is strongest when teams care about a polished and predictable implementation model.

The main advantages are not only feature availability, but how the Grid fits into the broader development experience:

• Predictable configuration patterns
• Strong template support
• Familiar event and data-binding approaches
• Alignment with the rest of the Telerik component suite
• Accessibility-specific documentation
• A mature experience for common business data scenarios

Telerik Grid accessibility is WCAG 2.2 AA and Section 508 compliant, follows WAI-ARIA best practices for keyboard navigation and is tested with popular screen readers. That is a concrete point worth considering for teams building applications with formal accessibility requirements.

Syncfusion Blazor Grid

The Syncfusion Grid is also highly capable and has a broad feature surface. It is particularly attractive when teams need extensive configuration options or specialized behaviors.

Syncfusion’s Grid supports accessibility standards including ADA, Section 508, WCAG 2.2 and ARIA roles, with details on screen reader support, RTL support, color contrast, mobile device support, keyboard navigation and Axe-core validation.

Grid Takeaway

Both Grids are mature and capable.

Syncfusion’s Grid stands out for broad functionality and configurability. The Telerik Grid stands out for a polished developer experience, accessibility documentation and a usage model that tends to fit well into long-lived applications with multiple contributors.

If your evaluation is based on a specific Grid feature, test that feature in both products. If your evaluation is based on long-term maintainability, onboarding, accessibility and shared implementation patterns, Telerik deserves stronger consideration.

Scheduler, Charts and Dashboards

After the Grid, Scheduler and Charts are often among the most important components in business applications.

Scheduler

Both Telerik and Syncfusion support common scheduling scenarios such as:

• Day, week and month views
• Recurring events
• Resource grouping
• Drag-and-drop editing
• Custom templates
• Business calendar scenarios

Syncfusion is attractive when the team wants broad scenario coverage and many examples.

Telerik is attractive when the Blazor Scheduler needs to feel like part of the same UI platform as the Grid, Forms, Inputs, Dialogs, Charts and navigation components.

Charts and Dashboards

Both libraries provide charting capabilities suitable for dashboards, reporting UIs, KPI tracking, analytics screens and business intelligence-style interfaces.

The distinction is less about whether common chart types exist and more about the surrounding workflow:

• How easily can charts be themed?
• Can they follow the same visual system as the rest of the app?
• Can multiple teams reuse the same design language?
• Can dashboard screens stay visually aligned over time?

This is where the Telerik theming story becomes especially relevant.

Theming and Design-System Governance

Theming is often underestimated during evaluations.

At the start of a project, teams usually focus on functionality. Later, especially in long-lived applications, theming becomes a product and architecture concern.

Questions start to appear:

• Can we align components with our brand?
• Can designers and developers collaborate without translating everything manually?
• Can we reuse themes across multiple applications?
• Can we manage design tokens centrally?
• Can we support light and dark modes?
• Can we avoid one-off CSS overrides that become hard to maintain?
• Can we update the visual language without rewriting large parts of the UI?

This is one of Progress Telerik UI’s clearest differentiators.

Progress Telerik ThemeBuilder

Progress Telerik ThemeBuilder is a SaaS tool that enables teams to create custom themes and preview how they affect component appearance. It can generate a CSS file that can be used in a Blazor app instead of a built-in theme.

ThemeBuilder also supports capabilities that matter in design-system driven organizations, including:

• Atomic customization
• CSS/SASS variables
• Custom HTML support
• Figma integration
• Theme modes and built-in themes
• Custom fonts and iconography
• Project sharing
• Version control
• Collaboration and user access rights

This is more than visual customization. It helps teams create a shared styling workflow between design and engineering.

For organizations with multiple product teams, this can reduce duplicated CSS work, prevent visual drift between applications and make brand updates easier to manage.

Syncfusion Customization

Syncfusion also provides styling and customization options. For many teams, those capabilities will be enough.

However, if centralized design-system governance is a major requirement, Progress Telerik ThemeBuilder gives it a particularly strong position.

Theming Takeaway

Both libraries can be customized.

Telerik has a clearer advantage when teams need design tokens, Figma-related workflows, centralized branding, visual governance and reusable themes across multiple applications.

Blazor App Accessibility

Accessibility should be part of any serious UI library evaluation.

Teams building applications for public sector, healthcare, finance, education, government or large internal platforms often need to consider:

• WCAG
• Section 508
• Keyboard navigation
• Screen reader support
• WAI-ARIA roles and attributes
• Color contrast
• Accessible interaction alternatives
• Accessibility conformance documentation

Telerik Accessibility

Telerik UI for Blazor provides an accessibility compliance table that lists WCAG 2.2 compliance levels for individual components. Progress Telerik also provides an Accessibility Conformance Report through VPAT.

For the Grid specifically, Telerik documents WCAG 2.2 AA and Section 508 compliance, WAI-ARIA best practices, keyboard navigation, and screen reader testing.

Syncfusion Accessibility

Syncfusion documents accessibility support for Blazor components, including WAI-ARIA, WCAG 2.2, Section 508, keyboard navigation, screen reader support, RTL support and color contrast considerations.

Syncfusion’s DataGrid accessibility documentation also provides a detailed view of supported standards and limitations for complex interactions.

Accessibility Takeaway

Both vendors take accessibility seriously and provide documentation around standards and component behavior.

The Telerik component-level compliance table and documented Grid compliance are helpful for teams that need formal accessibility evidence. Syncfusion also provides broad accessibility documentation, including detailed DataGrid accessibility coverage.

For accessibility-sensitive applications, the best approach is to test the exact components and configurations your application will use.

Support, Documentation and Learning Resources

Support quality is hard to capture in a comparison table, but it often becomes critical after adoption.

During a trial, teams should evaluate:

• How quickly developers find answers in documentation
• Whether examples match real scenarios
• How clear upgrade notes are
• How support handles complex issues
• Whether feedback and bug reports are visible
• Whether the vendor provides practical guidance beyond simple demos

Telerik UI for Blazor Support

Progress Telerik has a long-standing reputation in the ecosystem for polished components, detailed documentation, active forums, feedback channels and strong support. That reputation is one of the reasons Telerik UI is often favored by teams building long-lived applications.

This should still be validated during evaluation. The best support test is not reading a marketing page. It is submitting realistic trial questions and measuring how useful the answers are.

Syncfusion Blazor Support

Syncfusion also provides commercial support, documentation, samples and a large knowledge base. Its broad ecosystem can be helpful when developers are searching for examples across many controls and scenarios.

Syncfusion’s large sample repository is especially useful when teams want to inspect working examples and compare usage across components.

Support Takeaway

Both vendors provide serious support and learning resources.

Telerik UI is often especially attractive for teams that prioritize product polish, support confidence and long-term UI quality. Syncfusion is strong for teams that value broad documentation coverage, many samples and a large ecosystem.

Product Quality, Stability and Upgrade Experience

Product quality is more than whether a component works in a demo.

For long-lived applications, quality usually means:

• Stable APIs
• Clear documentation
• Predictable behavior
• Accessibility guidance
• Reliable release notes
• Manageable upgrades
• Good support for modern .NET versions
• Transparent handling of bug fixes and breaking changes
• Similar concepts across related components

This is where the Telerik UI value proposition becomes stronger. Its advantage is not only that the components are polished, but that the suite tends to feel like a coherent product rather than a collection of unrelated controls.

That can reduce cognitive load for teams. Developers who learn common Telerik concepts in one component often find similar ideas elsewhere in the suite.

Syncfusion’s broader catalog is valuable, but naturally creates a larger surface area to learn, test and govern. That tradeoff may be completely acceptable if the team needs the additional breadth.

Upgrade Experience Takeaway

For short-lived apps, upgrade experience may not matter much.

For applications expected to live for several years, upgrade predictability and maintainable implementation patterns become important. Telerik UI is particularly compelling for teams that prioritize those concerns.

AI Readiness and Agentic Development

A few years ago, component library evaluations focused primarily on features, performance and support. Today, many teams are adding another criterion to their evaluation:

How well does the platform integrate with AI-assisted development workflows?

The discussion is no longer limited to AI-powered components. Developers increasingly expect AI tools that can help generate interfaces, configure components, validate code, enforce design-system rules and accelerate application development.

Progress Telerik AI Approach

Progress Telerik has invested in AI-assisted development across several areas of the product ecosystem, combining UI components, AI-powered tooling and agentic workflows into a more complete development experience.

The foundation of this effort is the Telerik AI Coding Assistant, which integrates directly into developer workflows through IDE-based experiences, GitHub Copilot extensions, and MCP-based tooling. The assistant can help generate Telerik UI for Blazor code, configure components, scaffold common scenarios, generate sample data and provide implementation guidance using Telerik-specific knowledge rather than generic web examples.

Beyond code generation, Progress Telerik has introduced an Agentic UI Generator that uses a collection of specialized assistants working together through an MCP-based architecture. Rather than generating isolated snippets, it can help create complete pages, dashboards, layouts and component configurations while following Telerik component patterns and design-system guidance.

The platform includes specialized assistants for:

• Page and UI generation
• Component selection and configuration
• Layout creation
• Styling and theming
• Icons and visual assets
• Accessibility guidance
• Validation and quality checks
• Project onboarding and setup workflows

These capabilities are orchestrated through the Agentic UI Generator, allowing developers to work at a higher level of abstraction when creating Blazor applications.

Telerik AI Plugins, MCP and Development Tools

One notable aspect of the Telerik AI strategy is the focus on developer tools rather than only AI-enabled components.

The Telerik MCP-based tooling includes plugin capabilities for:

This allows AI tools to work with Telerik-specific knowledge instead of relying solely on generic LLM training data, which can help reduce incorrect component usage and configuration errors.

In addition, Telerik provides AI-enhanced capabilities within its component ecosystem, including AI-powered chat experiences, semantic search scenarios, AI-assisted data operations, AI integrations within Grid and Editor components, WebMCP support, and integration scenarios involving technologies such as A2UI, AG-UI and Microsoft Agent Framework.

Syncfusion AI Position

Syncfusion is also actively investing in AI-based developer experiences and provides AI-related features, assistants and tooling across its ecosystem. Like Progress Telerik, Syncfusion is exploring AI-assisted development workflows and has published AI-related resources and component skills for developers working with its platform.

One of Syncfusion’s broader advantages remains the size of its overall ecosystem, which includes a large collection of UI components, document processing libraries and developer tools that can participate in AI-assisted workflows.

AI Readiness Takeaway

Which platform has the stronger AI story? Today, both Progress Telerik and Syncfusion are investing in AI.

The difference is less about whether AI capabilities exist and more about where the investment is focused.

Syncfusion’s strength comes from the breadth of its ecosystem and the large number of controls, libraries, and scenarios available to developers.

Telerik UI’s strength comes from providing an increasingly connected AI development experience that spans:

• AI Coding Assistant
• Agentic UI Generator
• MCP-based development tooling
• Specialized AI assistants
• Validation workflows
• Accessibility guidance
• Design-system alignment
• AI-enhanced components and features

For teams looking beyond AI-powered controls and toward AI-assisted UI development, Telerik currently offers one of the more comprehensive AI stories available in the Blazor ecosystem. The combination of UI generation, component-aware assistants, validation tooling, theming guidance and MCP integration makes the AI capabilities feel like part of the overall developer workflow rather than a collection of isolated features.

Where Telerik Has a Clear Advantage

Telerik is strongest when the team cares less about maximizing the catalog and more about building a maintainable UI platform.

Telerik is particularly compelling when:

• The application will live for several years.
• Multiple developers or product teams will work in the same codebase.
• The Grid, Forms, Charts, Scheduler and layout components need to feel cohesive.
• Design-system governance matters.
• The team wants strong theming workflows through ThemeBuilder.
• Accessibility evidence is important.
• Support confidence is a major factor.
• AI-assisted development is becoming part of the engineering workflow.

The clearest Telerik differentiator is ThemeBuilder. Its support for visual customization, variables, Figma integration, theme modes, custom fonts, project sharing, version control and collaboration makes it especially useful for teams that need a structured design-to-development workflow.

Pros and Cons

Telerik UI for Blazor

Syncfusion Blazor

Decision Framework

Telerik UI for Blazor is likely the better fit if…

1. The application will be maintained for several years.
2. Multiple developers or teams will contribute to the UI.
3. You need a shared design system.
4. The Grid is central to your application.
5. Accessibility documentation is important.
6. You want a polished and cohesive development experience.
7. Support confidence is part of the buying decision.
8. You expect AI-assisted development to become more important.
9. You value maintainability more than raw component count.

Syncfusion Blazor is likely the better fit if…

1. You need the large component catalog.
2. You need niche components.
3. The Community License applies to you.
4. Your team is comfortable managing a larger API surface.
5. Your evaluation is primarily driven by breadth and feature availability.

Final Verdict

If your primary goal is maximizing the number of available controls, accessing specialized components, benefiting from a Community License, Syncfusion Blazor is difficult to overlook.

If your priority is building a long-lived Blazor application with a cohesive developer experience, strong theming, accessibility documentation, support confidence, predictable implementation patterns and maintainable UI architecture, Telerik UI for Blazor offers a very compelling value proposition.

The choice comes down to what your team wants to optimize for. Feature breadth matters during evaluation. Maintainability matters in production.

For teams building applications that need to scale across developers, products, themes, accessibility requirements, and future AI-assisted workflows, Telerik UI for Blazor stands out as the stronger long-term choice—not because Syncfusion is weak, but because Telerik UI for Blazor’s strengths align especially well with the needs of structured, design-system driven, maintainable Blazor development.

Try Telerik UI for Blazor

In this post, I want to talk about a choice most teams are making without realizing it: delegating work to AI agents when they should be automating it deterministically, and the financial cliff that choice creates.

Image generated with AI

We are leaving the golden age of cheap tokens. The era where companies handed AI a blank check and called it innovation is ending. Reports across the industry tell the same story: budgets consumed in months instead of years, teams scrambling to explain runaway costs and executives quietly asking whether the return ever justified the spending. AI agents, the ones that loop, retry, reason and call themselves back, turned out to be remarkably efficient at one thing: burning through tokens.

We talk about the current AI cycle resembling a bubble. And although it has not fully burst yet, the air is leaving. What remains will be expensive. The professionals who built their entire workflow on token-hungry agents will be the first to feel the squeeze.

The Difference Nobody Talks About

There is a fundamental distinction between the two approaches that the industry keeps conflating into a single term.

An AI agent is a system that receives a goal, reasons about it, makes decisions at runtime and consumes tokens with every step. It is powerful. It is also unpredictable in cost because you are paying for the machine to think every time it runs.

Deterministic automation is a system that analyzes a known structure, applies fixed rules and produces a predictable output, without tokens or runtime reasoning. That will reduce the surprises on your invoice.

Both use intelligence. One front-loads it. The intelligence lives in the design, not in the execution. I call it deterministic AI: a system shaped by years of architectural thinking, where the machine does not need to reason because the reasoning already happened when you built it.

The most intelligent system is the one that does not need to think at runtime.

What I Built Instead

I spent years building a platform that generates entire SaaS applications from a data structure. Not a prototype, and not a scaffold. A complete, production-grade system: backend in .NET, frontend in React, data-first, mobile-first, unit test coverage on both sides, observability baked in with Prometheus, Loki and Tempo, and ready-made Grafana dashboard templates. Roughly 60 files per entity, generated deterministically from the shape of your data.

When a client asked me for a Micro CRM to be delivered overnight, I did not open an AI chat and start prompting. I ran my automation. In under eight hours, including three hours of database design, I made it myself. It was done. Backend, frontend, tests, monitoring. Everything in less than eight hours.

And with zero tokens consumed. (That also cuts unpredictable costs.) The result was identical to what I would have delivered if I had spent a week writing it by hand, because the automation encodes years of decisions I already made.

This is not anti-AI. This is anti-waste.

Where AI Still Earns Its Place

I am not arguing against AI. I use it. But I use it surgically, not as a crutch.

My automation already had a structure designed around C# interfaces, built specifically so that an AI model could understand and navigate the codebase. When I needed to expand unit test coverage, I pointed an AI coding assistant at the existing tests and had it generate new ones that followed the same patterns. I ran it for about six hours over two days. The cost was around $20 in tokens.

Twenty dollars. A manageable, traceable cost for a well-scoped task. But here is the part that matters: I had set a spending limit. Without it, that same task could have spiraled into hundreds, maybe thousands. And that, I believe, is exactly where companies bleeding money on AI are failing: not in choosing to use it, but in using it without boundaries.

I also explored running a custom LLM locally using Ollama and integrating it with my coding environment. It offers unlimited token usage at zero marginal cost, but it demands serious hardware: a GPU with at least 16 or 20 GB of VRAM. For teams that can invest in the infrastructure, it is a path worth exploring, one that decouples your productivity from someone else’s pricing model. Here is a tutorial about my journey implementing custom LLM on Cursor.

Use AI where it multiplies your intelligence. Automate where it would only repeat it.

Build the Machine That Does Not Need the Machine

There is a deeper lesson here, and it goes beyond cost optimization.

If your entire delivery pipeline depends on an external AI service to function, you have a single point of failure priced by someone else. Token prices go up. APIs go down. Models get deprecated. Rate limits tighten. And when any of that happens, your ability to deliver stops with it.

Deterministic automation is yours. You own it. It runs on your terms. It does not get more expensive overnight. And it does not hallucinate.

The architect who invests in automation today is building a shelter for when the token economy changes, and it will change. The one who delegates everything to agents is building on rented land.

Automate with AI. But never depend on AI to execute.

Conclusion

We are at an inflection point. The decisions architects and developers make right now, about what to automate deterministically and what to delegate to AI agents, will define the resilience and economics of their products for years to come.

The question is not whether AI is useful. It is. The question is whether you are building something that survives when the cost of thinking doubles.

So before you spin up another agent, ask yourself: could this be a machine that already knows the answer?

Have you ever heard of Pan de Jamón? I hadn’t—until I met Mike, one of the best developers I ever worked with.

This isn’t a “here’s what bread taught me about life” post. It’s an observation that might bring some light to an AI outlook that can feel pretty dark sometimes.

What made Mike stand out wasn’t only his personality or skillset. It was that he went home and baked Venezuelan Christmas bread.

Ode to the Hobbyist

And it wasn’t only Mike. Most developers I remember, I remember by their hobby.

Just off the top of my mind:

• The genius printing parts on a 3D printer he built himself
• The audiophile building a sound system for a perfect pitch
• The home-automation engineer who wired his house with PLCs
• The architect drilling a water well in his own backyard
• The rotary-engine-obsessed designer with a Mazda RX-7
• The 3D specialist restoring a surf van with his son

None of this is on their LinkedIn profile. None of it pays. And it’s the most interesting thing about them.

I’ve spent a long time in enterprise software, working with developers who write code that runs critical infrastructure.

The pattern is so consistent it stopped being a pattern and started looking like a characteristic: The best developers I’ve worked with don’t stop building when they close the laptop. They go home and make something else—bread, sound, water, vans. They just stop getting paid for it.

What Agents Don’t Have

We live in interesting times. Agents are now colleagues that cooperate in writing our code. And companies are considering, or actively pursuing, what that means for headcount. More and more developers are asking: “Will there be a job for me? How do I compete?”

But here’s what agents don’t do. They don’t drive home and pick up a task that’s not on a kanban board. They don’t lose a Saturday to a bad weld or experiment with different kinds of dough and oven temperatures. They don’t bake a loaf that fails three weekends in a row and quietly absorb the lesson that some processes can’t be hurried, no matter how clever the idea. They don’t ferment, restore, dig, solder, role-play or rebuild.

Agents have no Saturday. They have no irrational, over-obsessed curiosity we call a hobby.

Hobbies are unpressured, unstructured, unscheduled—messy mindbenders. That’s what agents miss. And this unpaid labor is where a lot of real learning happens. The kind that doesn’t show up in the sprint demo, but shows up in great architecture decisions, clever unit tests and surprising solutions.

Don’t Give Up on Your Hobbies

If you’re a developer wondering what to do with the noise about AI replacing you, here’s an honest answer: Look beyond the code. Lean harder into the things you make that nobody pays you for.

Your hobby isn’t a side-quest to the main game of being a developer. It’s not only about balance, self-care or free time. It’s where you keep growing the part of yourself that an agent can’t copy. Where character is formed. Where unconstrained thinking is allowed and you explore solutions only you have to justify.

That wonderful waste of a Saturday is the perspective that breaks through on a mundane Monday morning.

The coffee chat “what did you do over the weekend?” might be the context that wins over the agent whose most coffee-related moment is running a brew command in the terminal.

So bake the bread. Dig the well. Restore the van. Roll the dice.

Keep building without getting paid. That’s the work that keeps you irreplaceable.

For more than 20 years, Progress Telerik has helped developers build better software, faster.

AI hasn’t changed our mission. It’s changed the problems developers need help solving.

That’s why we’re excited to welcome Jeff Fritz back to Progress.

A Familiar Face Returns

If you’ve spent time in the .NET community over the last two decades, chances are you’ve crossed paths with Jeff. Whether through his Twitch channel, conference talks, videos or his work at Microsoft, Jeff has built a reputation for helping developers understand emerging technologies by demystifying complex ideas and making them immediately useful.

But prior to Microsoft, Jeff was part of the Telerik team, where he helped developers embrace modern .NET and web technologies. Jeff’s return to the team isn’t just a sentimental return, it’s also to help Progress as it moves in a new direction .

Like Jeff, for many developers, their journey with Progress Telerik began with our UI components. And we continue to help thousands of organizations build modern .NET and JavaScript web, desktop and mobile applications.

But as software development evolves, so do the challenges developers face. Today, engineering teams aren’t just building applications. They’re integrating AI to produce better experiences at a faster pace than ever.

That’s why we’re expanding the ways we help developers build better software. Alongside our already well-known UI components, we’re investing in tools that help teams build AI-powered applications and agents, accelerate software delivery and confidently observe, manage and govern intelligent systems. As AI reshapes software development, exceptional user experiences remain just as important They’re simply one part of a broader software engineering challenge.

This isn’t a departure from who we are. We are still doing what we’ve always done: giving developers the tools, knowledge and confidence to stay ahead of the next technology curve.

At the heart of every technology shift are the people who help others navigate it.

Throughout his career, Jeff has earned the trust of developers by making complex technology accessible without oversimplifying it. He has an innate ability to help developers understand not just what’s new, but why it matters and how to apply it in the real world.

And that philosophy couldn’t be more aligned with Progress’ own.

“I’ve spent my career helping developers understand what’s changing and how to turn new technology into practical, reliable solutions. Returning to Progress felt natural. This next era of software development demands tools that are thoughtful, durable and built with developers’ real challenges in mind—and I’m excited to help shape them.”

Jeff will be working closely with the community to share, learn, listen and lead. The technologies developers use will continue to evolve. That’s always been true. Our mission remains. We’ll continue helping developers build better software, faster, wherever technology takes us next.

Welcome back, Jeff. Let’s build what’s next.

Emotional intelligence (EI) refers to one’s ability to understand and manage emotions—not just their own, but those of the people around them.

A high emotional intelligence can be incredibly beneficial for web designers. For starters, honing your EI can help you work more effectively with others. Also, it can enable you to create more effective digital user experiences.

In this post, I’m going to share some tips on how designers can improve their work relationships with coworkers, clients and collaborators through emotional intelligence. I’ve also included info on how to use this skill to create more emotionally intelligent designs.

What Does Emotional Intelligence Look Like?

There are two sides to emotional intelligence. First, let’s look at what emotional intelligence looks like when we turn it inward:

Next, let’s look at emotional intelligence turned outward:

Improving Your Work Relationships with Emotional Intelligence

Here are some ways in which you might benefit from utilizing emotional intelligence in the workplace:

• Resolve conflicts speedily and equitably
• Reduce your own stress and prevent burnout
• Contribute to a healthy, supportive work environment
• Improve productivity and collaboration with coworkers
• Improve the client’s experience and build trust and loyalty in the process
• Develop a positive relationship with superiors and pave the way for greater responsibility and job opportunities

Here are some ways you can use emotional intelligence to improve your relationships at work.

Hit the Pause Button Before Reacting

Something happens that makes you want to react.

A client says they don’t like your designs for the second time without giving any constructive feedback. You get scheduled for a third meeting today despite your manager knowing you’re under a time crunch. The account manager didn’t give you all the details about a prospect and so you misspoke during the initial call.

Your body and mind may be screaming at you to react. You feel stuck.

If you react emotionally and right away, there could be negative consequences. But if you don’t do anything about it, you could be stuck with your emotions running high with nowhere for them to go.

To navigate something like this, you need to be able to pause and reflect on the situation objectively. This will give you a chance to slow down your emotions, consider what led to the situation from the other person’s point of view, and then come up with a logical and grounded resolution.

This also can be a valuable learning opportunity.

We all receive criticism at some point in our design careers. We all make mistakes, too. In some cases, our egos want to lash out or reject any responsibility for the situation.

With emotional intelligence, we teach our inner ego not to feel personally attacked or demoralized. Instead, we accept the role we played in the situation and calmly navigate it with the person who has confronted us.

Talk Things Out

I think one of the biggest problems that came about as a result of virtual work is the growing disconnection we feel from others. It’s all too easy to receive an email or request and to misinterpret its intent.

This can lead to:

• Guessing or assuming what the person meant, and then running with your own mistaken conclusions
• Allowing a (possibly perceived) negative experience to fester and then it turning into something bigger than it needed to be
• Feeling frustrated that someone isn’t getting what you’re saying, leaving you to feel as if you have to just do it yourself

In reality, a five-minute phone or Zoom call could have avoided all of this.

While I’m partially laying the blame at the foot of digital communication, poor communication skills in general can create these problems as well.

So, it’s not just important that you’re able to talk things out with others. You need to be able to listen and really hear what they’re saying. This is where social awareness comes into play.

For example, let’s say a junior designer was just hired at your agency. You’ve given them a bunch of tasks to do. You ask them, “Are you good with all this?” And their answer is …

“Yes? Yes. I think so.”

You heard the word “yes,” so that must mean they’re good. Now onto the pile of work waiting for you.

Is that really what they were saying though? While we expect everyone to be responsible for the tasks they assume, this new hire may have just been too nervous to say “no.” Their first “yes” sounded more like a question than an affirmative. And perhaps their body language suggested they were feeling anxious.

So, be careful not to accept certain buzzwords as the truth. Listen and then talk it out if you feel as though there’s a misunderstanding or misalignment between you and someone else.

Be Honest with Yourself and Others

Honesty is a big thing in emotional intelligence. You can see in the example above how dishonesty (no matter how innocent it may seem) can create a lot of problems for a web designer or their team.

When working in collaborative environments—with coworkers or with clients—honesty is critical. And it starts with yourself.

Rather than allowing your ego, fear or other emotions to make decisions for you, have an honest conversation with yourself first.

Let’s say your boss is really pleased with the job you’ve been doing as a senior web designer. They would like you to move into a creative director role by year’s end. The job comes with much longer hours. You’ll also have to complete a few courses between now and then with certifying exams.

You’re excited about the promotion and the increase in pay. In the moment, you want to accept the job, agree to whatever they want and immediately share the news with your partner.

Instead, you ask them for 48 hours to think about it. It’s not that you’re not thrilled about the opportunity, but there are some things to think through.

For starters, can you manage to commit more hours a week? Your partner is already stressed about how much time you work. Plus, the two of you were talking about having kids someday. Would that kind of schedule really be fair to all of you?

What’s more, do you even want to be a creative director? Will you find the work as fulfilling as what you do now? Does money matter more than job satisfaction or fulfillment?

An emotionally intelligent person wouldn’t betray themselves by making a hasty decision or one in which they have doubts. They would consider the matter from all angles, and then be honest about their needs, desires, limitations and so on with others.

Applying Emotional Intelligence to Your Web Design Work

Once you’ve learned how to wield your emotional intelligence on a personal level, you can leverage this skill to create emotionally intelligent digital experiences.

Let’s go back to the idea of emotional intelligence turned outward.

On one side of the coin, there is social awareness. This looks like:

• Recognizing how other people feel
• Empathizing with their situation
• Owning your role in the situation

On the other side is relationship management. This looks like:

• Providing a stable and consistent response
• Adapting your behaviors and reactions to other people and situations
• Being a beacon of responsibility and dependability, so that others feel safe in trusting you

While we can use tools like Google Analytics to tell us what happens on our websites or apps, they don’t help us understand the users’ emotional journey. And without that empathy or understanding, we can’t create digital experiences that are consistent, adaptable, helpful, trustworthy and ultimately satisfying.

To create these types of experiences, you can use:

User Psychology

User psychology can be a useful first step in emotionally intelligent design. For instance, you can use psychology to help you choose colors for your digital experience. It’s a helpful tool, for sure, but it can’t be the only one you use as it really only gives us insights about a generic “audience.”

User Research and Testing

User research methods like surveys, interviews, focus groups and usability tests give us invaluable insights about users. Instead of seeing users as IP addresses that interact with certain pages or screens, they become real people that we’re serving.

With this information, you can go on to develop user personas, empathy maps, user journey maps and content strategies built around your target users’ needs, preferences and challenges.

Feedback Collection

Once your product is live, it’s important to solicit feedback from your users from time to time. The feedback could pertain to their experience with:

• Using the website or app
• Contacting support
• Something they purchased

Feedback isn’t always constructive. Look at any reviews page online and you’ll see people leave one-star reviews with no comments. But if enough people feel passionately enough about an experience, you’ll start getting some really valuable input about what your users like and don’t like.

Iterative Design

In an ideal world, we’d start every web project off with a minimum viable product. This would allow us to deliver just what our users need without wasting too much time on things they might not.

Websites, apps and omnichannel digital experiences can and should continually be improved upon. Whether you’re able to begin all your projects as MVPs or not, iterative design should be part of your process.

When we use critical thinking, empathy and active listening, iterative design goes beyond the superficial. It allows us to really understand our users on an emotional level and to enhance their experiences based on what we learn about them over time.

Wrapping Up

Emotional intelligence is an incredibly valuable soft skill to have as a web designer. Not only can it make things go more smoothly for you at work, it also gives you the ability to design from a more empathetic lens.

Instead of navigating your job as a checklist of things to do, you start to see how your choices and actions affect others—both positively and negatively.

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.

In my technical accounting course back in the ’90s, there was a class on psychology. Out of everything I learned that semester, one phrase stayed with me until today: “Know thyself,” inscribed at the Temple of Apollo in Delphi and made eternal by Socrates.

Twenty-something years later, with a full career in software engineering behind me, I have realized this is the most underrated skill in our profession. We collect certificates, frameworks, languages and architecture. We stack courses on LinkedIn as if they were trophies. But we rarely stop to debug ourselves.

And what an irony. We, who spend our lives fixing other people’s bugs, are the ones least likely to look at our own.

Photo by Melissa Holowaty on Unsplash

Why This Matters for Those Who Write Code

Socrates also said that “an unexamined life is not worth living.” I would adapt this for our craft: a career without reflection is not worth building.

How many times have you accepted a project knowing it would drain your energy? How many times have you fought over a technical decision that, deep down, was just ego? How many times have you postponed rest because “just one more commit”? These are all symptoms, and symptoms must be treated at the cause, not in the stack trace.

The cause is almost always in a place that hurts to look at. That is why most people do not look.

The Method That Works for Me

There is no shortcut to self-knowledge, but there are tools. Mine are absurdly simple.

1. A Journal Connected to Goals

This is not a teenager’s diary. It is an engineer’s log. I write down epiphanies, decisions, situations that pushed me over the edge, and patterns that keep repeating. Will Durant said, “We are what we repeatedly do,” so I started observing what I was repeating.

2. Reflection Before Sleep

I replay the day in my head and imagine a better version of myself reacting to the same situations. It sounds silly, but it is mental training, just like writing tests for code that does not exist yet. You are programming future behavior.

3. Microsoft TO DO as a Measurement Instrument

I record everything I do during the month and categorize it. The categorized data becomes the input I feed to the AI later (more on that below).

Life Happens in Cycles

One thing I’ve noticed from keeping this habit is that life repeats itself in cycles, and the same lesson keeps coming back until you learn it. Every day, trivial situations (or not) will reappear. If you have already mapped out a better way to react in your head, you will change automatically when they return.

And there are moments when the entire system shifts: a trip, houseguests, a new project. When the ecosystem changes, a window opens to rewrite behaviors. It is like deploying a new version. The environment is already in maintenance mode, so take advantage of it.

I use these windows consciously. But I can only do that because I already know what I want to change. And that knowledge only came from the habit of observing myself.

Where AI Comes In, and Where It Falls Short

Part I: Using the TO DO

I use the TO DO tasks at the end of the month, export them and feed them to AI, asking for an honest analysis: what made me waste time, what I should eliminate and where I am running away from my own goals.

I did this throughout 2025 and into early 2026, and the results scared me, in a good way: too many tasks for a single developer; too many projects in the timeline; and it helped give me focus on the main solutions.

Part II: Using the LLM

This is the part that helped me the most over the past two years. The exercise goes like this.

1. Create a long document with the story of your life. Be detailed. List your traumas, your victories, your shames, your patterns. Be brutally honest.

2. Add a section about what you want to learn in the coming months.

3. Add a section about what you want to achieve in life.

4. Then ask the AI model:

“What did I fail to notice in my own story that is hidden in what I wrote?”

The result may surprise you. It surprised me. AI sees patterns you do not see, because you are inside the pattern.

But, and this “but” is large, AI hallucinates. It will make things up. It will reach wrong conclusions. It will tell you what you want to hear if you give it room. Use the result as a hypothesis, never as a diagnosis. The ideal is still a real therapist.

I use AI as a complementary mirror, and when something really hits me, I take it to someone who knows me, a close friend or a family member, to check it against a human perspective.

AI is a tool. A good and powerful one, but a tool. It does not replace therapy. It does not replace friendship. And it does not replace the courage to look at yourself.

Why It Hurts and Why It Is Worth It

Knowing yourself hurts. You may face things you would rather have forgotten. But those are exactly the things blocking your progress.

Nobody can help you out of your own shell. There is a cruel observation in nature: if you help a chick break its shell, it dies. It did not develop the strength needed for what comes next. Our shell works the same way. The effort itself is the development.

Seek adversity on purpose. Look for challenges that scare you a little. Try to be better than you were yesterday, not better than the developer at the next desk. You are your own obstacle, and nobody is going to fight that fight for you.

Conclusion

This is the path that worked for me. It will not work the same way for you. You need to find your own tools, your own pace, your own style of honesty.

But start. Open a document today, write your story, write what you want from life and what is holding you back. Reread it in a month. Reread it in a year. You will see things that are invisible to you today.

Investing in new frameworks gives you a few months’ advantage. Investing in yourself earns you a lifetime.