Smashingmagazine

I’ve spent over two decades in the trenches of user experience design. I remember the transition from table-based layouts to CSS, the pivot to responsive design when the iPhone launched, and the rise of the “attention economy.” But as we navigate 2026, the industry is facing its most significant shift yet. We are moving past the era of “design at any cost” into the era of Sustainable UX.

It’s not something most designers think about, including myself, until I was prompted by hearing about this as a concept. For years, we have treated the internet as an ethereal, weightless cloud. We have assumed that digital products were “green” simply because they weren't printed on paper. I used to think that too, and before the concept of climate change emerged, it was more about saving trees.

We were wrong. The cloud is a physical infrastructure, a sprawling network of data centres, undersea cables, and cooling systems that hum 24/7. While AI-focused data centers match the power consumption of massive aluminum smelters, their high geographic density creates an even more intense and localised environmental strain.

As UX designers, we are the architects of this energy consumption. Every high-resolution hero image, every auto-playing background video, and every complex JavaScript animation we approve is a direct instruction to a processor to consume power. If we want to build a future that lasts, we must stop designing for “wow” and start designing for efficiency.

Dark Mode

In the early 2000s, white backgrounds were the standard because they mimicked the familiarity of paper. However, the hardware has evolved, and our design philosophy must follow. The shift from LCD to OLED (Organic Light Emitting Diode) technology has fundamentally changed how colour impacts energy.

The Logic

Unlike traditional LCD screens, which require a backlight that is always on (even when displaying black), OLED screens illuminate each pixel individually. When a pixel is set to true black (#000000), that specific diode is turned completely off. It draws zero power.

By designing interfaces that favour darker palettes, we aren’t just following a trend; we are physically reducing the energy requirement of the user’s device.

The Data

The energy savings are far from negligible. A landmark study by Purdue University in 2021, which has become the gold standard for this discussion, revealed that at 100% brightness, switching from light mode to dark mode can save an average of 39% to 47% of battery power. On a global scale, if every major app defaulted to dark mode, the reduction in grid demand would be astronomical.

The Design Goal

In 2026, Dark Mode should no longer be a secondary “theme” tucked away in a settings menu. We should be designing with a “Dark-First” mentality. This doesn’t mean every site must look like The Matrix, but it does mean prioritising high-contrast dark themes as the default system-preferred state. This extends the hardware lifespan of the device and lowers the carbon footprint of every interaction.

I personally prefer Light-Mode for reading, so it makes sense to have both light and dark mode options available. There are also accessibility considerations with providing both options.

Image And Video Optimisation

We have become lazy designers. With high-speed 5G and fibre optics, we’ve stopped worrying about file sizes. The average mobile page weight has increased by over 500% in the last decade, largely due to unoptimized visual assets.

The Logic

The “Digital Fat” of a website (those 4MB Unsplash photos and 15MB background videos) is the single largest contributor to page-load energy. Every megabyte transferred from a server to a client requires electricity for the transmission, the server’s processing, and the user’s rendering engine. When we use massive files, we are essentially “burning” energy to show a picture that could have been just as effective at a fraction of the size. Not to mention, you are also providing a better user experience with a page that loads much faster.

The Data

According to the HTTP Archive, images and video consistently account for the lion’s share of a page’s total weight. However, the shift to modern formats like AVIF and WebP can reduce image weight by up to 50% compared to JPEG, without any perceptible loss in quality.

Although these formats are not as familiar to me as JPG and PNG, I am definitely looking forward to using them to reduce page size.

The Design Goal

I recently led a redesign for a cybersecurity platform. By implementing a “Before and After” audit, we discovered that their homepage was loading 5.5MB of data. By replacing high-res photography with SVG (Scalable Vector Graphics) art and using clever CSS gradients instead of image assets, we dropped the load to 1.2MB. That is a 78% reduction in energy load! As a designer, your first question should always be:

“Do I need a photo for this, or can I achieve the same emotional resonance with code?” Intentional Motion: Cutting “Loud" Animations

We live in an era of “scroll-jacking” and complex 3D Parallax effects. While these might win awards on Awwwards.com, they are often ecological disasters.

The Logic

Animation is not free. To render a complex animation, the device’s GPU (Graphics Processing Unit) must work at high capacity. This increases the CPU temperature, triggers cooling fans (in laptops), and drains battery rapidly. “Loud” animations that run constantly in the background or trigger massive re-paints of the browser are the energy equivalent of leaving your car idling in the driveway.

The Data

Google’s Material Design guidelines emphasize “Meaningful Motion.” They argue that animation should be used only to orient the user or provide feedback. And using WebP instead of JPEG can save 25-50% of data on a page.

The Design Goal

We must adopt Meaningful Motion. If an animation doesn’t help a user complete a task or understand a hierarchy, it is a waste. We should favour CSS transitions over heavy JavaScript libraries like GSAP or Lottie where possible, as CSS is hardware-accelerated and far more efficient for the browser to calculate.

As a UX designer, I can’t argue this approach. This not only helps reduce data waste but also improves UX for our users.

Setting A “Data Budget” For Every Project

In my 20+ years of UX, the most successful projects have generally been the ones with the tightest constraints.

Just as a project has a financial budget, it should also have a carbon and data budget.

The Logic

A Data Budget is a hard cap on the total size of a page (e.g., “This landing page cannot exceed 1MB”). This forces the design team to make difficult, intentional choices. If you want to add a new tracking script or a fancy font weight, you have to “pay” for it by optimising or removing something else. This prevents “feature creep” from turning into “carbon creep.”

The Data

The Sustainable Web Design model, developed by pioneers like Wholegrain Digital, provides a formula to calculate the CO2 per page view. The average website produces about 0.5 grams of CO2 per view. For a site with 1 million monthly views, that’s 6 metric tons of CO2 a year, equivalent to driving a car 15,000 miles.

The Design Goal

The Sustainable UX Checklist

• Reduce Images
  Question the necessity of every visual and use the smallest resolution and most efficient file formats (like AVIF) to minimize data transfer.
• Optimise Video
  Eliminate auto-playing media and prioritise highly compressed, short loops to ensure energy is only spent on content the user intends to view.
• Limit Fonts
  Use a maximum of two web font weights or stick to classic system fonts to remove unnecessary server requests and rendering bloat.
• Recycle Assets
  Repurpose a single image or video multiple times using CSS filters and overlays to create visual variety without increasing the total page weight.
• Choose Green Hosting
  Host your digital products on servers verified by The Green Web Foundation to ensure they are powered by renewable energy sources.
• Minimize Data Distance
  Select server locations geographically close to your primary audience to reduce the energy required for data to travel through physical infrastructure.

The Business Case For Eco-friendly Design

Some might argue that “Green UX” sounds like a compromise on quality. On the contrary, it is a competitive advantage. Sustainable design is performance design.

When you reduce page weight, your site loads faster. When your site loads faster, your Core Web Vitals improve. When your Core Web Vitals improve, your SEO ranking goes up. Furthermore, users on older devices or slower data plans (especially in emerging markets) can actually access your product. This is the definition of “Inclusive Design.”

By cutting the “digital fat,” we create a leaner, faster, and more accessible web. We are moving away from the “disposable design” of the 2010s toward a more permanent, respectful digital architecture.

Conclusion: The Future Of “Clean” Design

In my two decades of design, I’ve seen many trends come and go. Skeuomorphism, Flat Design, Neumorphism — they were all aesthetic choices. But sustainable UX isn’t a trend; it’s now a necessity. We are the first generation of designers who have to reckon with the physical consequences of our digital work.

Sustainable UX is a “win-win-win.” It’s better for the planet because it reduces energy consumption. It’s better for the user because it results in faster, more responsive interfaces. And it’s better for the business because it lowers hosting costs AND improves conversion rates.

The era of “unlimited pixels” is over. In 2026, the most sophisticated design is the one that leaves the smallest footprint. We are no longer just designers; we are the guardians of the user’s battery, their data plan, and ultimately, the environment.

The Call To Action

I challenge you to audit just one page of your current project today. Use a tool like the Website Carbon Calculator to see its impact. Then, look for the “invisible waste.” Can that image be an SVG? Can that video be a static hero? Can that “loud” animation be silenced?

Start small. The most elegant solution is often the one with the fewest bytes.

I’m sure you’ve heard of streaks or used an app with one. But ever wondered why streaks are so popular and powerful? Well, there is the obvious one that apps want as much of your attention as possible, but aside from that, did you know that when the popular learning app Duolingo introduced iOS widgets to display streaks, user commitment surged by 60%. Sixty percent is a massive shift in behaviour and demonstrates how “streak” patterns can be used to increase engagement and drive usage.

At its most basic, a streak is the number of consecutive days that a user completes a specific activity. Some people also define it as a “gamified” habit or a metric designed to encourage consistent usage.

But streaks transcend beyond being a metric or a record in an app; it is more psychological than that. Human instincts are easy to influence with the right factors. Look at these three factors: progress, pride, and fear of missing out (commonly called FOMO). What do all these have in common? Effort. The more effort you put into something, the more it shapes your identity, and that is how streaks crosses into the world of behavioural psychology.

Now, with great power comes great responsibility, and because of that, there’s a dark side to streaks.

In this article, we’ll be going into the psychology, UX, and design principles behind building an effective streak system. We’ll look at (1) why our brains almost instinctively respond to streak activity, (2) how to design streaks in ways that genuinely help users, and (3) the technical work involved in building a streak pattern.

The Psychology Behind Streaks

To design and build an effective streak system, we need to understand how it aligns with how our brains are wired. Like, what makes it so effective to the extent that we feel so much intense dedication to protect our streaks?

There are three interesting, well-documented psychology principles that support what makes streaks so powerful and addictive.

Loss Aversion

This is probably the strongest force behind streaks. I say this because most times, you almost can’t avoid this in life.

Think of it this way: If a friend gives you $100, you’d be happy. But if you lost $100 from your wallet, that would hurt way more. The emotional weight of those situations isn’t equal. Loss hurts way more than gain feels good.

Let’s take it further and say that I give you $100 and ask you to play a gamble. There’s a 50% chance you win another $100 and a 50% chance you lose the original $100. Would you take it? I wouldn’t. Most people wouldn’t. That’s loss aversion.

If you think about it, it is logical, it is understandable, it is human.

The concept behind loss aversion is that we feel the pain of losing something twice as much as the pleasure of gaining something of equal value. In psychological terms, loss lingers more than gains do.

You probably see how this relates to streaks. To build a noticeable streak, it requires effort; as a streak grows, the motivation behind it begins to fade; or more accurately, it starts to become secondary.

Here’s an example: Say your friend has a three-day streak closing their “Move Rings” on their Apple Watch. They have almost nothing to lose beyond wanting to achieve their goal and be consistent. At the same time, you have an impressive 219-day streak going. Chances are that you are trapped by the fear of losing it. You most likely aren’t thinking about the achievement at this point; it’s more about protecting your invested effort, and that is loss aversion.

Duolingo explains how loss aversion contributes to a user’s reluctance to break a long streak, even on their laziest days. In a way, a streak can turn into a habit when loss aversion settles in.

The Fogg Behaviour Model (B = MAP)

Now that we understand the fear of losing the effort invested in longer streaks, another question is: What makes us do the thing in the first place, day after day, even before the streak gets big?

That’s what the Fogg Behaviour Model is about. It is relatively simple. A behaviour (B) only occurs when three factors — Motivation (M), Ability (A), and Prompt (P) — align at the same moment. Thus, the equation B=MAP.

If any of these factors, even one, is missing at that moment, the behaviour won’t happen.

So, for a streak system to be efficient and recurring, all three factors must be present:

Motivation
This is fragile and not something that is consistently present. There are days when you’re pumped to learn Spanish, and days you don’t even feel an iota of willpower to learn the language. Motivation by itself to build a habit is unreliable and a losing battle from day one.

Ability
To compensate for the limitations of motivation, ability is critical. In this context, ability means the ease of action, i.e, the effort is so easy that it’s unrealistic to say it isn’t possible. Most apps intentionally use this. Apple Fitness just needs you to stand for one minute in an hour to earn a tick towards your Stand goal. Duolingo only needs one completed lesson. These tasks do not require all that much effort. The barrier is so low that even on your worst days, you can do it. But the combined effort of an ongoing streak is where the idea of losing that streak kicks in.

Prompt
This is what completes the equation. Humans are naturally forgetful, so yes, ability can get us 90% there. But a prompt reminds us to act. Streaks are persistent by design, so users need to be constantly reminded to act. To see how powerful a prompt can be, Duolingo did an A/B test to see if a little red badge on the app’s icon increased consistent usage. It produced a 6% increase in daily active users. Just a red badge.

Model Limitations

All this being said, there is a limitation to the Fogg model whereby critics and modern research have noticed that a design that relies too heavily on prompts, like aggressive notifications, risks creating mental fatigue. Constant notifications and overtime could cause users to churn. So, watch out for that.

The Zeigarnik Effect

How do you feel when you leave a task of project half-done? That irritates many people because unfinished tasks occupy more mental space than the things we complete. When something is done and gone, we tend to forget it. When something is left undone, it tends to weigh on our minds.

This is exactly why digital products use artificial progress indicators, like Upwork's profile completion bar, to let a user know that their profile is only “60% complete”. It nudges the user to finish what they started.

Let’s look at another example. You have five tasks in a to-do list app, and at the end of the day, you only check four of them as completed. Many of us will feel unaccomplished because of that one unfinished task. That, right there, is the Zeigarnik effect.

The Zeigarnik effecthe was demonstrated by psychologist Bluma Zeigarnik, who described that we tend to keep incomplete tasks active in our memory longer than completed tasks.

A streak pattern naturally taps into this in UX design. Let’s say you are on day 63 of a learning streak. At that point, you’re in an ongoing pattern of unfinished business. Your brain would rarely forget about it as it sits in the back of your mind. At this point, your brain becomes the one sending you notifications.

When you put these psychological forces together, you begin to truly understand why streaks aren’t just a regular app feature; they are capable of reshaping human behaviour.

But somewhere along the line — I can’t say exactly when, as it differs for everyone — things reach a point where a streak shifts from “fun” to something you feel you can’t afford to lose. You don’t want 58 days of effort to go to waste, do you? That is what makes a streak system effective. If done right, streaks help users build astounding habits that accomplish a goal. It could be reading daily or hitting the gym consistently.

These repeated actions (sometimes small) compound over time and become evident in our daily lives. But there are two sides to every coin.

The Thin Line Between Habit And Compulsion

If you have been following along, you can already tell there’s a dark side to streak systems. Habit formation is about consistency with a repeated goal. Compulsion, however, is the consistency of working on a goal that is no longer needed but held onto out of fear or pressure. It is a razor-thin line.

You brush your teeth every morning without thinking; it is automatic and instinctive, with a clear goal of having good breath. That’s a streak that forms a good habit. An ethical streak system gives users space to breathe. If, for some reason, you don’t brush in the morning, you can brush at noon. Imperfection is allowed without fear of losing a long effort.

Compulsion takes the opposite route, whereby a streak makes you anxious, you feel guilty or even exhausted, and sometimes, it feels like you haven’t accomplished anything, despite all your work. You act not because you want to, but because you’re subconsciously terrified of seeing your progress reset to zero.

Someone even described this perfectly, “I felt that I was cheating, but simply did not care. I am nothing without my streak”. This shows the extreme hold streaks can have on an individual. To the extent that users begin to tie their self-worth to an arbitrary metric rather than the original goal or reason they started the streak in the first place. The streak becomes who they are, not just what they do.

A well-designed ethical streak system should feel like encouragement to the user, not pressure or obligation. This relates to the balance of intrinsic and extrinsic motivation. Extrinsic motivation (external rewards, avoiding punishment) might get users started, but intrinsic motivation (doing the task for a personal goal like learning Spanish because you genuinely want to communicate with a loved one) is stronger for long-term engagement.

A good system should gravitate towards intrinsic motivation with careful use of extrinsic elements, i.e., remind users of how far they have come, not threaten them with what they might lose. Again, it is a fine line.

A simple test when designing a streak system is to actually take some time and think whether your products make money by selling solutions to anxiety that your product created. If yes, there’s a high chance you are exploiting users.

So the next question becomes, If I choose to use streak, how do I design it in a way that genuinely helps users achieve their goals?

The UX of Good Streak System Design

I believe this is where most projects either nail an effective streak system or completely mess it up. Let’s go through some UX principles of a good streak design.

Keep It Effortless

You’ve probably heard this before, maybe from books like Atomic Habits, but it’s worth mentioning that one of the easiest ways habits can be formed is by making the action tiny and easy. This is similar to the ability factor we discussed from the Fogg Behaviour Model.

The first rule of any streak design should be making the required action as small as humanly possible while still achieving progress.

If a daily action requires willpower to complete, that action won’t make it past five days. Why? You can’t be motivated five days in a row.

Case in point: If you run a meditation app, you don’t need to make users go through a 20-minute session just to maintain the streak. Try a single minute, maybe even something as small as thirty seconds, instead.

As the saying goes, little drops of water make the mighty ocean). Small efforts compile into big achievements with time. That should be the goal: remove friction, especially when the moment might be difficult. When users are stressed or overwhelmed, let them know that simply showing up, even for a few seconds, counts as effort.

Provide Clear Visual Feedback

Humans are visual by nature. Most times, we need to see something to believe; there’s this need to visualize things to understand them better and put things into perspective.

This is why streak patterns often use visual elements, like graphs, checkmarks, progress rings, and grids, to visualize effort. Look at GitHub’s contribution graph. It is a simple visualization of consistency. Yet developers breathe it in like oxygen.

The key is not to make a streak system feel abstract. It should feel real and earned. For instance, Duolingo and Apple’s Fitness activity rings use clean animation designs on completion of a streak, and GitHub shows historical data of a user’s consistency over time.

Use Good Timing

I mentioned earlierthat humans are generally forgetful by nature, and that prompts can help maintain forward momentum. Without prompts, most new users forget to keep going. Life can get busy, motivation disappears, and things happen. Even long-time users benefit from prompts, though most times, they are already locked inside the habit loop. Nevertheless, even the most committed person can accidentally miss a day.

Your streak system most definitely needs reminders. The most-used prompt reminders are push notifications. Timing really matters when working with push notifications. The type of app matters, too. Sending a notification at 9 a.m. saying “You haven’t practiced today” is just weird for a learning app because many have things to do in the day before they even think about completing a lesson. If we’re talking about a fitness app, though, it is reasonable and maybe even expected to be reminded earlier in the day.

Push notifications vary significantly by app category. Fitness apps, for instance, see higher engagement with early morning notifications (7–8 AM), while productivity apps might perform better in early noon. The key is to A/B test your app’s timing based on your users' behaviours rather than assuming things are one-size-fits-all. What works for a meditation app might not work for a coding tracker.

Other prompt methods are red dots on the app icon and even app widgets. Studies vary, but the average person unlocks their device between 50-150 times a day (PDF). If a user sees a red dot on an app or a widget that indicates a current streak every time they unlock their phone, it increases commitment.

Just don’t overdo it; the prompt should serve as a reminder, not a nag.

Celebrate Milestones

A streak system should try to celebrate milestones to reignite emotions, especially for users deep into a streak.

When a user hits Day 7, Day 30, Day 50, Day 100, Day 365, you should make a big deal out of it. Acknowledge achievements — especially for long-time users.

As we saw earlier, Duolingo figured this out and implemented an animated graphic that celebrates milestones with confetti. Some platforms even give substantial bonus rewards that validate users’ efforts. And this can be beneficial to apps, such that users tend to share their milestones publicly on social media.

Another benefit is the anticipation that comes before reaching milestones. It isn’t just keeping the streak alive endlessly; users have something to look forward to.

Use Grace Mechanisms

Life is unpredictable. People get distracted. Any good streak system should expect imperfection. One of the biggest psychological threats to a streak system is the hard reset to zero after just a single missed day.

An “ethical” streak system should provide the user with some slack. Let’s say you have a 90-day chess learning streak. You have been consistent for three good months, and one day, your phone dies while traveling, and just like that, 90 becomes 0 — everything, all that effort, is erased, and progress vanishes. The user might be completely devastated. The thought of rebuilding it from scratch is so demoralizing that the effort isn’t worth it. At worst, a user might abandon the app after feeling like a failure.

Consider adding a “grace” mechanism to your streak system:

• Streak Freeze
  Allow users to intentionally miss a day without penalties.
• Extra Time
  Allow a few hours (2–3) past the usual deadline before triggering a reset.
• Decay Models
  Instead of a hard reset, the streak decreases by a small amount, e.g., 10 days is deducted from the streak per missed day.

Use An Encouraging Tone

Let’s compare two messages shown to users when a streak breaks:

1. “You lost your 42-day streak. Start over.”
2. “You showed up for 42 days straight. That’s incredible progress! Wanna give it another try?”

Both convey the same information, but the emotional impact is different. The first message would most likely make a user feel demoralized and cause them to quit. The second message celebrates what has already been achieved and gently encourages the user to try again.

Streak Systems Design Challenges

Before we go into the technical specifics of building a streak system, you should be aware of the challenges that you might face. Things can get complicated, as you might expect.

Handling Timezones

There is a reason why handling time and date is among the most difficult concepts developers deal with. There’s formatting, internationalization, and much more to consider.

Let me ask you this: What counts as a day?

We know the world runs on different time zones, and as if that is not enough, some regions have Daylight Saving Time (DST) that happens twice a year. Where do you even begin handling these edge cases? What counts as the “start” of tomorrow?

Some developers try to avoid this by using one central timezone, like UTC. For some users, this would yield correct results, but for some, it could be off by an hour, two hours, or more. This inconsistency ruins the user experience. Users care less how you handle the time behind the scenes; all they expect is that if they perform a streak action at 11:40 p.m., then it should register at that exact time, in their context. You should define “one day” based on the user’s local timezone, not the server time.

Sure, you can take the easy route and reset streaks globally for all users at midnight UTC, but you are very much creating unfairness. Someone in California always has eight extra hours to complete their task than someone living in London. That’s an unjust design flaw that punishes certain users because of their location. And what if that person in London is only visiting, completes a task, then returns to another timezone?

One effective solution to all these is to ask users to explicitly set their timezone during onboarding (preferably after first authentication). It’s a good idea to include a subtle note that providing timezone information is only used for the app to accurately track progress, rather than being used as personally identifiable data. And it’s another good idea to make that a changeable setting.

I suggest that anyone avoid directly handling timezone logic in an app. Use tried-and-true date libraries, like Moment.js or pytz (Python), etc. There’s no need to reinvent the wheel for something as complex as this.

Missed Days And Edge Cases

Another challenge you should worry about is uncontrollable edge cases like users oversleeping, server downtime, lag, network failures, and so on. Using the idea of grace mechanisms, like the ones we discussed earlier, can help.

A grace window of two hours might help both user and developer, in the sense that users are not rigidly punished for uncontrollable life circumstances. For developers, grace windows are helpful in those uncontrollable moments when the server goes down in the middle of the night.

Above all, never trust the client. Always validate on the server-side. The server should be the single source of truth.

Cheating Prevention

Again, I cannot stress this enough: Make sure to validate everything server-side. Users are humans, and humans might cheat if given the opportunity. It is unavoidable.

You might try:

• Storing all actions with UTC timestamps.
  The client can send their local time, but the server can immediately convert that to UTC and validate against the server time. That way, if the client's timestamp is suspiciously far, the system can reject it as an error, and the UI can respond accordingly.
• Using event-based tracking.
  In other words, store a record of each action with metadata including information like the user’s ID, the type of action performed, and the timestamp and timezone. This helps with validation.

Building A Streak System Engine

This isn’t a code tutorial, so I will avoid dumping a bunch of code on you. I’ll keep this practical and describe how things generally operate a streak system engine as far as architecture, flow, and reliability.

Core Architecture

As I’ve said several times, make the serverthe single source of truth for streak data. The architecture can go something like this on the server:

• Store each user’s data in a database.
• Store the current streak store (default as 0) as an integer.
• Store the timezone preference, i.e., IANA Timezone string (either implicitly from local timestamp or explicitly by asking user to select their timezone). For example, “America/New_York”.
• Handle all logic to determine if the streak continues or breaks, with a timezone check that is relative to the user’s local timezone.

Meanwhile, on the client-side:

• Display the current streak, normally fetched from the server.
• Send action done in the form of metadata to the server to validate whether the user actually completed a qualifying streak action.
• Provide visual feedback based on the server responses.

So, in short, the brain is on the server, and the client is for display purposes and submitting events. This saves you a lot of failures and edge cases, plus makes updates and fixes easier.

The Logical Flow

Let’s simulate a walkthrough of how a minimal efficient streak system engine would go when a user completes an action:

1. The user completes a qualifying streak action.
2. The client sends an event to the server as metadata. This could be “User X completed action Y at timestamp Z”.
3. The server receives this event and does basic validation. Is this a real user? Are they authenticated? Is the action valid? Is the timezone consistent?
4. If this passes, the server retrieves the user’s streak data from the database.
5. Then, convert the received action timestamp to the user’s local timezone.
6. Let the server compare the calendar dates (not timestamps) in the user's local timezone:
   • If it is the same day, then the action is redundant and there is no change in the streak.
   • If it is the next day, then the streak extends and increments by 1.
   • If there is a gap of more than one day, the streak breaks. However, this is where you might apply grace mechanics.
   • If the grace mechanism is missed, then reset the streak to 1.
7. If you choose to save historical data for milestone achievements, then update variables like “longest streak” or “total active days”.
8. The server then updates the database and responds to the client. Something like this:

{ "current_streak": 48, "longest_streak": 50, "total_active_days": 120, "streak_extended": true, }

As a further measure, the server should either retry or reject and notify the client when anything fails during the process.

Building For Resilience

As mentioned before, users losing a streak due to bugs or server downtime is terrible UX, and users don’t expect to take the fall for it. Thus, your streak system should have safeguards for those scenarios.

If the server is down for maintenance (or whatever reason), consider allowing a temporary window of additional hours to get it fixed so actions can be submitted late and still count. You can also choose to notify users, especially if the situation is capable of affecting an ongoing streak.

Note: Establish an admin backdoor where data can be manually restored. Bugs are inevitable, and some users would call your app out or reach out to support that their streak broke for a reason they could not control. You should be able to manually restore the streaks if, after investigation, the user is right.

Conclusion

One thing remains clear: Streaks are really powerful because of how human psychology works on a fundamental level.

The best streak system out there is the one that users don’t think about consciously. It has become a routine of immediate results or visible progress, like brushing teeth, which becomes a regular habit.

And I’m just gonna say it: Not all products need a streak system. Should you really force consistency just because you want daily active users? The answer may very well be “no”.

Imagine a user opening a mental health app while feeling overwhelmed with anxiety. The very first thing they encounter is a screen with a bright, clashing colour scheme, followed by a notification shaming them for breaking a 5-day “mindfulness streak,” and a paywall blocking the meditation they desperately need at that very moment. This experience isn’t just poor design; it can be actively harmful. It betrays the user’s vulnerability and erodes the very trust the app aims to build.

When designing for mental health, this becomes both a critical challenge and a valuable opportunity. Unlike a utility or entertainment app, the user’s emotional state cannot be treated as a secondary context. It is the environment your product operates in.

With over a billion people living with mental health conditions and persistent gaps in access to care, safe and evidence-aligned digital support is increasingly relevant. The margin for error is negligible. Empathy-Centred UX becomes not a “nice to have” but a fundamental design requirement. It is an approach that moves beyond mere functionality to deeply understand, respect, and design for the user’s intimate emotional and psychological needs.

But how do we translate this principle into practice? How do we build digital products that are not just useful, but truly trustworthy?

Throughout my career as a product designer, I’ve found that trust is built by consistently meeting the user’s emotional needs at every stage of their journey. In this article, I will translate these insights into a hands-on empathy-centred UX framework. We will move beyond theory to dive deeper into applicable tools that help create experiences that are both humane and highly effective.

In this article, I’ll share a practical, repeatable framework built around three pillars:

1. Onboarding as a supportive first conversation.
2. Interface design for a brain in distress.
3. Retention patterns that deepen trust rather than pressure users.

Together, these pillars offer a grounded way to design mental health experiences that prioritise trust, emotional safety, and real user needs at every step.

The Onboarding Conversation: From a Checklist to a Trusted Companion

Onboarding is “a first date” between a user and the app — and the first impression carries immense stakes, determining whether the user decides to continue engaging with the app. In mental health tech, with up to 20,000 mental-health-related apps on the market, product designers face a dilemma of how to integrate onboarding’s primary goals without making the design feel too clinical or dismissive for a user seeking help.

The Empathy Tool

In my experience, I have found it essential to design onboarding as the first supportive conversation. The goal is to help the user feel seen and understood by delivering a small dose of relief quickly, not just overload them with data and the app’s features. Case Study: A Teenager’s Parenting Journey

At Teeni, an app for parents of teenagers, onboarding requires an approach that solves two problems: (1) acknowledge the emotional load of parenting teens and show how the app can share that load; (2) collect just enough information to make the first feed relevant.

Recognition And Relief

Interviews surfaced a recurring feeling among parents: “I’m a bad parent, I’ve failed at everything.” My design idea was to provide early relief and normalisation through a city-at-night metaphor with lit windows: directly after the welcome page, a user engages with three brief, animated and optional stories based on frequent challenges of teenage parenting, in which they can recognise themselves (e.g., a story of a mother learning to manage her reaction to her teen rolling their eyes). This narrative approach reassures parents that they are not alone in their struggles, normalising and helping them cope with stress and other complex emotions from the very beginning.

Note: Early usability sessions indicated strong emotional resonance, but post-launch analytics showed that the optionality of the storytelling must be explicit. The goal is to balance the storytelling to avoid overwhelming the distressed parent, directly acknowledging their reality: “Parenting is tough. You’re not alone.”

Progressive Profiling

To tailor guidance to each family, we defined the minimal data needed for personalisation. On the first run, we collect only the essentials for a basic setup (e.g., parent role, number of teens, and each teen’s age). Additional, yet still important, details (specific challenges, wishes, requests) are gathered gradually as users progress through the app, avoiding long forms for those who need support immediately.

The entire onboarding is centred around a consistently supportive choice of words, turning a typically highly practical, functional process into a way to connect with the vulnerable user on a deeper emotional level, while keeping an explicit fast path.

Your Toolbox

• Use Validating Language
  Start with “It’s okay to feel this way,” not “Allow notifications.”
• Understand “Why”, not just “What”
  Collect only what you’ll use now and defer the rest via progressive profiling. Use simple, goal-focused questions to personalise users’ experience.
• Prioritise Brevity and Respect
  Keep onboarding skimmable, make optionality explicit, and let user testing define the minimum effective length &mdashl the shorter is usually the better.
• Keep an Eye on Feedback and Iterate
  Track time-to-first-value and step drop-offs; pair these with quick usability sessions, then adjust based on what you learn.

This initial conversation sets the stage for trust. But this trust is fragile. The next step is to ensure the app’s very environment doesn’t break it.

The Emotional Interface: Maintaining Trust In A Safe Environment

A user experiencing anxiety or depression often shows reduced cognitive capacity, which affects their attention span and the speed with which they process information and lowers tolerance for dense layouts and fast, highly stimulating visuals. This means that high-saturation palettes, abrupt contrast changes, flashing, and dense text can feel overwhelming for them.

The Empathy Tool

When designing a user flow for a mental health app, I always apply the Web Content Accessibility Guidelines 2.2 as a foundational baseline. On top of that, I choose a “low-stimulus”, “familiar and safe” visual language to minimise the user’s cognitive load and create a calm, predictable, and personalised environment. Where appropriate, I add subtle, opt-in haptics and gentle micro-interactions for sensory grounding, and offer voice features as an option in high-stress moments (alongside low-effort tap flows) to enhance accessibility.

Imagine you need to guide your users “by the hand”: we want to make sure their experience is as effortless as possible, and they are quickly guided to the support they need, so we avoid complicated forms and long wordings.

Case: Digital Safe Space

For the app focused on instant stress relief, Bear Room, I tested a “cosy room” design. My initial hypothesis was validated through a critical series of user interviews: the prevailing design language of many mental health apps appeared misaligned with the needs of our audience. Participants grappling with conditions such as PTSD and depression repeatedly described competing apps as “too bright, too happy, and too overwhelming,” which only intensified their sense of alienation instead of providing solace. This suggested a mismatch for our segment, which instead sought a sense of safety in the digital environment.

This feedback informed a low-arousal design strategy. Rather than treating “safe space” as a visual theme, we approached it as a holistic sensory experience. The resulting interface is a direct antithesis to digital overload; it gently guides the user through the flow, keeping in mind that they are likely in a state where they lack the capacity to concentrate. The text is divided into smaller parts and is easily scannable and quickly defined. The emotional support tools — such as a pillow — are highlighted on purpose for convenience.

The interface employs a carefully curated, non-neon, earthy palette that feels grounding rather than stimulating, and it rigorously eliminates any sudden animations or jarring bright alerts that could trigger a stress response. This deliberate calmness is not an aesthetic afterthought but the app’s most critical feature, establishing a foundational sense of digital safety.

To foster a sense of personal connection and psychological ownership, the room introduces three opt-in “personal objects”: Mirror, Letter, and Frame. Each invites a small, successful act of contribution (e.g., leaving a short message to one’s future self or curating a set of personally meaningful photos), drawing on the IKEA effect (PDF).

For instance, Frame functions as a personal archive of comforting photo albums that users can revisit when they need warmth or reassurance. Because Frame is represented in the digital room as a picture frame on the wall, I designed an optional layer of customisation to deepen this connection: users can replace the placeholder with an image from their collection — a loved one, a pet, or a favourite landscape — displayed in the room each time they open the app. This choice is voluntary, lightweight, and reversible, intended to help the space feel more “mine” and deepen attachment without increasing cognitive load.

Note: Always adapt to the context. Try to avoid making the colour palette too pastel. It is useful to balance the brightness based on the user research, to protect the right level of the app’s contrast.

Case: Emotional Bubbles

In Food for Mood, I used a visual metaphor: coloured bubbles representing goals and emotional states (e.g., a dense red bubble for “Performance”). This allows users to externalise and visualise complex feelings without the cognitive burden of finding the right words. It’s a UI that speaks the language of emotion directly.

In an informal field test with young professionals (the target audience) in a co-working space, participants tried three interactive prototypes and rated each on simplicity and enjoyment. The standard card layout scored higher on simplicity, but the bubble carousel scored better on engagement and positive affect — and became the preferred option for the first iteration. Given that the simplicity trade-off was minimal (4/5 vs. 5/5) and limited to the first few seconds of use, I prioritised the concept that made the experience feel more emotionally rewarding.

Case: Micro-interactions And Sensory Grounding

Adding a touch of tactile micro-interactions like bubble-wrap popping in Bear Room, may also offer users moments of kinetic relief. Integrating deliberate, tactile micro-interactions, such as the satisfying bubble-wrap popping mechanic, provides a focused act that can help an overwhelmed user feel more grounded. It offers a moment of pure, sensory distraction for a person stuck in a torrent of stressful thoughts. This isn’t about gamification in the traditional, points-driven sense; it’s about offering a controlled, sensory interruption to the cycle of anxiety.

Note: Make tactile effects opt-in and predictable. Unexpected sensory feedback can increase arousal rather than reduce it for some users.

Case: Voice Assistants

When a user is in a state of high anxiety or depression, it can become an extra effort for them to type something in the app or make choices. In moments when attention is impaired, and a simple, low-cognitive choice (e.g., ≤4 clearly labelled options) isn’t enough, voice input can offer a lower-friction way to engage and communicate empathy.

In both Teeni and Bear Room, voice was integrated as a primary path for flows related to fatigue, emotional overwhelm, and acute stress — always alongside a text input alternative. Simply putting feelings into words (affect labelling) has been shown to reduce emotional intensity for some users, and spoken input also provides a richer context for tailoring support.

For Bear Room, we give users a choice to share what’s on their mind via a prominent mic button (with text input available below. The app then analyses their response with AI (does not diagnose) and provides a set of tailored practices to help them cope. This approach gives users a space for the raw, unfiltered expression of emotion when texting feels too heavy.

Similarly, Teeni’s “Hot flow” lets parents vent frustration and describe a difficult trigger via voice. Based on the case description, AI gives a one-screen piece of psychoeducational content, and in a few steps, the app suggests an appropriate calming tool, uniting both emotional and relational support.

By meeting the user at their level of low cognitive capacity and accepting their input in the most accessible form, we build a deeper trust and reinforce the app as a truly adaptive, reliable, and non-judgmental space.

Note: Mental-health topics are highly sensitive, and many people feel uncomfortable sharing sensitive data with an app — especially amid frequent news about data breaches and data being sold to third parties. Before recording, show a concise notice that explains how audio is processed, where it’s processed, how long it’s stored, and that it is not sold or shared with third parties. Present this in a clear, consent step (e.g., GDPR-style). For products handling personal data, it’s also best practice to provide an obvious “Delete all data” option.

Your Toolbox

• Accessibility-Friendly User Flow
  Aim to become your user’s guide. Only use the text that is important, highlight key actions, and provide simple, step-by-step paths.
• Muted Palettes
  There’s no one-size-fits-all colour rule for mental-health apps. Align palette with purpose and audience; if you use muted palettes, verify WCAG 2.2 contrast thresholds and avoid flashing.
• Tactile Micro-interactions
  Use subtle, predictable, opt-in haptics and gentle micro-interactions for moments of kinetic relief.
• Voice-First Design
  Offer voice input as an alternative to typing or single-tap actions in low-energy/high-pressure states
• Subtle Personalisation
  Integrate small, voluntary customisations (like a personal photo in a digital frame) to foster a stronger emotional bond.
• Privacy by Default
  Ask for explicit consent to process personal data. State clearly how, where, and for how long data is processed, and that it’s not sold or shared — and honour it.

A safe interface builds trust in the moment. The final pillar is about earning the trust that brings users back, day after day.

The Retention Engine: Deepening Trust Through Genuine Connection

Encouraging consistent use without manipulation often requires innovative solutions in mental health. The app, as a business, faces an ethical dilemma: its mission is to prioritise user wellbeing, which means it cannot indulge users simply to maximise their screen time. Streaks, points, and time limits can also induce anxiety and shame, negatively affecting the user’s mental health. The goal is not to maximise screen time, but to foster a supportive rhythm of use that aligns with the non-linear journey of mental health.

The Empathy Tool

I replace anxiety-inducing gamification with retention engines powered by empathy. This involves designing loops that intrinsically motivate users through three core pillars: granting them agency with customisable tools, connecting them to a supportive community, and ensuring the app itself acts as a consistent source of support, making return visits feel like a choice, not a chore or pressure. Case: “Key” Economy

In search of reimagining retention mechanics away from punitive streaks and towards a model of compassionate encouragement, the Bear Room team came up with the idea of the so-called “Key” economy. Unlike a streak that shames users for missing a day, users are envisioned to earn “keys” for logging in every third day — a rhythm that acknowledges the non-linear nature of healing and reduces the pressure of daily performance. Keys never gate SOS sets or essential coping practices. Keys only unlock more objects and advanced content; the core toolkit is always free. The app should also preserve users’ progress regardless of their level of engagement.

The system’s most empathetic innovation, however, lies in the ability for users to gift their hard-earned keys to others in the community who may be in greater need (still in the process of making). This intends to transform the act of retention from a self-focused chore into a generous, community-building gesture.

It aims to foster a culture of mutual support, where consistent engagement is not about maintaining a personal score, but about accumulating the capacity to help others.

Why it Works

• It’s Forgiving.
  Unlike a streak, missing a day doesn’t reset progress; it just delays the next key. This removes shame.
• It’s Community-driven.
  Users can give their keys to others. This transforms retention from a selfish act into a generous one, reinforcing the app’s core value of community support.

Case: The Letter Exchange

Within Bear Room, users can write and receive supportive letters anonymously to other users around the world. This tool leverages AI-powered anonymity to create a safe space for radical vulnerability. It provides a real human connection while completely protecting user privacy, directly addressing the trust deficit. It shows users they are not alone in their struggles, a powerful retention driver.

Note: Data privacy is always a priority in product design, but (again) it’s crucial to approach it firsthand in mental health. In the case of the letter exchange, robust anonymity isn’t just a setting; it is the foundational element that creates the safety required for users to be vulnerable and supportive with strangers.

Case: Teenager Translator

The “Teenager Translator” in Teeni became a cornerstone of our retention strategy by directly addressing the moment of crisis where parents were most likely to disengage. When a parent inputs their adolescent’s angry words like “What’s wrong with you? It’s my phone, I will watch what I want, just leave me alone!”, the tool instantly provides an empathetic translation of the emotional subtext, a de-escalation guide, and a practical script for how to respond.

This immediate, actionable support at the peak of frustration transforms the app from a passive resource into an indispensable crisis-management tool. By delivering profound value exactly when and where users need it most, it creates powerful positive reinforcement that builds habit and loyalty, ensuring parents return to the app not just to learn, but to actively navigate their most challenging moments.

Your Toolbox

• Reframe Metrics
  Change “You broke your 7-day streak!” to “You’ve practiced 5 of the last 10 days. Every bit helps.”
• Compassion Access Policy
  Never gate crisis or core coping tools behind paywalls or keys.
• Build Community Safely
  Facilitate anonymous, moderated peer support.
• Offer Choice
  Let users control the frequency and type of reminders.
• Keep an Eye on Reviews
  Monitor app-store reviews and social mentions regularly; tag themes (bugs, UX friction, feature requests), quantify trends, and close the loop with quick fixes or clarifying updates.

Your Empathy-First Launchpad: Three Pillars To Trust

Let’s return to the overwhelmed user from the introduction. They open an app that greets them with a tested, audience-aligned visual language, a validating first message, and a retention system that supports rather than punishes.

This is the power of an Empathy-Centred UX Framework. It forces us to move beyond pixels and workflows to the heart of the user experience: emotional safety. But to embed this philosophy in design processes, we need a structured, scalable approach. My designer path led me to the following three core pillars:

1. The Onboarding Conversation
   Start by transforming the initial setup from a functional checklist into the first supportive, therapy-informed dialogue. This pillar is rooted in using validating language, keeping asking “why” to understand deeper needs, and prioritising brevity and respect to make the user feel seen and understood from their very first interactions.
2. The Emotional Interface
   Adjust the design to a low-stimulus digital environment for a brain in distress. This pillar focuses on the visual and interactive tools: muted palettes, calming micro-interactions, voice-first features, and personalisation, to make sure a user enters a calm, predictable, and safe digital environment. Certainly, these tools are not limited to the ones I applied throughout my experience, and there is always room for creativity, keeping in mind users’ preferences and scientific research.
3. The Retention Engine
   Be persistent in upholding genuine connection over manipulative gamification. This pillar focuses on building lasting engagement through forgiving systems (like the “Key” economy), community-driven support (like letter exchanges), and tools that offer profound value in moments of crisis (like the Teenager Translator). When creating such tools, aim for a supportive rhythm of use that aligns with the non-linear journey of mental health.

Trust Is The Success: Balancing Game

While we, as designers, don’t directly define the app’s success metrics, we cannot deny that our work influences the final outcomes. This is where our practical tools in mental health apps may come in partnership with the product owner’s goals. All the tools are designed based on hypotheses, evaluations of whether users need them, further testing, and metric analysis.

I would argue that one of the most critical success components for a mental health app is trust. Although it is not easy to measure, our role as designers lies precisely in creating a UX Framework that respects and listens to its users and makes the app fully accessible and inclusive.

The trick is to achieve a sustainable balance between helping users reach their wellness goals and the gaming effect, so they also benefit from the process and atmosphere. It is a blend of enjoyment from the process and fulfillment from the health benefits, where we want to make a routine meditation exercise something pleasant. Our role as product designers is to always keep in mind that the end goal for the user is to achieve a positive psychological effect, not to remain in a perpetual gaming loop.

Of course, we need to keep in mind that the more responsibility the app takes for its users’ health, the more requirements there arise for its design.

When this balance is struck, the result is more than just better metrics; it’s a profound positive impact on your users’ lives. In the end, empowering a user’s well-being is the highest achievement our craft can aspire to.

In the first part of this series, we established the fundamental shift from generative to agentic artificial intelligence. We explored why this leap from suggesting to acting demands a new psychological and methodological toolkit for UX researchers, product managers, and leaders. We defined a taxonomy of agentic behaviors, from suggesting to acting autonomously, outlined the essential research methods, defined the risks of agentic sludge, and established the accountability metrics required to navigate this new territory. We covered the what and the why.

Now, we move from the foundational to the functional. This article provides the how: the concrete design patterns, operational frameworks, and organizational practices essential for building agentic systems that are not only powerful but also transparent, controllable, and worthy of user trust. If our research is the diagnostic tool, these patterns are the treatment plan. They are the practical mechanisms through which we can give users a palpable sense of control, even as we grant AI unprecedented autonomy. The goal is to create an experience where autonomy feels like a privilege granted by the user, not a right seized by the system.

Core UX Patterns For Agentic Systems

Designing for agentic AI is designing for a relationship. This relationship, like any successful partnership, must be built on clear communication, mutual understanding, and established boundaries.

To manage the shift from suggestion to action, we utilize six patterns that follow the functional lifecycle of an agentic interaction:

• Pre-Action (Establishing Intent)
  The Intent Preview and Autonomy Dial ensure the user defines the plan and the agent’s boundaries before anything happens.
• In-Action (Providing Context)
  The Explainable Rationale and Confidence Signal maintain transparency while the agent works, showing the “why” and “how certain.”
• Post-Action (Safety and Recovery)
  The Action Audit & Undo and Escalation Pathway provide a safety net for errors or high-ambiguity moments.

Below, we will cover each pattern in detail, including recommendations for metrics for success. These targets are representative benchmarks based on industry standards; adjust them based on your specific domain risk.

1. The Intent Preview: Clarifying the What and How

This pattern is the conversational equivalent of saying, “Here’s what I’m about to do. Are you okay with that?” It’s the foundational moment of seeking consent in the user-agent relationship.

Before an agent takes any significant action, the user must have a clear, unambiguous understanding of what is about to happen. The Intent Preview, or Plan Summary, establishes informed consent. It is the conversational pause before action, transforming a black box of autonomous processes into a transparent, reviewable plan.

Psychological Underpinning
Presenting a plan before action reduces cognitive load and eliminates surprise, giving users a moment to verify the agent truly understands their intent.

Anatomy of an Effective Intent Preview:

• Clarity and Conciseness
  The preview must be immediately digestible. It should summarize the primary actions and outcomes in plain language, avoiding technical jargon. For instance, instead of “Executing API call to cancel_booking(id: 4A7B),” it should state, “Cancel flight AA123 to San Francisco.”
• Sequential Steps
  For multi-step operations, the preview should outline the key phases. This reveals the agent’s logic and allows users to spot potential issues in the proposed sequence.
• Clear User Actions
  The preview is a decision point, not just a notification. It must be accompanied by a clear set of choices. It’s a moment of intentional friction, a ‘speed bump’ in the process designed to ensure the user is making a conscious choice, particularly for irreversible or high-stakes actions.

Let’s revisit our travel assistant scenario from the first part of this series. We use this proactive assistant to illustrate how an agent handles a flight cancellation. The agent has detected a flight cancellation and has formulated a recovery plan.

The Intent Preview would look something like this:

Proposed Plan for Your Trip Disruption

I’ve detected that your 10:05 AM flight has been canceled. Here’s what I plan to do:

1. Cancel Flight UA456
   Process refund and confirm cancellation details.
2. Rebook on Flight DL789
   Book a confirmed seat on a 2:30 PM non-stop flight, as this is the next available non-stop flight with a confirmed seat.
3. Update Hotel Reservation
   Notify the Marriott that you will be arriving late.
4. Email Updated Itinerary
   Send the new flight and hotel details to you and your assistant, Jane Doe.

[ Proceed with this Plan ] [ Edit Plan ] [ Handle it Myself ]

This preview is effective because it provides a complete picture, from cancellation to communication, and offers three distinct paths forward: full consent (Proceed), a desire for modification (Edit Plan), or a full override (Handle it Myself). This multifaceted control is the bedrock of trust.

When to Prioritize This Pattern
This pattern is non-negotiable for any action that is irreversible (e.g., deleting user data), involves a financial transaction of any amount, shares information with other people or systems, or makes a significant change that a user cannot easily undo.

Risk of Omission
Without this, users feel ambushed by the agent’s actions and will disable the feature to regain control.

Metrics for Success:

• Acceptance Ratio
  Plans Accepted Without Edit / Total Plans Displayed. Target > 85%.
• Override Frequency
  Total Handle it Myself Clicks / Total Plans Displayed. A rate > 10% triggers a model review.
• Recall Accuracy
  Percentage of test participants who can correctly list the plan’s steps 10 seconds after the preview is hidden.

Applying This to High-Stakes Domains

While travel plans are a relatable baseline, this pattern becomes indispensable in complex, high-stakes environments where an error results in more than an inconvenience for an individual traveling. Many of us work in settings where wrong decisions may result in a system outage, putting a patient’s safety at risk, or numerous other catastrophic outcomes that unreliable technology would introduce.

Consider a DevOps Release Agent tasked with managing cloud infrastructure. In this context, the Intent Preview acts as a safety barrier against accidental downtime.

In this interface, the specific terminology (Drain Traffic, Rollback) replaces generalities, and the actions are binary and impactful. The user authorizes a major operational shift based on the agent’s logic, rather than approving a suggestion.

2. The Autonomy Dial: Calibrating Trust With Progressive Authorization

Every healthy relationship has boundaries. The Autonomy Dial is how the user establishes it with their agent, defining what they are comfortable with the agent handling on its own.

Trust is not a binary switch; it’s a spectrum. A user might trust an agent to handle low-stakes tasks autonomously but demand full confirmation for high-stakes decisions. The Autonomy Dial, a form of progressive authorization, allows users to set their preferred level of agent independence, making them active participants in defining the relationship.

Psychological Underpinning
Allowing users to tune the agent’s autonomy grants them a locus of control, letting them match the system’s behavior to their personal risk tolerance.

Implementation
This can be implemented as a simple, clear setting within the application, ideally on a per-task-type basis. Using the taxonomy from our first article, the settings could be:

• Observe & Suggest
  I want to be notified of opportunities or issues, but the agent will never propose a plan.
• Plan & Propose
  The agent can create plans, but I must review every one before any action is taken.
• Act with Confirmation
  For familiar tasks, the agent can prepare actions, and I will give a final go/no-go confirmation.
• Act Autonomously
  For pre-approved tasks (e.g., disputing charges under $50), the agent can act independently and notify me after the fact.

An email assistant, for example, could have a separate autonomy dial for scheduling meetings versus sending emails on the user’s behalf. This granularity is key, as it reflects the nuanced reality of a user’s trust.

When to Prioritize This Pattern
Prioritize this in systems where tasks vary widely in risk and personal preference (e.g., financial management tools, communication platforms). It is essential for onboarding, allowing users to start with low autonomy and increase it as their confidence grows.

Risk of Omission
Without this, users who experience a single failure will abandon the agent completely rather than simply dialing back its permissions.

Metrics for Success:

• Trust Density
  Percentage breakdown of users per setting (e.g., 20% Suggest, 50% Confirm, 30% Auto).
• Setting Churn
  Number of Setting Changes / Total Active Users per month. High churn indicates trust volatility.

3. The Explainable Rationale: Answering Why?

After taking an action, a good partner explains their reasoning. This pattern is the open communication that follows an action, answering Why? before it’s even asked. “I did that because you’ve told me in the past that you prefer X.”

When an agent acts, especially autonomously, the immediate question in the user’s mind is often, Why did it do that? The Explainable Rationale pattern proactively answers this question, providing a concise justification for the agent’s decisions. This is not a technical log file. In my first article of this series, we discussed translating system primitives into user-facing language to prevent deception. This pattern is the practical application of that principle. It transforms the raw logic into a human-readable explanation grounded in the user’s own stated preferences and prior inputs.

Psychological Underpinning
When an agent’s actions are explainable, they feel logical rather than random, helping the user build an accurate mental model of how the agent thinks.

Effective Rationales:

• Grounded in Precedent
  The best explanations link back to a rule, preference, or prior action.
• Simple and Direct
  Avoid complex conditional logic. Use a simple “Because you said X, I did Y” structure.

Returning to the travel example, after the flight is rebooked autonomously, the user might see this in their notification feed:

I’ve rebooked your canceled flight.

• New Flight: Delta 789, departing at 2:30 PM.
• Why I took this action:
  • Your original flight was canceled by the airline.
  • You’ve pre-approved autonomous rebooking for same-day, non-stop flights.

[ View New Itinerary ] [ Undo this Action ]

The rationale is clear, defensible, and reinforces the idea that the agent is operating within the boundaries the user established.

When to Prioritize This Pattern
Prioritize it for any autonomous action where the reasoning isn’t immediately obvious from the context, especially for actions that happen in the background or are triggered by an external event (like the flight cancellation example).

Risk of Omission
Without this, users interpret valid autonomous actions as random behavior or ‘bugs,’ preventing them from forming a correct mental model.

Metrics for Success:

• Why? Ticket Volume
  Number of support tickets tagged “Agent Behavior — Unclear” per 1,000 active users.
• Rationale Validation
  Percentage of users who rate the explanation as ‘Helpful’ in post-interaction microsurveys.

4. The Confidence Signal

This pattern is about the agent being self-aware in the relationship. By communicating its own confidence, it helps the user decide when to trust its judgment and when to apply more scrutiny.

To help users calibrate their own trust, the agent should surface its own confidence in its plans and actions. This makes the agent’s internal state more legible and helps the user decide when to scrutinize a decision more closely.

Psychological Underpinning
Surfacing uncertainty helps prevent automation bias, encouraging users to scrutinize low-confidence plans rather than blindly accepting them.

Implementation:

• Confidence Score
  A simple percentage (e.g., Confidence: 95%) can be a quick, scannable indicator.
• Scope Declaration
  A clear statement of the agent’s area of expertise (e.g., Scope: Travel bookings only) helps manage user expectations and prevents them from asking the agent to perform tasks it’s not designed for.
• Visual Cues
  A green checkmark can denote high confidence, while a yellow question mark can indicate uncertainty, prompting the user to review more carefully.

When to Prioritize This Pattern
Prioritize when the agent’s performance can vary significantly based on the quality of input data or the ambiguity of the task. It is especially valuable in expert systems (e.g., medical aids, code assistants) where a human must critically evaluate the AI’s output.

Risk of Omission
Without this, users will fall victim to automation bias, blindly accepting low-confidence hallucinations, or anxiously double-check high-confidence work.

Metrics for Success:

• Calibration Score
  Pearson correlation between Model Confidence Score and User Acceptance Rate. Target > 0.8.
• Scrutiny Delta
  Difference between the average review time of low-confidence plans and high-confidence plans. Expected to be positive (e.g., +12 seconds).

5. The Action Audit & Undo: The Ultimate Safety Net

Trust requires knowing you can recover from a mistake. The Undo function is the ultimate relationship safety net, assuring the user that even if the agent misunderstands, the consequences are not catastrophic.

The single most powerful mechanism for building user confidence is the ability to easily reverse an agent’s action. A persistent, easy-to-read Action Audit log, with a prominent Undo button for every possible action, is the ultimate safety net. It dramatically lowers the perceived risk of granting autonomy.

Psychological Underpinning
Knowing that a mistake can be easily undone creates psychological safety, encouraging users to delegate tasks without fear of irreversible consequences.

Design Best Practices:

• Timeline View
  A chronological log of all agent-initiated actions is the most intuitive format.
• Clear Status Indicators
  Show whether an action was successful, is in progress, or has been undone.
• Time-Limited Undos
  For actions that become irreversible after a certain point (e.g., a non-refundable booking), the UI must clearly communicate this time window (e.g., Undo available for 15 minutes). This transparency about the system’s limitations is just as important as the undo capability itself. Being honest about when an action becomes permanent builds trust.

When to Prioritize This Pattern
This is a foundational pattern that should be implemented in nearly all agentic systems. It is absolutely non-negotiable when introducing autonomous features or when the cost of an error (financial, social, or data-related) is high.

Risk of Omission
Without this, one error permanently destroys trust, as users realize they have no safety net.

Metrics for Success:

• Reversion Rate
  Undone Actions / Total Actions Performed. If the Reversion Rate > 5% for a specific task, disable automation for that task.
• Safety Net Conversion
  Percentage of users who upgrade to Act Autonomously within 7 days of successfully using Undo.

6. The Escalation Pathway: Handling Uncertainty Gracefully

A smart partner knows when to ask for help instead of guessing. This pattern allows the agent to handle ambiguity gracefully by escalating to the user, demonstrating a humility that builds, rather than erodes, trust.

Even the most advanced agent will encounter situations where it is uncertain about the user’s intent or the best course of action. How it handles this uncertainty is a defining moment. A well-designed agent doesn’t guess; it escalates.

Psychological Underpinning
When an agent acknowledges its limits rather than guessing, it builds trust by respecting the user’s authority in ambiguous situations.

Escalation Patterns Include:

• Requesting Clarification
  “You mentioned ‘next Tuesday.’ Do you mean September 30th or October 7th?”
• Presenting Options
  “I found three flights that match your criteria. Which one looks best to you?”
• Requesting Human Intervention
  For high-stakes or highly ambiguous tasks, the agent should have a clear pathway to loop in a human expert or support agent. The prompt might be: “This transaction seems unusual, and I’m not confident about how to proceed. Would you like me to flag this for a human agent to review?”

When to Prioritize This Pattern
Prioritize in domains where user intent can be ambiguous or highly context-dependent (e.g., natural language interactions, complex data queries). Use this whenever the agent operates with incomplete information or when multiple correct paths exist.

Risk of Omission
Without this, the agent will eventually make a confident, catastrophic guess that alienates the user.

Metrics for Success:

• Escalation Frequency
  Agent Requests for Help / Total Tasks. Healthy range: 5-15%.
• Recovery Success Rate
  Tasks Completed Post-Escalation / Total Escalations. Target > 90%.

Pattern Best For Primary Risk Key Metric Intent Preview Irreversible or financial actions User feels ambushed >85% Acceptance Rate Autonomy Dial Tasks with variable risk levels Total feature abandonment Setting Churn Explainable Rationale Background or autonomous tasks User perceives bugs “Why?” Ticket Volume Confidence Signal Expert or high-stakes systems Automation bias Scrutiny Delta Action Audit & Undo All agentic systems Permanent loss of trust <5% Reversion Rate Escalation Pathway Ambiguous user intent Confident, catastrophic guesses >90% Recovery Success

Table 1: Summary of Agentic AI UX patterns. Remember to adjust the metrics based on your specific domain risk and needs.

Designing for Repair and Redress

This is learning how to apologize effectively. A good apology acknowledges the mistake, fixes the damage, and promises to learn from it.

Errors are not a possibility; they are an inevitability.

The long-term success of an agentic system depends less on its ability to be perfect and more on its ability to recover gracefully when it fails. A robust framework for repair and redress is a core feature, not an afterthought.

Empathic Apologies and Clear Remediation

When an agent makes a mistake, the error message is the apology. It must be designed with psychological precision. This moment is a critical opportunity to demonstrate accountability. From a service design perspective, this is where companies can use the service recovery paradox: the phenomenon where a customer who experiences a service failure, followed by a successful and empathetic recovery, can actually become more loyal than a customer who never experienced a failure at all. A well-handled mistake can be a more powerful trust-building event than a long history of flawless execution.

The key is treating the error as a relationship rupture that needs to be mended. This involves:

• Acknowledge the Error
  The message should state clearly and simply that a mistake was made.
  Example: I incorrectly transferred funds.
• State the Immediate Correction
  Immediately follow up with the remedial action.
  Example: I have reversed the action, and the funds have been returned to your account.
• Provide a Path for Further Help
  Always offer a clear link to human support. This de-escalates frustration and shows that there is a system of accountability beyond the agent itself.

A well-designed repair UI might look like this:

We made a mistake on your recent transfer.
I apologize. I transferred $250 to the wrong account.

✔ Corrective Action: The transfer has been reversed, and your $250 has been refunded.
✔ Next Steps: The incident has been flagged for internal review to prevent it from happening again.

Need further help? [ Contact Support ] Building the Governance Engine for Safe Innovation

The design patterns described above are the user-facing controls, but they cannot function effectively without a robust internal support structure. This is not about creating bureaucratic hurdles; it is about building a strategic advantage. An organization with a mature governance framework can ship more ambitious agentic features with greater speed and confidence, knowing that the necessary guardrails are in place to mitigate brand risk. This governance engine turns safety from a checklist into a competitive asset.

This engine should function as a formal governance body, an Agentic AI Ethics Council, comprising a cross-functional alliance of UX, Product, and Engineering, with vital support from Legal, Compliance, and Support. In smaller organizations, these ‘Council’ roles often collapse into a single triad of Product, Engineering, and Design leads.

A Checklist for Governance

• Legal/Compliance
  This team is the first line of defense, ensuring the agent’s potential actions stay within regulatory and legal boundaries. They help define the hard no-go zones for autonomous action.
• Product
  The product manager is the steward of the agent’s purpose. They define and monitor its operational boundaries through a formal autonomy policy that documents what the agent is and is not allowed to do. They own the Agent Risk Register.
• UX Research
  This team is the voice of the user’s trust and anxiety. They are responsible for a recurring process for running trust calibration studies, simulated misbehavior tests, and qualitative interviews to understand the user’s evolving mental model of the agent.
• Engineering
  This team builds the technical underpinnings of trust. They must architect the system for robust logging, one-click undo functionality, and the hooks needed to generate clear, explainable rationales.
• Support
  These teams are on the front lines of failure. They must be trained and equipped to handle incidents caused by agent errors, and they must have a direct feedback loop to the Ethics Council to report on real-world failure patterns.

This governance structure should maintain a set of living documents, including an Agent Risk Register that proactively identifies potential failure modes, Action Audit Logs that are regularly reviewed, and the formal Autonomy Policy Documentation.

Where to Start: A Phased Approach for Product Leaders

For product managers and executives, integrating agentic AI can feel like a monumental task. The key is to approach it not as a single launch, but as a phased journey of building both technical capability and user trust in parallel. This roadmap allows your organization to learn and adapt, ensuring each step is built on a solid foundation.

Phase 1: Foundational Safety (Suggest & Propose)

The initial goal is to build the bedrock of trust without taking significant autonomous risks. In this phase, the agent’s power is limited to analysis and suggestion.

• Implement a rock-solid Intent Preview: This is your core interaction model. Get users comfortable with the idea of the agent formulating plans, while keeping the user in full control of execution.
• Build the Action Audit & Undo infrastructure: Even if the agent isn’t acting autonomously yet, build the technical scaffolding for logging and reversal. This prepares your system for the future and builds user confidence that a safety net exists.

Phase 2: Calibrated Autonomy (Act with Confirmation)

Once users are comfortable with the agent’s proposals, you can begin to introduce low-risk autonomy. This phase is about teaching users how the agent thinks and letting them set their own pace.

• Introduce the Autonomy Dial with limited settings: Start by allowing users to grant the agent the power to Act with Confirmation.
• Deploy the Explainable Rationale: For every action the agent prepares, provide a clear explanation. This demystifies the agent’s logic and reinforces that it is operating based on the user’s own preferences.

Phase 3: Proactive Delegation (Act Autonomously)

This is the final step, taken only after you have clear data from the previous phases demonstrating that users trust the system.

• Enable Act Autonomously for specific, pre-approved tasks: Use the data from Phase 2 (e.g., high Proceed rates, low Undo rates) to identify the first set of low-risk tasks that can be fully automated.
• Monitor and Iterate: The launch of autonomous features is not the end, but the beginning of a continuous cycle of monitoring performance, gathering user feedback, and refining the agent’s scope and behavior based on real-world data.

Design As The Ultimate Safety Lever

The emergence of agentic AI represents a new frontier in human-computer interaction. It promises a future where technology can proactively reduce our burdens and streamline our lives. But this power comes with profound responsibility.

Autonomy is an output of a technical system, but trustworthiness is an output of a design process. Our challenge is to ensure that the user experience is not a casualty of technical capability but its primary beneficiary.

As UX professionals, product managers, and leaders, our role is to act as the stewards of that trust. By implementing clear design patterns for control and consent, designing thoughtful pathways for repair, and building robust governance frameworks, we create the essential safety levers that make agentic AI viable. We are not just designing interfaces; we are architecting relationships. The future of AI’s utility and acceptance rests on our ability to design these complex systems with wisdom, foresight, and a deep-seated respect for the user’s ultimate authority.

When learning the principles of basic CSS, one is taught to write modular, reusable, and descriptive styles to ensure maintainability. But when developers become involved with real-world applications, it often feels impossible to add UI features without styles leaking into unintended areas.

This issue often snowballs into a self-fulfilling loop; styles that are theoretically scoped to one element or class start showing up where they don’t belong. This forces the developer to create even more specific selectors to override the leaked styles, which then accidentally override global styles, and so on.

Rigid class name conventions, such as BEM, are one theoretical solution to this issue. The BEM (Block, Element, Modifier) methodology is a systematic way of naming CSS classes to ensure reusability and structure within CSS files. Naming conventions like this can reduce cognitive load by leveraging domain language to describe elements and their state, and if implemented correctly, can make styles for large applications easier to maintain.

In the real world, however, it doesn’t always work out like that. Priorities can change, and with change, implementation becomes inconsistent. Small changes to the HTML structure can require many CSS class name revisions. With highly interactive front-end applications, class names following the BEM pattern can become long and unwieldy (e.g., app-user-overview__status--is-authenticating), and not fully adhering to the naming rules breaks the system’s structure, thereby negating its benefits.

Given these challenges, it’s no wonder that developers have turned to frameworks, Tailwind being the most popular CSS framework. Rather than trying to fight what seems like an unwinnable specificity war between styles, it is easier to give up on the CSS Cascade and use tools that guarantee complete isolation.

Developers Lean More On Utilities

How do we know that some developers are keen on avoiding cascaded styles? It’s the rise of “modern” front-end tooling — like CSS-in-JS frameworks — designed specifically for that purpose. Working with isolated styles that are tightly scoped to specific components can seem like a breath of fresh air. It removes the need to name things — still one of the most hated and time-consuming front-end tasks — and allows developers to be productive without fully understanding or leveraging the benefits of CSS inheritance.

But ditching the CSS Cascade comes with its own problems. For instance, composing styles in JavaScript requires heavy build configurations and often leads to styles awkwardly intermingling with component markup or HTML. Instead of carefully considered naming conventions, we allow build tools to autogenerate selectors and identifiers for us (e.g., .jsx-3130221066), requiring developers to keep up with yet another pseudo-language in and of itself. (As if the cognitive load of understanding what all your component’s useEffects do weren’t already enough!)

Further abstracting the job of naming classes to tooling means that basic debugging is often constrained to specific application versions compiled for development, rather than leveraging native browser features that support live debugging, such as Developer Tools.

It’s almost like we need to develop tools to debug the tools we’re using to abstract what the web already provides — all for the sake of running away from the “pain” of writing standard CSS.

Luckily, modern CSS features not only make writing standard CSS more flexible but also give developers like us a great deal more power to manage the cascade and make it work for us. CSS Cascade Layers are a great example, but there’s another feature that gets a surprising lack of attention — although that is changing now that it has recently become Baseline compatible.

The CSS @scope At-Rule

I consider the CSS @scope at-rule to be a potential cure for the sort of style-leak-induced anxiety we’ve covered, one that does not force us to compromise native web advantages for abstractions and extra build tooling.

“The @scope CSS at-rule enables you to select elements in specific DOM subtrees, targeting elements precisely without writing overly-specific selectors that are hard to override, and without coupling your selectors too tightly to the DOM structure.”

— MDN

In other words, we can work with isolated styles in specific instances without sacrificing inheritance, cascading, or even the basic separation of concerns that has been a long-running guiding principle of front-end development.

Plus, it has excellent browser coverage. In fact, Firefox 146 added support for @scope in December, making it Baseline compatible for the first time. Here is a simple comparison between a button using the BEM pattern versus the @scope rule:

<!-- BEM --> <button class="button button--primary"> <span class="button__text">Click me</span> <span class="button__icon">→</span> </button> <style> .button .button__text { /* button text styles */ } .button .button__icon { /* button icon styles */ } .button--primary { primary button styles */ } </style> <!-- @scope --> <button class="primary-button"> <span>Click me</span> <span>→</span> </button> <style> @scope (.primary-button) { span:first-child { /* button text styles */ } span:last-child { /* button icon styles */ } } </style>

The @scope rule allows for precision with less complexity. The developer no longer needs to create boundaries using class names, which, in turn, allows them to write selectors based on native HTML elements, thereby eliminating the need for prescriptive CSS class name patterns. By simply removing the need for class name management, @scope can alleviate the fear associated with CSS in large projects.

Basic Usage

To get started, add the @scope rule to your CSS and insert a root selector to which styles will be scoped:

@scope (<selector>) { /* Styles scoped to the <selector> */ }

So, for example, if we were to scope styles to a <nav> element, it may look something like this:

@scope (nav) { a { /* Link styles within nav scope */ } a:active { /* Active link styles */ } a:active::before { /* Active link with pseudo-element for extra styling */ } @media (max-width: 768px) { a { /* Responsive adjustments */ } } }

This, on its own, is not a groundbreaking feature. However, a second argument can be added to the scope to create a lower boundary, effectively defining the scope’s start and end points.

/* Any a element inside ul will not have the styles applied */ @scope (nav) to (ul) { a { font-size: 14px; } }

This practice is called donut scoping, and there are several approaches one could use, including a series of similar, highly specific selectors coupled tightly to the DOM structure, a :not pseudo-selector, or assigning specific class names to <a> elements within the <nav> to handle the differing CSS.

Regardless of those other approaches, the @scope method is much more concise. More importantly, it prevents the risk of broken styles if classnames change or are misused or if the HTML structure were to be modified. Now that @scope is Baseline compatible, we no longer need workarounds!

We can take this idea further with multiple end boundaries to create a “style figure eight”:

/* Any <a> or <p> element inside <aside> or <nav> will not have the styles applied */ @scope (main) to (aside, nav) { a { font-size: 14px; } p { line-height: 16px; color: darkgrey; } }

Compare that to a version handled without the @scope rule, where the developer has to “reset” styles to their defaults:

main a { font-size: 14px; } main p { line-height: 16px; color: darkgrey; } main aside a, main nav a { font-size: inherit; /* or whatever the default should be */ } main aside p, main nav p { line-height: inherit; /* or whatever the default should be */ color: inherit; /* or a specific color */ }

Check out the following example. Do you notice how simple it is to target some nested selectors while exempting others?

See the Pen @scope example [forked] by Blake Lundquist.

Consider a scenario where unique styles need to be applied to slotted content within web components. When slotting content into a web component, that content becomes part of the Shadow DOM, but still inherits styles from the parent document. The developer might want to implement different styles depending on which web component the content is slotted into:

<!-- Same <user-card> content, different contexts --> <product-showcase> <user-card slot="reviewer"> <img src="avatar.jpg" slot="avatar"> <span slot="name">Jane Doe</span> </user-card> </product-showcase> <team-roster> <user-card slot="member"> <img src="avatar.jpg" slot="avatar"> <span slot="name">Jane Doe</span> </user-card> </team-roster>

In this example, the developer might want the <user-card> to have distinct styles only if it is rendered inside <team-roster>:

@scope (team-roster) { user-card { display: inline-flex; align-items: center; gap: 0.5rem; } user-card img { border-radius: 50%; width: 40px; height: 40px; } } More Benefits

There are additional ways that @scope can remove the need for class management without resorting to utilities or JavaScript-generated class names. For example, @scope opens up the possibility to easily target descendants of any selector, not just class names:

/* Only div elements with a direct child button are included in the root scope */ @scope (div:has(> button)) { p { font-size: 14px; } }

And they can be nested, creating scopes within scopes:

@scope (main) { p { font-size: 16px; color: black; } @scope (section) { p { font-size: 14px; color: blue; } @scope (.highlight) { p { background-color: yellow; font-weight: bold; } } } }

Plus, the root scope can be easily referenced within the @scope rule:

/* Applies to elements inside direct child section elements of main, but stops at any direct aside that is a direct chiled of those sections */ @scope (main > section) to (:scope > aside) { p { background-color: lightblue; color: blue; } /* Applies to ul elements that are immediate siblings of root scope */ :scope + ul { list-style: none; } }

The @scope at-rule also introduces a new proximity dimension to CSS specificity resolution. In traditional CSS, when two selectors match the same element, the selector with the higher specificity wins. With @scope, when two elements have equal specificity, the one whose scope root is closer to the matched element wins. This eliminates the need to override parent styles by manually increasing an element’s specificity, since inner components naturally supersede outer element styles.

<style> @scope (.container) { .title { color: green; } } <!-- The <h2> is closer to .container than to .sidebar so "color: green" wins. --> @scope (.sidebar) { .title { color: red; } } </style> <div class="sidebar"> <div class="container"> <h2 class="title">Hello</h2> </div> </div> Conclusion

Utility-first CSS frameworks, such as Tailwind, work well for prototyping and smaller projects. Their benefits quickly diminish, however, when used in larger projects involving more than a couple of developers.

Front-end development has become increasingly overcomplicated in the last few years, and CSS is no exception. While the @scope rule isn’t a cure-all, it can reduce the need for complex tooling. When used in place of, or alongside strategic class naming, @scope can make it easier and more fun to write maintainable CSS.

Further Reading

• CSS @scope (MDN)
• “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks)
• Firefox 146 Release Notes (Firefox)
• Browser Support (CanIUse)
• Popular CSS Frameworks (State of CSS 2024)
• “The “C” in CSS: Cascade”, Thomas Yip (CSS-Tricks)
• BEM Introduction (Get BEM)