Designing For Distressed Users: Why Mental Health Apps Shouldn’t Follow Every UI Fashion

 

Many UI trends are designed to capture attention and signal innovation, but those goals often conflict with the needs of mental health apps: reducing cognitive strain, fostering trust, and providing a sense of refuge. Here it introduces an evaluation framework that helps designers assess whether trendy visual and interaction patterns support or undermine the unique goals of mental health experiences.

Mental health applications keep facing a continuing, measurable crisis: many people stop using them quickly. The data is stark: almost 95% of users who open the app on day 1 abandon the app by day 30, with a median 30-day retention of only 3.3%. Even the recognised mental health giants lose around 50% of their users within the first ten days. This severe engagement loss and retention collapse are why effective interface design must be a clinical and operational priority. Good design is not merely aesthetic; it is a fundamental tool for user retention.

While many factors drive this abandonment, research suggests that mental health apps have tended to prioritise visual appeal at the expense of what actually sustains users. In a space defined by vulnerability and cognitive strain, chasing visual fashion risks adding effort when users have the least to spare — quietly trading away the utility and trust the app depends on. Users don’t open mental health apps out of curiosity, but from need — often while stressed, anxious, overwhelmed, or exhausted. In these states, an unconventional icon, a confusing gesture, or a flashy animation instead of a delightful surprise becomes an extra cognitive overload. Moreover, it becomes a reason to disengage.

In those moments, visual experimentation from a mild distraction can turn into a friction that undermines the very help the app is meant to deliver. A solution must be a visual interface that is simple in usage and understanding from the first moment.

Crucially, improving engagement depends less on which UI trends you follow than on a single test applied to each one of them: does a trend lower the cost of using the app when the user can least afford it?

“

The High Cost Of Trend-driven Design In Mental Health

Before we look into the specific problems, we must recognise a core tension: many UI trends are optimised for goals that mental health apps don’t share.

Trend design is often about capturing attention and signaling innovation. Mental health design, in contrast, must be about offering refuge, reducing strain, and building trust.

(Large preview)

Pursuing the former directly overrides the latter. It’s not a surface-level error of colour or font; it’s a foundational conflict of purpose. This tension surfaces across five fronts, each a place where adopting a trend on novelty alone can cost more engagement than it seeks to create.

The proposed principles are not based on a single A/B test or one isolated study. They are built from published research on mental health app engagement, cognitive load, accessibility, and emotional response in mHealth, set against competitive product audits and app-store evidence, and pressure-tested against my own quantitative and qualitative product work. That last source I treat as an illustration, understanding the limits of personal experience. In this context, validation is less about proving that one interface pattern universally works and more about asking whether a design reduces effort, preserves agency, avoids emotional mismatch, and remains usable when the user is already under strain.

“Distressed user” here refers not to a diagnosis, but to a reduced-capacity state in which everyday tasks, choices, and self-care can require more effort than usual.

A note on the examples: This isn’t a ranking of apps. Every app has its own positioning, target audience, constraints, and business pressures that may not be visible from outside, and a pattern that strains a user in distress may be exactly right for that product’s actual goal. I’m reading individual, visible design decisions for one question only: how they might affect someone arriving in a low-capacity state.

1. Cognitive Friction: When Design Becomes A Barrier To Healing

The primary goal of any mental health tool is to reduce, not increase, cognitive load. Yet, many trendy interfaces achieve the opposite. Neo-brutalist layouts with stark contrasts demand visual parsing. Hidden navigation menus that rely on non-standard swipes turn simple tasks into puzzles. Abstract, unlabeled icons force users to guess rather than recognise. Each of these patterns adds friction — seconds of hesitation, a moment of confusion — and for a user whose mental energy is already low, those costs start to accumulate.

Abstract controls can add interpretation effort, even in otherwise polished wellbeing interfaces. 

This friction is most damaging during acute need. Research suggests that when a user is in a state of high anxiety or depression, even typing or making simple choices can feel overwhelming. When an interface demands high cognitive effort at the moment support is needed, it doesn’t just make that session harder — it gives an overwhelmed user a reason to close the app, and a reason not to reopen it. Each point of confusion can become a place where a user may quit for good.

Other findings show that apps with simple interfaces reduce the time and effort required to engage, directly improving retention. Conversely, a complex, trend-driven UI increases that time, creating an obstacle course that undermines the very healthy habit formation the app is meant to support.

This does not mean that every mental health product must be visually plain or minimal. The issue is whether the interface meets the user’s current capacity.

A panic-support tool, for example, works best when it offers a small number of obvious actions, rather than asking the user to browse. However, if a calming action meant for a moment of panic instead surfaces an upgrade screen, the product fails the user at precisely the point where failing matters most. Monetization is not the issue by itself; the issue is whether it appears at a point where the user expects immediate support.

A clear panic entry point lowers cognitive load; surprise paywalls inside support actions can reintroduce friction.

Nonori shows the same principle in a more reflective context. The app does not present the user with a large content library or a complex dashboard at the start. Instead, it leads them through a simple, linear sequence of small actions. The value of this pattern is that it reduces the effort needed to begin. When a user is tired, anxious, or mentally overloaded, knowing exactly what to do next can lower the barrier to returning.

A linear flow reduces the need to decide what to do next.

At the other end of the spectrum, comprehensive tracking apps show a different trade-off. Bearable, for example, is genuinely powerful: it consolidates almost everything a person tracks — mood, symptoms, sleep, medication, habits, reports, correlations — into one place. For users managing chronic conditions or preparing for medical appointments, this can be genuinely useful. But the same comprehensiveness can become a burden for an exhausted user. Dense dashboards and multi-step check-ins require executive capacity — the very resource that anxiety, depression, burnout, or brain fog often reduce.

Comprehensive tracking can be valuable, but dense check-ins require executive capacity.

A similar tension appears in anxiety apps with strong support content but busy entry points. A product may contain useful features yet still make the first screen feel noisy with too many cards, locked items, playful characters, or upgrade prompts. This is not evidence that the product is bad. It shows how the same interface can feel very different depending on the user’s state: clear enough during exploration, but too demanding during distress.

In low-capacity states, visually rich home screens can make the path to support harder to find.

This insight shaped a guiding principle for our work: every interaction point must meet users at their current level of capacity, removing mechanical and cognitive barriers rather than adding to them. This principle guided our integration of low-friction, state-aware interactions in apps like Bear Room, a stress and anxiety reduction app, and Teeni, an emotional-wellbeing app for parents of teens.

In Bear Room, we already had a fast mood-based flow built around four emotion cards. At the same time, our product research supported a second need: users also wanted more personalised support. We avoided making this a long selection flow or a typing-only route because both can still create friction for people under stress or anxiety. Instead, we made voice a primary, prominent path, always alongside a text alternative. A central microphone button allows users to share what’s on their mind. The app then uses AI to analyse the input and provide a tailored set of coping practices.

Rather than picking a single entry model, we kept two paths because they served different states. That matched what we saw in later analytics and user conversations: quick emotional selection worked better when users wanted speed, while open voice or text input worked better when they wanted personalisation and to feel more heard. This was more a pattern we noticed, without having the exact measured results.

Voice is used as a low-friction alternative to typing across different tasks in Bear Room. (Large preview)

Similarly, in Teeni, we directly addressed the cognitive friction of parenting stress by introducing a “Quick Relief” button. This creates an empathy-friendly flow for parents experiencing anger or frustration. The button initiates a dedicated “Hot Flow,” allowing them to first vent and relieve their immediate negative emotions through voice input. Only after this emotional release does the app gently guide them into the more reflective “Cold Flow” for the rest of the app’s resources. This sequential, state-sensitive design acknowledges that a user in peak distress cannot navigate a complex app; they need a direct, simple, and validating first step.

Teeni’s Quick Relief flow helps parents regulate before reflection.

These solutions directly tackle cognitive friction by meeting users at their level of capacity, resisting trends that add visual or interaction complexity. Voice input and single-action buttons remove the mechanical and cognitive burden of navigation and typing. The result is an interface that feels reliably non-judgmental and genuinely helpful when users are least equipped to navigate complexity.

• 
  

2. Emotional Mismatch: The Trust Erosion Of Misaligned Design Tone

A user’s emotional state is the context in which a mental health app operates. This is why its visual language must be empathetic and considerate. Research investigating how colour and aesthetics influence mood in mHealth apps suggests a critical insight: users in distress show a strong preference for subtlety. They long for dark palettes, sleek and sophisticated looks, and clean, uncluttered aesthetics, explicitly noting that cheerful, bright colours, while seemingly appropriate, can create a jarring, even physically uncomfortable conflict with their current mood.

Emotional alignment is the fit between the product’s promise, visual tone, and the user’s likely emotional state.

This does not mean that every mental health or wellbeing app should look dark, quiet, or clinically restrained. The category is broad: it includes self-care, anxiety support, habit change, addiction recovery, trauma tools, therapy-adjacent products, and apps for more severe mental health contexts. A playful visual style may be appropriate for one product and a poor fit for another. What matters is not whether the interface is bright or muted, but whether its emotional tone fits the product’s purpose and the likely state in which users arrive.

Emotional mismatch can also appear in mechanics, not only in aesthetics. In Calmer, an anxiety and panic relief app, the interface itself appeared relatively clean and relaxed. Yet some of its engagement and monetisation mechanics sit in a different register from that relaxed: a discount wheel, or confetti celebrating a logged low mood. For a user who just recorded a hard moment, that shift — from quiet support to upsell or celebration — can land as a mismatch, whatever its intent.

For Bear Room, we prototyped a “cosy room” design informed by direct feedback from our users, which echoed the study’s conclusions. Several users in our research described the apps they had tried for similar needs as “too bright, too happy, and too overwhelming”. Users longed for a digital safe space. This was part of what pointed us toward a quieter palette in the final design: muted, earthy tones — neutral hues like soft greens and taupes — set against darker, calming backgrounds. For this product — a refuge for users arriving overwhelmed — that meant a middle ground: a space that feels safe without being gloomy. The interface avoided any bright alerts or sudden animations, making calmness the core feature.

Bear Room’s muted palette was designed to create a grounded, safe, and emotionally low-friction atmosphere.

This case underscores a critical principle: an overly cheerful, bold, or trend-forward interface can feel dismissive to someone in distress, creating a conflict that erodes trust. As Bear Room shows, trust is built when the interface respectfully aligns with the user’s emotional reality, offering solace through subtlety (which creates an overall feeling of a “welcoming and safe atmosphere”), not a solution through saturation.

3. The Inconsistency Penalty: Why Novelty Undermines Routine

Mental health often relies on routine and predictability. Yet many contemporary UI trends thrive on novelty and disruption, intentionally reimagining fundamental navigation. When an app introduces a novel interaction pattern, such as a unique swipe or a non-standard button behavior, it asks the user to learn something before they can act, forcing them into cognitive effort they can’t afford.

This does not mean that mental health apps must be plain, rigid, or generic. A product can have its own character, playfulness, and sense of identity. The question is whether that identity remains understandable and predictable when the user returns in a low-capacity state. A gamified self-care app like Finch may work well when the user arrives ready to explore, play, and build a routine. But open it after a hard day just to mark one task done, and the can’t-skip celebration screens that delight an engaged user become one more layer to get through before they reach what they came for.

Playful identity can support routine, but repeated non-skippable moments may interrupt users who only want to complete a simple task.

A similar tension appears in large meditation and wellbeing platforms. Apps such as Headspace and Calm offer extensive libraries of different content. This breadth can be valuable during exploration. But in moments of stress, the product question becomes sharper: can the user return and immediately find the exact support they need, or do they have to search, filter, and relearn the structure?

Large content libraries can be valuable during exploration, but harder to navigate during distress.

Someone experiencing anxiety or executive dysfunction needs to use the tool in a straightforward navigation manner, not an interface they have to learn each time anew.

PTSD Coach, a public-health-oriented trauma-support app designed to help users learn about and manage symptoms after trauma, offers a useful positive example. Its interface is not trying to be fashion-forward. Its strength lies in a stable information architecture: users can learn, track symptoms, manage symptoms, and get support through clearly separated areas. For a user returning during distress, this predictability matters more than novelty.

Stable IA supports return use: learn, track, manage symptoms, get support.

CALMzone offers another useful example. Some of its breathing animations differ from standard visual patterns, but they remain tied to the exercise itself: the animation shows what to do, when to inhale, and when to hold. The guided audio screen also explicitly invites the user to put the phone down and listen. This is a rare and valuable form of interaction design: the product’s success is not more screen time, but reduced effort and regulation.

Novel interaction can work when it directly supports the exercise rather than distracting from it.

These insights guided our approach in applications like Bear Room, where navigation reliability was treated as a therapeutic feature. We intentionally crafted an experience of an empathetic guided flow.

Recognising that users would likely approach in states of overwhelm, we structured the interface as a clear, unwavering path, with a visible “Start” sign. Key emotional support tools here are represented as the room’s objects — symbols of daily life, unmistakably recognised by all. They are visually highlighted by design so that the user won’t get lost in the elements, can easily access the needed tool, and can remember their way around the digital space upon the next return to the app.

Navigation reliability as a guided flow: familiar objects, visible entry points, and a repeatable path to support. 

Trend-driven interfaces sacrifice this navigational certainty for novelty. Each unconventional choice in mHealth apps, when core functions are buried behind experimental interactions or placed in unexpected locations, leads to a cumulative effect of fatigue instead of innovation. Users are not in a place to explore. They abandon the entire practice of seeking digital support when every interaction feels like solving a new puzzle. This does not restrict experimentation; it simply means that animations, micro-interactions, AI, or playful mechanics must serve the user’s state rather than interrupt it.

4. The Silent Exclusion: How Trends Compromise Accessibility

Many popular UI trends can be exclusionary when applied without adaptation. The minimalist trend of low-contrast text fails users with visual impairments. Gesture-only navigation marginalises those with motor difficulties. Visually dense, animated interfaces can overwhelm users with cognitive or attentional conditions. In mental health, the population needing support disproportionately includes individuals with these accessibility needs.

Low contrast, small text, and dense layouts can make support harder to access for users with visual, cognitive, or attentional needs.

Choosing a trending aesthetic over an accessible one is therefore an active decision to limit the app’s reach and efficacy. It ensures that those who might benefit most cannot use the tool effectively. Accessibility isn’t a layer you add at the end; it’s a constraint you design within, with most of it codified in Web Content Accessibility Guidelines 2.2. Body text needs 4.5:1 contrast against its background, large text and interface elements 3:1 — exactly what low-contrast minimalism fails. Interactive targets need a floor of 24×24 px (more for unsteady hands). Every gesture needs a visible button fallback, or you risk excluding anyone who can’t perform the swipe.

5. The Coercion Paradox: When “Engagement” Becomes “Pressure”

A final, and often overlooked, consequence of trend-following is the adoption of engagement mechanics designed for entertainment, educational, or productivity apps. Features like streaks, aggressive notifications, and gamified reward systems are engineered to maximise screen time and create dependency. Although they have long been considered effective tools for increasing retention, in a mental health context, this approach can easily be misguided. What presents as “motivation” can quickly transform into a source of performance pressure and guilt. For a user managing depression, a broken streak or a missed daily goal can exacerbate the very feelings the app aims to alleviate.

Streaks can motivate some users, but missed days should not be framed as failure in non-linear recovery contexts.

These mechanics are not inherently unethical. In routine-building products, they can help some users. The risk appears when they are transferred into mental health contexts without adapting for shame, low energy, relapse, and non-linear recovery. A streak, for example, is not just a retention mechanic when the user is emotionally vulnerable. It can become a visible record of whether they have “kept up” with their well-being.

In the apps I reviewed, this tension appeared through familiar persuasion patterns: streaks, streak freezes, commitment copy, urgency-based notifications, “don’t miss this offer” prompts, and success-framed buttons such as “Yes, I want to succeed.” In self-care or wellbeing products, these details can make the app feel less like a supportive tool and more like another system the user has to satisfy.

(Large preview)

Designers still need return triggers. A mental health app has little value if users install it once and forget it exists. But return mechanics must be adapted to the emotional context. In Bear Room, for example, this philosophy is embodied in short, forgiving three-day streaks: the streak does not reset when a user misses a day, and every third day brings a small benefit. The goal is not to punish absence, but to gently support return.

The same principle applies to lighter interactions. Bear Room includes a simple, optional bubble-popping game. Its purpose, however, is not to hook the user but to offer a brief, calming interlude. It is deliberately finite, providing a small mood lift and gently signposting other resources within the app. The value is in the momentary relief, not the extended session.

This commitment to supportive, non-coercive design extends to foundational app architecture:

• Respectful and User-Tailored Interaction Models
  The Pillow, a visual interface in the app, acts as a neutral, accepting space. Users can select a feeling or record a voice note, and the app responds with an AI-curated set of practices (28). It offers support without judgment, commentary, or pressure to “achieve” a certain state. Our app prioritises mood-aware algorithms to dynamically order activities. Breathing exercises or grounding techniques are surfaced based on the user’s reported emotional state, creating personal resonance without the need for an overwhelming content library.
• Feedback as a Reciprocal Exchange
  We approach feedback not as a data grab via constant emails but as a respectful dialogue. An unobtrusive object allows users to contribute at a natural pause point, and their input is acknowledged with a small reward. This frames their participation as a valued gift, not a demanded obligation.

In mental health technology, sustainable retention is earned not by capturing attention, but by becoming a consistently respectful and helpful presence in a user’s life.

“

The mHealth apps design invites finding a challenging balance between boosting their use without being too demanding.

The Scale Of The Stakes

This is not a niche concern affecting a fringe audience. The World Health Organization (WHO) estimates that about one billion people globally live with a mental disorder, with depression alone affecting nearly 5% of adults. Critically, the overall number is rising — in the last decade, depression and anxiety cases have increased by 25%. This vast and vulnerable population cannot afford for its tools to fail due to poor design. While UI trends aren’t inherently problematic, their application within wellbeing products demands a radically contextual approach.

Even a five-minute decompression tool between meetings has an emotional context, and a style chosen for its look — glassmorphism, a certain flavour of ultra-minimalism — can miss it, however sophisticated the audience. The point isn’t that these styles are wrong; it’s that the look has to answer to the moment. Soft biomorphic shapes or fluid transitions can genuinely help when they directly serve the goal of calm — and the same elements become noise when they’re there to impress.

What carries the highest risk is lifting a visually striking “Dribbble shot” and applying it without deep adaptation: it solves for the designer’s portfolio, not the user’s need.

A Practical Framework For Evaluation

The five fronts outlined above are not just a diagnostic lens; they are the foundation of an evaluation framework for anyone designing in the mental health space. Before incorporating any trendy visual or interaction pattern, it is worth running it through each of them in sequence:

(Large preview)

• Cognitive load
  Does this reduce the effort required for someone who is overwhelmed, or does it add another layer of complexity to an already strained experience?
• Emotional alignment
  Does this support a wide spectrum of emotional states, including distress and exhaustion, or does it clash with the context in which users are most likely to arrive?
• Navigational reliability
  Does this build trust through predictability, allowing users to return and find their way without relearning, or does it prioritise novelty at the cost of consistency?
• Accessibility
  Does this uphold or enhance accessibility for diverse sensory and cognitive abilities, or does it quietly exclude the users who may need support the most?
• Engagement integrity
  Does this invite use in a way that is supportive and non-coercive, or does it borrow mechanics from entertainment products that may create pressure rather than relief?

A design that passes all five holds together as something more than usable: it becomes a tool that users can trust enough to return to in moments of genuine need.

Trends can be inspiring. They can win awards and generate buzz. But in mental health, sometimes the best design is the one that helps users feel understood — a quiet helper they trust enough to return to in moments of stress and vulnerability. It doesn’t steal the spotlight, but focuses on the user’s emotions. In the end, the ultimate goal is not for the interface to be seen — but for the support to be felt.

Stop Building "Dead" Websites. (The Pixel-Perfect Era is Over)

 

Your $50k website is officially a dinosaur. 🦖

For a decade, we’ve been obsessed with "Pixel Perfection." We argued over hex codes, debated the radius of a button, and spent months perfecting "Click Paths."

The reality? In 2026, your users don’t want to click through your beautiful menu. They want an answer.

We are witnessing the violent transition from Deterministic UI (the static site you built) to Generative UI (the interface that builds itself around the user).

---

1. The Netflix-ification of Everything

Remember when you had to browse "Genres" to find a movie? Now, Netflix builds a unique homepage for you the second you log in.

If your SaaS or E-commerce site still looks the same for a first-time visitor as it does for a 5-year veteran, you aren't "consistent"—you’re irrelevant. Generative UI means the interface morphs based on intent. If the AI detects a user is frustrated, the "Help" button shouldn't just be there; it should be the only thing there.

2. Accessibility is your new SEO

Here is a hard truth: If an AI Agent (like Gemini or GPT-6) can’t "crawl" your site and understand it instantly, you don't exist.

• Old way: Making your site accessible to be "nice."
• New way: Using Semantic HTML because if the AI can’t read your site, it won't recommend you to the millions of people using Voice Search and AI Personal Assistants.

3. The "Invisible" UI (Example: Uber)

The most successful interface of the last decade is the Uber map. Why? Because it’s invisible. You don’t "navigate" a menu to find a car. You see a map, you see a car, you press one button.

The future isn't more buttons; it’s Zero UI. It’s systems that use token-driven logic to automate the boring stuff so humans can do the creative stuff.

---

The Bottom Line:

Stop building for browsers. Start building for behaviors.

If your design system requires a manual to understand, you’ve already lost. The winners of 2026 will be the ones who blend high-end aesthetics with "Invisible" AI logic.

---

I’m calling it: The "Sidebar and Dashboard" layout is officially dead. Who’s brave enough to disagree? 👇

Drop a comment below: Is your team still stuck in the "Pixel-Perfect" trap, or are you building for the AI era?

What Will Engineers Actually Do in 2030?

 

🔥 Big Story of the Week

🧑💻 The Engineer of 2030: Builder, Reviewer, or AI Trainer?

If you look at how you work today… and compare it to even a year ago, something feels different.

You’re still coding. But not in the same way.

Sometimes, it feels like:

• You’re reviewing more than writing
• Thinking more than typing
• Guiding more than building

And that raises an uncomfortable but important question:

👉 What does it actually mean to be an engineer in the future?

---

🧠 The Shift Has Already Started

Let’s be real.

AI can now:

• Generate full functions in seconds
• Suggest optimizations
• Write tests you might skip
• Even explain your own code back to you

So naturally, your role starts to shift.

Not overnight. But quietly, consistently.

---

⚙️ So… What Are We Becoming?

The future engineer isn’t just one thing anymore.

It’s a mix of roles.

---

🔹 1. The Builder (Still Important)

Yes — coding isn’t going away.

You still need to:

• Understand systems
• Write critical logic
• Handle edge cases

Because AI is fast… but it doesn’t understand context like you do.

---

🔹 2. The Reviewer (More Important Than Ever)

AI can generate code.

But can it guarantee:

• Business correctness? ❌
• Edge case handling? ❌
• Long-term maintainability? ❌

That’s where you come in.

You’re no longer just writing code — 👉 you’re validating intelligence.

---

🔹 3. The AI Trainer (The New Role)

This is where things get interesting.

You’re now:

• Writing better prompts
• Refining outputs
• Teaching AI what “good” looks like

In a way… 👉 you’re training a junior developer that learns instantly.

---

⚠️ The Risk Nobody Talks About

There’s a hidden danger in all this.

If we rely too much on AI:

• Our fundamentals may weaken
• Our debugging instincts may slow down
• Our deep understanding may fade

And that’s risky.

Because when AI fails — 👉 you’re still the final line of defense.

---

🌍 The Bigger Reality

The barrier to building software is dropping fast.

Which means:

• More builders are entering the space
• More products are being created
• More competition is coming

So the real differentiator won’t be: ❌ Who can code ✅ But who can think, design, and adapt

---

🔮 What the Best Engineers Will Do

The engineers who thrive won’t fight AI.

They’ll:

• Use it to move faster
• Focus on deeper problems
• Build better systems, not just more code

Because the game is changing from: 👉 “Write more code” to 👉 “Create more impact”

---

💡 Engineer’s Takeaway

The future engineer is not just a builder.

They are: 🧠 A thinker 🔍 A reviewer 🤖 A guide to AI

And maybe that’s the real evolution.

Because in the end, 👉 tools will change — but great thinking never goes out of style.

---

✍️ EngiSphere Insight: “The engineers who win in the AI era won’t be the fastest coders — they’ll be the smartest decision-makers.”

#SoftwareEngineering #AI #FutureOfWork #Developers #TechTrends #EngiSphere

#ArtificialIntelligence #Programming #CareerGrowth #TechLeadership #Innovation

Modal vs. Separate Page: UX Decision Tree

 

You probably have been there before. How do we choose between showing a modal to users, and when do we navigate them to a separate, new page? And does it matter at all?

Actually, it does. The decision influences users’ flow, their context, their ability to look up details, and with it error frequency and task completion. Both options can be disruptive and frustrating — at the wrong time, and at the wrong place.

So we’d better get it right. Well, let’s see how to do just that.

Modals vs. Dialogs vs. Overlays vs. Lightboxes

While we often speak about a single modal UI component, we often ignore fine, intricate nuances between all the different types of modals. In fact, not every modal is the same. Modals, dialogs, overlays, and lightboxes — all sound similar, but they are actually quite different:

Understanding modal vs. nonmodal and lightbox vs. nonlightbox dialog boxes for good UX. (Image source: Popups by NN/g) 

• Dialog
  A generic term for “conversation” (user ↔ system).
• Overlay
  A small content panel displayed on top of a page.
• Modal
  User must interact with overlay + background disabled.
• Nonmodal
  User must interact with overlay + background enabled.
• Lightbox
  Dimmed background to focus attention on the modal.

As Anna Kaley highlights, most overlays appear at the wrong time, interrupt users during critical tasks, use poor language, and break users’ flow. They are interruptive by nature, and typically with a high level of severity without a strong need for that.

The many sides of modals and overlays. A little tree to understand the differences for UI components. (Image source: Ryan Neufeld) (Large preview)

Surely users must be slowed down and interrupted if the consequences of their action have a high impact, but for most scenarios non-modals are much more subtle and a more friendly option to bring something to the user’s attention. If anything, I always suggest it to be a default.

Modals → For Single, Self-Contained Tasks

As designers, we often dismiss modals as irrelevant and annoying — and often they are! — yet they have their value as well. They can be very helpful to warn users about potential mistakes or help them avoid data loss. They can also help perform related actions or drill down into details without interrupting the current state of the page.

But the biggest advantage of modals is that they help users keep the context of the current screen. It doesn’t mean just the UI, but also edited input, scrolling position, state of accordions, selection of filters, sorting, and so on.

Nonmodal in action: large and small overlays for filters and a modal for customization work well on Yahoo! Finance. (Large preview)

At times, users need to confirm a selection quickly (e.g., filters as shown above) and then proceed immediately from there. Auto-save can achieve the same, of course, but it’s not always needed or desired. And blocking the UI is often not a good idea.

However, modals aren’t used for any tasks. Typically, we use them for single, self-contained tasks where users should jump in, complete a task, and then return to where they were. Unsurprisingly, they do work well for high-priority, short interactions (e.g., alerts, destructive actions, quick confirmations).

When modals help:

🚫 Modals are often disruptive, invasive, and confusing.
🚫 They make it difficult to compare and copy-paste.
✅ Yet modals allow users to maintain multiple contexts.
✅ Useful to prevent irreversible errors and data loss.
✅ Useful if sending users to a new page would be disruptive.

✅ Show a modal only if users will value the disruption.
✅ By default, prefer non-blocking dialogs (“nonmodals”).
✅ Allow users to minimize, hide, or restore the dialog later.
✅ Use a modal to slow users down, e.g., verify complex input.
✅ Give a way out with “Close”, ESC key, or click outside the box.

Pages → For Complex, Multi-Step Workflows

Wizards or tabbed navigation within modals doesn’t work too well, even in complex enterprise products — there, side panels or drawers typically work better. Troubles start when users need to compare or reference data points — yet modals block this behavior, so they re-open the same page in multiple tabs instead.

Perhaps, we use Too Many Modals. A not-very-modal-friendly project by Adrian Egger.

For more complex flows and multi-step processes, standalone pages work best. Pages also work better when they demand the user’s full attention, and reference to the previous screen isn’t very helpful. And drawers work for sub-tasks that are too complex for a simple modal, but don’t need a full page navigation.

When to avoid modals:

🚫 Avoid modals for error messages.
🚫 Avoid modals for feature notifications.
🚫 Avoid modals for onboarding experience.
🚫 Avoid modals for complex, lengthy multi-step-tasks.
🚫 Avoid multiple nested modals and use prev/next instead.
🚫 Avoid auto-triggered modals unless absolutely necessary.

Avoid Both For Repeated Tasks

In many complex, task-heavy products, users will find themselves performing the same tasks repeatedly, over and over again. There, both modals and new page navigations add friction because they interrupt the flow or force users to gather missing data between all the different tabs or views.

Too often, users end up with a broken experience, full of never-ending confirmations, exaggerated warnings, verbose instructions, or just missing reference points. As Saulius Stebulis mentioned, in these scenarios, expandable sections or in-place editing often work better — they keep the task anchored to the current screen.

In practice, in many scenarios, users don’t complete their tasks in isolation. They need to look up data, copy-paste values, refine entries in different places, or just review similar records as they work through their tasks.

Overlays and drawers are more helpful in maintaining access to background data during the task. As a result, the context always stays in its place, available for reference or copy-paste. Save modals and page navigation for moments where the interruption genuinely adds value — especially to prevent critical mistakes.

Modals vs. Pages: A Decision Tree

A while back, Ryan Neufeld put together a very helpful guide to help designers choose between modals and pages. It comes with a handy PNG cheatsheet and a Google Doc template with questions broken down across 7 sections.

It’s lengthy, extremely thorough, but very easy to follow:

A flowchart to choose between page vs. modal, with the page being the default, and modals reserved for interruption and focus. Put together by wonderful Ryan Neufeld. 

It might look daunting, but it’s a quite simple 4-step process:

1. Context of the screen.
   First, we check if users need to maintain the context of the underlying screen.
2. Task complexity and duration.
   Simpler, focused, non-distracting tasks could use a modal, but long, complex flows need a page.
3. Reference to underlying page.
   Then, we check if users often need to refer to data in the background or if the task is a simple confirmation or selection.
4. Choosing the right overlay.
   Finally, if an overlay is indeed a good option, it guides us to choose between modal or nonmodal (leaning towards a nonmodal).

Wrapping Up

Whenever possible, avoid blocking the entire UI. Have a dialog floating, partially covering the UI, but allowing navigation, scrolling, and copy-pasting. Or show the contents of the modal as a side drawer. Or use a vertical accordion instead. Or bring users to a separate page if you need to show a lot of detail.

But if you want to boost users’ efficiency and speed, avoid modals at all costs. Use them to slow users down, to bundle their attention, to prevent mistakes. As Therese Fessenden noted, no one likes to be interrupted, but if you must, make sure it’s absolutely worth the cost.

Meet “Smart Interface Design Patterns” #

You can find a whole section about modals and alternatives in Smart Interface Design Patterns, our 15h-video course with 100s of practical examples from real-life projects — with a live UX training later this year. Everything from mega-dropdowns to complex enterprise tables — with 5 new segments added every year. Jump to a free preview. Use code BIRDIE to save 15% off.

Video + UX Training

$ 579^.00 $ 699^.00 Get Video + UX Training

25 video lessons (15h) + Live UX Training.
100 days money-back-guarantee.

Video only

$ 275^.00$ 350^.00

Get the video course

40 video lessons (15h). Updated yearly.
Also available as a UX Bundle with 2 video courses.

Useful Resources

• Different Types of Popups, by Anna Kaley
• Best Practices for Designing UI Modals, by Uxcel
• We Use Too Many Damn Modals: UX Guidelines, by Adrian Egger
• Modal & Nonmodal Dialogs, by Therese Fessenden
• Modern Enterprise UI Design: Modal Dialogs, by James Jacobs
• Modals in Design Systems

Beyond border-radius: What The CSS corner-shape Property Unlocks For Everyday UI

For years, developers have been hacking around the limitations of border-radius, using clip-path, SVG masks, and fragile workarounds just to get anything other than round corners. The new corner-shape property finally changes that, opening the door to beveled, scooped, and squircle corners.

When I first started building websites, rounded corners required five background images, one for each corner, one for the body, and a prayer that the client wouldn’t ask for a different radius. Then the border-radius property landed, and the entire web collectively sighed with relief. That was over fifteen years ago, and honestly, we’ve been riding that same wave ever since. Just as then, I hope that we can look at this feature as a progressive enhancement slowly making its way to other browsers.

I like a good border-radius like any other guy, but the fact is that it only gives us one shape. Round. That’s it. Want beveled corners? Clip-path. Scooped ticket edges? SVG mask. Squircle app icons? A carefully tuned SVG that you hope nobody asks you to animate. We’ve been hacking around the limitations of border-radius for years, and those hacks come with real trade-offs: borders don’t follow clip-paths, shadows get cut off, and you end up with brittle code that breaks the moment someone changes a padding value.

Well, the new corner-shape changes all of that.

What Is corner-shape?

The corner-shape property is a companion to border-radius. It doesn’t replace it; it modifies the shape of the curve that border-radius creates. Without border-radius, corner-shape does nothing. But together, they’re a powerful pair.

The property accepts these values:

• round: the default, same as regular border-radius,
• squircle: a superellipse, the smooth Apple-style rounded square,
• bevel: a straight line between the two radius endpoints (snipped corners),
• scoop: an inverted curve, creating concave corners,
• notch: sharp inward cuts,
• square: effectively removes the rounding, overriding border-radius.

And you can set different values per corner, just like border-radius:

*corner-shape: bevel round scoop squircle;
/* top-left, top-right, bottom-right, bottom-left */

You can also use the superellipse() function with a numeric parameter for fine-grained control.

.element { 
  border-radius: 25px;
  corner-shape: superellipse(0); /* equal to 'bevel' */
}

So the question here might be: why not call this property “border-shape” instead? Well, first of all, that is something completely different that we’ll get to play around with soon. Second, it does apply to a bit more than borders, such as outlines, box shadows, and backgrounds. That’s the thing that the clip-path property could never do.

Why Progressive Enhancement Matters Here

At the time of writing (March 2026), corner-shape is only supported in Chrome 139+ and other Chromium-based browsers. That’s a significant chunk of users, but certainly not everyone. The temptation is to either ignore the property until it’s everywhere or to build demos that fall apart without it.

I don’t think either approach is right. The way I see it, corner-shape is the perfect candidate for progressive enhancement, just as border-radius was in the age of Internet Explorer 6. The baseline should use the techniques we already know, such as border-radius, clip-path, radial-gradient masks and look intentionally good. Then, for browsers that support corner-shape, we upgrade the experience. Sometimes this can be as simple as just providing a more basic default; sometimes it might need to be a bit more.

Every demo in this article is created with that progressive enhancement idea. The structure for the demos looks like:

@layer base, presentation, demo;

The presentation layer contains the full polished UI using proven techniques. The demo layer wraps everything in @supports:

@layer demo {
  @supports (corner-shape: bevel) {
    /* upgrade styles here */
  }
}

No fallback banners, no “your browser doesn’t support this” messages. Just two tiers of design: good and better. I thought it could be nice just to show some examples. There are a few out there already, but I hope I can add a bit of extra inspiration on top of those.

Demo 1: Product Cards With Ribbon Badges

Every e-commerce site has them: those little “New” or “Sale” badges pinned to the corner of a product card. Traditionally, getting that ribbon shape means reaching for clip-path: polygon() or a rotated pseudo-element, let’s call it “fiddly code” that has the chance to fall apart the moment someone changes a padding value.

But here’s the thing: we don’t need the ribbon shape in the baseline. A simple badge with slightly rounded corners tells the same story and looks perfectly fine:

.product__badge {
  border-radius: 0 4px 4px 0;
  background-color: var(--badge-bg);
}

That’s it. A small, clean label sitting flush against the left edge of the card. Nothing fancy, nothing broken. It works in every browser.

For browsers that support corner-shape, we enhance:

@layer demo {
  /* If the browser supports `corner-shape` */
  @supports (corner-shape: bevel) {
    .product {
      border-radius: 40px;
      corner-shape: squircle;
    }

    .product__badge {
      padding: 0.35rem 1.4rem 0.35rem 1rem;
      border-radius: 0 16px 16px 0;
      corner-shape: round bevel bevel round;
    }
  }
}

The round bevel bevel round combination creates a directional ribbon. Round where it meets the card edge, beveled to a point on the other side. No clip-path, no pseudo-element tricks. Borders, shadows, and backgrounds all follow the declared shape because it is the shape.

The cards themselves upgrade from border-radius: 12px to a larger size and the squircle corner-shape, that smooth superellipse curve that makes standard rounding look slightly off by comparison. Designers will notice immediately. Everyone else will just say it “feels more premium.”

Hot tip: Using the squircle value on card components is one of those upgrades where the before-and-after difference can be subtle in isolation, but transformative across an entire page. It’s the iOS effect: once everything uses superellipse curves, plain circular arcs start looking out of place. In this demo, I did exaggerate a bit.

See the Pen Corner-shape: Labels [forked] by utilitybend.

Demo 2: Buttons, Tags, And Components

This is the “component library demo”, the one that shows corner-shape isn’t just for hero sections. It’s practical, everyday UI: solid buttons, outlined buttons, status tags, directional arrows, notification badges.

The set-up is intentionally clean. Standard border-radius: 10px buttons with a polished typeface. Everything works, everything looks professional. You could do this without hesitation.

The corner-shape layer turns it into a showcase. Each button type gets its own shape to demonstrate the range of what’s possible:

@layer demo {
  @supports (corner-shape: bevel) {
    .btn--primary {
      corner-shape: bevel;
      transition: corner-shape 0.3s ease;

      &:hover {
        corner-shape: squircle;
      }
    }

    .btn--secondary {
      border-radius: 25px;
      corner-shape: superellipse(0.5);
    }

    .btn--danger {
      border-radius: 16px;
      corner-shape: squircle;
    }

    .btn--notch {
      border-radius: 12px;
      corner-shape: notch;
    }

    .btn--scoop {
      border-radius: 14px;
      corner-shape: scoop;
    }
  }
}

Before.

After.

The primary button starts beveled, faceted, and gem-like, and softens to squircle on hover. Because corner-shape values animate via their superellipse() equivalents, the transition is smooth. It’s a fun interaction that used to be hard to achieve but is now a single property (used alongside border-radius, of course).

The secondary button uses superellipse(0.5), a value that is between a standard circle and a squircle, combined with a larger border-radius for a distinctive pill-like shape. The danger button gets a more prominent squircle with a generous radius. And notch and scoop each bring their own sharp or concave personality.

Beyond buttons, the status tags get corner-shape: notch, those sharp inward cuts that give them a machine-stamped look. The directional arrow tags use round bevel bevel round (and its reverse for the back arrow), replacing what used to require clip-path: polygon(). Now borders and shadows work correctly across all states.

See the Pen Corner-shape: Buttons & Tags [forked] by utilitybend.

Demo 3: Testimonial Cards 

This demo is probably my favourite one. At its foundation, these are just testimonial cards with serif typography, a sandy palette, and scooped corners on the featured card. The design language is intentionally different from the clean geometric buttons demo, and that’s the point. corner-shape merely adds that extra “edge”.

The basis is standard border-radius: 16px cards. The featured testimonial spans full width with a subtle gradient and a decorative open quote mark. Normal cards alternate in a two-column grid. It already looks like something from a premium marketing site.

The corner-shape layer adds character:

@layer demo {
  /* Progressive enhancement */
  @supports (corner-shape: scoop) {
    .testimonial {
      border-radius: 20px;
      corner-shape: squircle;
    }

    .testimonial--featured {
      border-radius: 24px;
      corner-shape: scoop;
    }

    .testimonial:not(.testimonial--featured):nth-child(even) {
      corner-shape: scoop round;
    }

    .testimonial__avatar {
      border-radius: 28%;
      corner-shape: squircle;
    }
  }
}

The featured card gets full scoop corners, concave on all four sides, creating an organic, almost hand-crafted feel that matches the serif typography. Even-numbered cards mix scoop round, giving each one a slightly different personality without any extra markup.

The author avatars switch from circles to squircle. A small touch that makes it a bit more “different”.

Fallback. 

Supported.

Hot tip: corner-shape: scoop pairs beautifully with serif fonts and warm color palettes. The concave curves echo the organic shapes found in editorial design, calligraphy, and print layouts. For geometric sans-serif designs, stick with squircle or bevel.

See the Pen Corner-shape: Testimonials [forked] by utilitybend.

Demo 4: Pricing Cards

Every SaaS site needs a pricing page, and the visual hierarchy challenge is always the same: make one plan stand out without the others feeling neglected. This demo solves it with corner-shape.

This is quite similar to the last demo in that we once again have a nice baseline for browsers that don’t yet support corner-shape. We have three cards in a row, where the featured plan is distinguished by a warm gradient background, a stronger border, and a “Most Popular” badge.

The enhancement takes it further:

@layer demo {
  @supports (corner-shape: squircle) {
    .plan {
      border-radius: 20px;
      corner-shape: squircle;
    }

    .plan--featured {
      border-radius: 24px;
      corner-shape: scoop;
    }

    .plan__badge {
      inset-inline-start: 50%;
      translate: -50% 0;
      padding-inline: 1.2rem;
      border-radius: 10px;
      corner-shape: bevel;
    }

    .plan__cta {
      border-radius: 12px;
      corner-shape: squircle;
    }
  }
}

Regular plans get squircle for that premium feel. The featured plan gets scoop, concave corners that immediately set it apart from its neighbors. The “Most Popular” badge centers itself and takes on corner-shape: bevel, creating a gem-like, faceted shape that feels like a jewel pinned to the card. The CTA buttons get squircle to match the card language.

Before. (Large preview)

After.

What I like about this demo is how the shape hierarchy mirrors the content hierarchy. The most important element (featured plan) gets the most distinctive shape (scoop). The badge gets the sharpest shape (bevel). Everything else gets a simpler upgrade (squircle). Shape becomes a tool for visual emphasis, not just decoration.

See the Pen Corner-shape: Pricing [forked] by utilitybend.

Demo 5: Music Player

The final demo is a warm dark UI for a music player with album art, playback controls, genre tags, and a listening queue. It’s the most visually complex demo, and it shows how corner-shape works across many different element types within a single cohesive design.

This time, I went for a dark warm palette built on oklch(18% 0.015 40), and standard rounded corners throughout. The album art gets border-radius: 12px, queue items get border-radius: 12px, genre tags get border-radius: 5px. It looks good. It’s a complete, polished player.

And then once again, we add some enhancements:

@layer demo {
  @supports (corner-shape: squircle) {
    .now-playing {
      border-radius: 20px;
      corner-shape: squircle;
    }

    .now-playing__art {
      border-radius: 16px;
      corner-shape: squircle;
    }

    .now-playing__swatch {
      border-radius: 26%;
      corner-shape: squircle;
    }

    .queue-item {
      border-radius: 14px;
      corner-shape: scoop round;
    }

    .tag {
      border-radius: 8px;
      corner-shape: bevel;
    }
  }
}

The player card and album art get squircle, the same curves used for app icons and album thumbnails. Album art swatches go from border-radius: 22% to a proper squircle at 26%, which is a subtle but meaningful difference in the visual elements you stare at while listening.

Queue items get scoop round, resulting in concave corners on the top-left and bottom-left, and round on the right. It gives each row a distinctive feel without overwhelming the layout. Genre tags get bevel for that sharp feeling.

The Play button also gets corner-shape: squircle on its existing border-radius: 50% to fit the album covers. On the surface, the difference is barely noticeable, but it contributes to the overall feel of the player.

See the Pen Corner-shape: Music player [forked] by utilitybend.

Before. (Large preview)

After.

Browser Support

As of writing, corner-shape is available in Chrome 139+ and Chromium-based browsers. Firefox and Safari don’t support it yet. The spec lives in CSS Borders and Box Decorations Module Level 4, which is a W3C Working Draft as of this writing.

For practical use, that’s fine. That’s the whole point of how these demos are built. The presentation layer delivers a polished, complete UI to every browser. The demo layer is a bonus for supporting browsers, wrapped in @supports (corner-shape: ...). I lived through the time when border-radius was only available in Firefox. Somewhere along the line, it seems like we have forgotten that not every website needs to look exactly the same in every browser. What we really want is: no “broken” layouts and no “your browser doesn’t support this” messages, but rather a beautiful experience that just works, and can progressively enhance a bit of extra joy. In other words, we’re working with two tiers of design: good and better.

Wrapping Up

The approach I keep coming back to is: don’t design for corner-shape, and don’t design around the lack of it. Design a solid baseline with border-radius and then enhance it. The presentation layer in every demo looks intentionally good. It’s not a degraded version waiting for a better browser. It’s a complete design. The demo layer adds a dimension that border-radius alone can’t express.

What surprises me most about corner-shape is the range it offers — the amazing powerhouse we have with this single property: squircle for that premium, superellipse feel on cards and avatars; bevel for directional elements and gem-like badges; scoop for editorial warmth and visual hierarchy; notch for mechanical precision on tags; and superellipse() for fine control between round and squircle. And the ability to mix values per corner (round bevel bevel round, scoop round) opens up shapes that would have required SVG masks or clip-path hacks.

We went from five background images to border-radius, to corner-shape. Each step removed a category of workarounds. I’m excited to see what designers do with this one.

Further Reading

• corner-shape (MDN)
• “What Can We Actually Do With corner-shape?”, Daniel Schwarz
• CSS Borders and Box Decorations Module Level 4 (W3C specification)
• A fun demo for “eco-labels”, Sebastian on CodePen