Matching AI Modality To User Intent: Designing The Right Interface

 

We’ve fallen into conversational tunnel vision, defaulting every AI capability into a chat-based interface simply because LLMs are trained on dialogue data. But great UX is about matching modality to users’ context, intent, and cognitive load, so the interface adapts to the user, not the other way around.

The design community has entered a period of conversational tunnel vision. Because Large Language Models (LLMs) are trained on dialogue, the industry has collectively decided that the chat bubble is the natural home for every AI capability. While the chat interface is a viable and powerful option for many tasks, it is one tool in an expansive toolkit. UX and Product teams must be intentional about the modalities we choose for how users provide their data and commands, and how the system presents its output.

Modality is the way a person uses their senses to interact with a system: seeing, hearing, touching, speaking, or typing.

To pick the best method, you need to think about what the user wants to do, where they are, and how much cognitive effort they are already expending. This guide offers a clear way to figure out the best approach for any product, using two tools to assist in the process: a Task Audit and an Input/Output Alignment Matrix.

Picture a traveler jogging through a loud airport terminal after a sudden gate change. They are dragging their roller bag and carrying a coffee in the other hand. They need to open their airline app to ask the AI assistant where to go. The tool immediately fails the input modality test. It forces the traveler to stop walking, balance their coffee, and type a long booking reference number into a tiny chat box. When they finally hit send, the system fails the output modality test. Instead of flashing a large, high-contrast gate number, the AI returns a dense paragraph explaining the atmospheric weather patterns causing the delay. The actual gate number sits buried at the very bottom.

While they might make the flight just fine, the user won’t forget the moment of anxiety they felt while using the AI tool — an experience that could have served as a way to reinforce a commitment to UX has instead validated the common conception that companies don’t care about or understand customers using their products. In this scenario, the airline built a smart tool, but the interface failed the user. The input required physical dexterity, which the traveler lacked at the time of need. The output demanded a level of reading focus they could not spare. This article will cover how we can avoid this scenario in our AI-powered tools. In order to be successful, we must evaluate the physical and cognitive load of our users to match both the input and output modality to their immediate intent.

Let’s first discuss the limitations of a chat-based interface.

Myth of the Do-It-All Chatbot

The allure of the chatbot is easy to understand from a product development standpoint. It is a blank slate. It suggests that the system can handle anything the user provides. However, a text-heavy interface often causes a high adaptation load. This load increases cognitive demands on users. Over time, this cognitive burden turns into a psychological tax a person pays when changing natural thought processes to accommodate a machine.

When an interface relies solely on conversation, it imposes a dual burden: a linguistic challenge for input and a cognitive challenge for output. We’ll examine both separately below.

Input: Why a Text Box is a Linguistic Barrier

A blank chat box creates a major problem for users who need to discover what a tool can actually do. In a standard graphical interface, menus and buttons provide clear visual cues that signal every available option. A chat box often leads to choice paralysis because users are forced to guess what the AI is capable of. They have to remember the exact phrasing or technical terms required to get the result they want.

Consider a data analyst who wants to find a specific trend in a spreadsheet. In a traditional tool, they might click a filter or sort button. In a chat interface, they must suddenly become a writer and describe that complex logic in a complete sentence. Another example: a manager trying to reorganize a team schedule. Dragging and dropping blocks on a calendar is intuitive. Describing those same scheduling shifts in a text prompt adds a layer of work that makes the task feel more difficult than it should be.

Designing for input means recognizing that composing a prompt is a creative act. It requires a person to translate a vague thought into a specific command. For many professionals, this creates a linguistic barrier. A designer might know exactly how they want an image to look but struggle to describe the lighting or texture in a text prompt. In that case, a slider or a color picker is a much better input method than a text box.

Having addressed the linguistic barrier of constructing input prompts, we must now consider the other half of the conversational burden. This is the cognitive cost the AI imposes when it responds in dense blocks of text.

Output: The Cognitive Cost of Reading Long Text

When an AI responds in long blocks of text, it transfers the interpretive work to you, the user. Text is a serial medium: your brain has to read one word after the next to extract meaning. That takes time. Sequential reading is necessary in many scenarios. Complex legal analysis or reviewing nuanced medical histories requires reading full paragraphs. Teams create friction when they default to text for data that visual formats communicate faster. Visual methods allow parallel processing. You can view a chart and spot a pattern in under a second.

Imagine asking an AI for a project status update. Instead of a color-coded dashboard, you receive three paragraphs listing every task completed that week. Now you must read the entire response and mentally summarize it to find the one piece of information you needed. The quick visual check has been replaced by a reading assignment.

The cognitive tax of this work compounds with professional stakes. A doctor asking for a patient’s vital signs needs a clear numerical display, not a narrative describing the readings. A stock trader looking for a price spike needs a line graph immediately, not a written description of price movement over the past hour. In both cases, a text response forces the professional through a slow, error-prone extraction process when speed and accuracy are most important.

Figure 1: Redesigning for psychological fatigue. The linear text loop (left) forces exhausting sequential verification, causing anxiety. The graphical selection grid (right) permits instant, low-effort visual confirmation (glance verification). 

A Taxonomy of Input and Output Modalities

Before selecting a modality, practitioners need a shared vocabulary for what the options actually are. The table below maps common input and output modalities to the contexts where each performs best. This is not a ranking. Each modality has a role; the question is always which role it is playing in a given workflow.

Designing for modality inherently requires a strong focus on accessibility. While visual dashboards provide rapid insight for many people, designers need to provide screen-reader-optimized audio alternatives for users with visual disabilities. Modality choices should multiply pathways to information.

Input Modalities

Modality	Best For	Example Contexts	Cognitive & Physical Rationale
Button / Tap	Single-step, binary actions	Launching a feature; confirming an alert	Eliminates recall overhead by utilizing recognition; maximizes execution speed during time-sensitive tasks.
Voice	Hands-busy or eyes-busy contexts	Field technician query; driving navigation	Offloads physical interaction to speech, though bounded by ambient noise and social privacy norms.
Natural Language Chat	Ambiguous or exploratory queries	Researching options; asking follow-up questions	Offers users freedom in what they can say; however, the user must figure out how to phrase their request clearly.
Form / Wizard	Structured, multi-field data entry	Filling out a contract; configuring a report	Keeps users from missing information by breaking down a complicated task into clear, step-by-step visual sections.
GUI (Filters, Sliders, Drag-and-drop)	Complex parameter setting or spatial tasks	Scheduling; data filtering; image editing	Prevents mistakes and ensures users don't miss information by dividing complicated tasks into clear, step-by-step visual parts.
Multi-modal (Image + Text)	Visual input paired with description	Uploading a design mockup with annotation	Reduces the effort of explaining things because users can reference an object instead of having to describe it only with words.
Gesture	Hands-free spatial interaction	Waving a hand to acknowledge an alert in a sterile operating room	Allows physical interaction without touching a surface. This keeps users safe and clean in contaminated environments and allows for quick input or acknowledgement.

Output Modalities

Modality	Best For	Example Contexts	Cognitive & Physical Rationale
Push Notification / Alert	Time-sensitive, ambient awareness	Price spike alert; task completion notice	Provides a quick update that the user can process at a glance. It delivers information without demanding a full break in concentration from their primary task.
Audio Summary	Hands-busy or eyes-busy contexts	Status updates while walking; conversational voice agents providing real-time navigation	Delivers information directly to the user’s ear. Removes the need to look at a screen, keeping the user safe and aware of their physical surroundings while moving or working.
Short Text Summary	Focused queries needing brief answers	Definition lookup; single-metric status	Gives a fast answer to a direct question. Users can read a short sentence quickly without experiencing the fatigue of scanning paragraphs of text.
Visual Dashboard	High-density, comparative analysis	Project status; resource allocation	Enables visual trend and outlier detection. Avoids the mental effort of reading data line-by-line and cross-referencing in real time.
Interactive Canvas	Generative or iterative creative tasks	Design iteration; layout adjustment	Allows users to manipulate the output instead of asking an AI to move it via text instructions. Reflects a natural way to interact with the output.
Inline Confirmation	Guided task flows needing feedback	Step-by-step configuration wizard with in-line validation	Provides visual proof that the system recorded a choice correctly. Reduces users’ anxiety about wondering if an error occurred.

Table 1: Input and Output Modality Taxonomy. Use this as a reference during the Task Audit to identify candidate modalities before narrowing to a recommendation.

The following FigureFigure 2 illustrates the cognitive spectrum, mapping how mental effort scales across various interaction methods. This spectrum is a critical tool for designers to visualize the shift from low-effort, ambient interactions to high-effort, focused experiences. By understanding where a specific task sits on this spectrum, teams can identify whether a user needs a “glanceable” output that minimizes mental processing or a high-density format that supports deep, analytical thinking.

Figure 2: The Cognitive Spectrum of Modality. Both input (top) and output (bottom) move from low-effort, ambient interactions to high-effort, focused, and multi-modal experiences, illustrating why the context of use must dictate the design choice. 

With this taxonomy established, the next step is to apply a rigorous method to select the optimal input and output combination. Practitioners must ground this selection process in the user’s real-world environment and context.

Task Audit: A Framework for Modality Selection

To choose the right interaction method, practitioners should complete a Task Audit before interface design begins. A formal Task Audit is the framework that moves teams from assumptions about user behavior to evidence. This process gathers data about the physical, social, and cognitive context in which the work actually happens, which then drives all input and output modality decisions.

Use these four areas of focus to anchor the audit:

• Input Constraints: This addresses whether the user can physically interact with the system using their hands, such as typing or tapping. It often dictates the necessity of hands-free interaction methods like voice input when the user’s hands are occupied by tools or gear.
  • Can the user use their hands to type or tap? A mechanic working under a vehicle might need to ask a question using only voice because their hands are occupied and covered in grease.
• Output Constraints: This defines whether a user can safely and practically view information on a screen. It concerns situations where a user’s eyes must remain focused on their environment, making audio or glanceable visual cues the appropriate display method.
  • Can the user safely look at a screen to read information? A delivery driver’s navigation system should provide audio directions because reading a detailed map while driving through an intersection is dangerous.
• Social Constraints: This considers the environment’s tolerance for audible interaction, either speaking or listening to audio output. It helps determine if a quiet space requires silent alerts or if a loud environment demands a non-audio output method.
  • Is the environment appropriate for speaking aloud or listening to audio? An office worker in a quiet, open-plan space would prefer a silent text notification over a spoken voice response.
• Cognitive Load: This measures the amount of mental effort the user must already dedicate to their primary task. Teams must design the interface output to either minimize mental processing, such as with a quick visual indicator, or support deep thinking with a detailed summary.
  • How much mental effort does the task already require? A surgeon needs a quick visual red indicator during a procedure, while a lawyer researching case strategy needs a detailed text summary to absorb at their own pace.

The audit answers two questions for every feature:

1. What modality can the user physically use to provide input here?
2. What modality can the user realistically process as output here?

Here is how to gather the evidence to inform your task audit. Use one or more of these common UX research-related methods:

1. Contextual Inquiry and Observation

This is the most direct way to capture how people work in their natural setting, and it provides the richest data for identifying physical constraints on both input and output. Observation is necessary because users often perform hidden work: small steps or workarounds they forget to mention in an interview, or environmental details they do not think to describe because they have adapted to them.

 

The Approach: Go to the user’s actual workspace, whether a field site, warehouse, or office floor. Ask them to perform the task you are studying and observe closely.

What to Look For: This method is most revealing for Input Constraints and Output Constraints.

• Input example
  A technician diagnosing equipment who cannot put down their tools rules out typing and points directly to voice input.
• Output example
  A supervisor in a meeting who looks up and down repeatedly from a screen signals a need for glanceable, low-density output rather than a scrolling text summary.

2. Focused Interviews

Interviews surface the mental models and decision points that observation cannot capture. They are most valuable for understanding Cognitive Load.

The Approach: Conduct one-on-one sessions with end-users and the stakeholders who manage the outcome. Use a structured protocol focused on a specific task. Ask for stories about past successes and failures rather than general opinions.

What to Look For:

• The “Why” Behind High Cognitive Load
  Ask users to describe the hardest part of a task. A lawyer may explain that the volume of detail is not the challenge; synthesis for ethical or strategic judgment is. This confirms a need for detailed text output the user can read and absorb at their own pace, not a summary dashboard.
• Process Ambiguity
  Uncover situations that are unclear or error-prone, which identifies where AI capabilities provide the most leverage and what output format will reduce rather than increase ambiguity.

3. Collaborative Workshops

Workshops are essential for defining task boundaries and establishing required fidelity levels. Product managers and stakeholders bring foundational knowledge of system requirements; researchers apply audit criteria.

The Approach: Use workshops to build a shared Task Inventory. Bring designers, engineers, product managers, and business analysts together to map every step of the process. Product managers and business analysts ensure factual accuracy; the research team applies audit criteria to each step.

What to Look For:

• Social Constraints
  Confirm where tasks are performed. A workflow that takes place on a loud manufacturing floor versus a shared quiet library demands very different output modalities.
• Ambiguity and Speed Tests
  For every task in the inventory, apply two tests. First: Does this step require human ethical judgment? If yes, the AI output must support that judgment, not replace it. Second: Does this step require instantaneous execution? If yes, the interface must support fast input with minimal cognitive overhead.

Once you gather field evidence through these research channels, map your findings directly against the Modality Taxonomy. Each concrete physical or social constraint you document systematically eliminates mismatched interfaces. This process strips away design guesswork, narrowing your architectural choices down to the specific input and output combinations that survive the reality of the user’s environment.

When you ground input and output modality decisions in field evidence rather than interface convention, the resulting design reduces adaptation load for the user and grounds your modality choices in evidence. When you base decisions on field data, you move past interface convention and build a powerful case for the resources needed to create the right experience for your users.

Once the audit is complete, the final step is utilizing the Input/Output Alignment Matrix to formalize the connection between user intent and the optimal modality combination.

Input/Output Alignment Matrix

With Task Audit findings in hand, you can use an Input/Output Alignment Matrix to map user intent to specific modality combinations. This matrix is organized by what the user is trying to accomplish in a given moment. This distinction versus focusing on what your AI is capable of doing matters. If intent changes across a single workday for the same user, the interface should respond to those shifts.

Choosing the wrong modality for the user’s context can lead to user frustration. Users might feel mentally drained if a lot of information is delivered through a format that is hard to process, like getting a massive status update only in text. They may also start worrying if an action was actually completed correctly when a precise command is buried within a long chat exchange. Finally, the system can force users into finding clumsy workarounds, making them adapt to the machine’s method instead of working in their natural, most effective way.

User Intent	Optimal Input Modality	Optimal Output Modality	Environmental Fit
Quick Status Check	Voice or Single-tap Button	Audio or Push Notification	Hands-busy, Eyes-busy (e.g., Technician on ladder)
Specific Detail Query	Natural Language Chat	Short Text Summary	Focused, low-density data need
Complex Analysis	GUI (Filters, Sliders)	Visual Dashboard (Charts, Tables)	Desk-based, high-resolution screen
Creative Generation	Multi-modal (Image + Text)	Interactive Canvas	Design or drafting environment
Monitoring / Alert	Passive (background system)	Push Notification or Audio Alert	Any environment; task is ambient awareness
Guided Task Completion	Structured Form or Step-by-step Wizard	Inline Confirmation + Progress Indicator	Focused workflow; user needs verification feedback

Table 2: Input/Output Alignment Matrix. Map user intent to modality combinations using Task Audit evidence. The two added rows (Monitoring/Alert and Guided Task Completion) cover common enterprise and mobile scenarios not captured in simpler frameworks.

When teams coordinate these factors, they can move past the automatic default of adding a chatbot. Visual layouts enable rapid scanning. Structured inputs remove the burden of constructing perfect sentences. Audio outputs serve users whose hands and eyes are otherwise occupied.

The right modality combination respects the user’s physical and cognitive state at the moment of interaction.

A real-world scenario where environmental constraints dictated a shift in design strategy best demonstrates the practical application of this matrix and the broader audit framework.

Case Study: Adaptive Modality for Field Technicians

The Problem: Cognitive Overload in High-Risk Environments

Field technicians servicing high-voltage electrical grids often face a dangerous misalignment of interface modality. Traditionally, these technicians had to rely on ruggedized tablets to access technical manuals and log status updates. However, the physical constraints of the job — wearing heavy protective gloves and working in bucket trucks at significant heights — made interacting with a standard touch interface nearly impossible while on a job site. Additionally, attempting to read complex, text-heavy diagnostic reports on a screen while maintaining situational awareness created a high cognitive load that increased the risk of safety errors.

Research Methods: Capturing the Reality of the Field

To address this, researchers conducted a Task Audit utilizing three specific methods from this article. First, Contextual Inquiry and Observation revealed that technicians often worked in “hands-busy, eyes-busy” states where any manual input was a significant barrier. Researchers observed technicians wearing mandatory thick protective gloves while in the bucket truck, which made precise screen taps nearly impossible and often triggered the wrong commands.

High-altitude environments also introduced severe screen glare from direct sunlight, washing out the display and making text difficult to read even at full brightness. Furthermore, technicians faced the physical safety risk of trying to manipulate and secure a heavy, ruggedized tablet while balanced in awkward positions, creating a distraction that could lead to dangerous slips or equipment contact. These factors, combined with the need to constantly monitor live wires and the surrounding environment, meant technicians could not safely dedicate their eyes or hands to a standard tablet interface, confirming the severity of the eyes-busy and hands-busy constraints.

Second, Focused Interviews with veteran technicians validated the findings from the field. They confirmed that the operational challenges, including the thick gloves, screen glare, and safety risks, were not unique to one location but were commonly experienced across multiple sites, including high-altitude transmission lines and sprawling power substations. This broad confirmation solidified the need for a non-touch, voice-first solution. The interviews also surfaced a critical cognitive constraint: the need for glance verification of vital signs, such as voltage readings and temperature trends, rather than being forced to read a long narrative description of system health. Technicians stressed that their primary need was immediate, unambiguous verification (is this safe? or where is the fault?), not a lengthy diagnostic report, indicating that a text-heavy response was dangerous to their workflow.

These methods confirmed that the environment required a departure from the traditional chat or form-based AI capability interface.

The Resolution: A Multi-Modal Handoff Solution

The resulting solution implemented an adaptive modality handoff designed to mitigate the physical and cognitive barriers researchers identified during the research. While active on a job site, technicians utilize voice input to query the system. This method allows them to remain productive while wearing thick protective gloves that would otherwise prevent precise interaction with a touchscreen.

The AI responds with a short audio summary of immediate diagnostic data. This audio feedback bypasses the challenge of screen glare in high-altitude environments and allows the technician to maintain situational awareness of the high-voltage grid without the safety risk of looking away from dangerous equipment. By providing immediate answers to fault locations through audio, the system meets the technician’s need for glance verification through a hands-free and eyes-free channel.

Once technicians return to a truck and secure safety gear, a system automatically hands off workflows to a 15-inch visual dashboard mounted inside a vehicle. A rugged 10-inch field tablet lacks adequate screen real estate for complex schematics. A larger vehicle display allows for parallel processing of historical trend data and wide electrical grid maps. This case study reflects an actual field audit conducted for a national utility provider. Implementing this adaptive approach reduced diagnostic time by twenty percent and increased daily tool adoption among field crews.

Figure 3: Cross-modality handoff diagram for field technicians. Our solution to deliver AI capability using multiple modalities depending on context was the result of auditing user tasks and led to greater adoption of the tool.

Designing for the Environment

An AI capability is only as usable as the interface that delivers it. Researchers and designers must resist the pull toward the path of least resistance. Building a chatbot is fast and familiar, something we’ve been doing for decades now. Building an interface that feels like a natural extension of how someone already works is harder, and it is the work that matters.

Start by leaving the screen. The Task Audit requires presence in the places where work actually happens: the field site, the warehouse floor, the operating room. The physical and social realities of those spaces are not edge cases. They are the design brief.

The future of AI interface design is a diverse ecosystem: visual, vocal, haptic, and ambient, calibrated to user intent and environmental context. The chat window is one tool in that ecosystem. It is the right tool for specific jobs, and often the wrong tool for the jobs we reflexively assign to it.

In order for us to create the greatest likelihood of acceptance and use of the AI capability we offer users, we must fit the modality to the person and the place.

Where to Start

To get started immediately, run a lightweight version of the Task Audit before your next design sprint. Spend two hours observing the workflow in its actual environment. Conduct three to five interviews with the people who perform the task. Bring a PM or analyst into a 90-minute workshop to build a task inventory and apply the four audit questions. You will not have complete data, but you will have enough to make a defensible modality recommendation backed by evidence rather than convention.

I created a Modality Task Audit Template to help guide teams with moving forward. You can download this worksheet and take it directly to your next field observation. It allows design and product teams to document specific physical barriers before writing a single line of code.

• Download: Modality Task Audit Field Template (PDF)

Inside this Template:

• Step 1: Physical Reality Check.
  An observation checklist to log hand availability, eye focus requirements, and ambient noise levels in a specific workspace.
• Step 2: Cognitive Baseline.
  A scoring grid to rate required reading density and verification anxiety for a given workflow.
• Step 3: The Handoff Map.
  A blank flow diagram to chart where a user starts a task (for example, using voice on a mobile phone in a warehouse) and where they finish it (for example, reviewing a visual dashboard on an office monitor).

We focus heavily on training smarter AI models. We owe equal attention to human interfaces. A brilliant underlying model packaged in a lazy text interface fails. When you observe actual work environments and align interaction modalities to them, you remove adaptation friction.

Modality Task Audit Field Template

Use this worksheet during field observations. It allows design teams to document specific physical barriers before writing code.

Part 1: Physical Reality Check

Observe users as they perform a primary task in actual workspaces. Check all applicable conditions.

State of Hands

• Hands are free for typing.
• User holds a clipboard or a smartphone.
• User holds tools, drives a vehicle, or wears thick gloves.

Visual Focus Requirements

• User focuses entirely on a screen.
• User alternates glances between a screen and physical surroundings.
• User watches live machinery or navigates crowded spaces.

Ambient Noise Level

• Quiet environment (office).
• Moderate noise (busy cafe).
• Loud environment (construction site, loud retail floor).

Part 2: Cognitive Baseline

Rate the mental effort required to complete a specific workflow.

Metric	Low	Medium	High
Required Reading Density	Single numbers, binary states	Short summaries, simple instructions	Legal contracts, complex diagnostic reports
Verification Anxiety	Reversible actions, low stakes	Standard business operations	Irreversible actions, safety risks, financial transactions

Part 3: Handoff Map #

Chart user journeys across different environments. Document required input and output at each stage.

Stage 1: Initial Action

• Location: ________________________
• Input Method: ________________________
• Output Method: ________________________

Stage 2: Context Transition

• Trigger for environment change (example: user returns to a desk): ________________________

Stage 3: Completion Action

• Location: ________________________
• Input Method: ________________________
• Output Method: ________________________

Why Accessibility Is An Operational Capability, Not A Feature

 

Teams can generate UI faster than ever, but they still have to guarantee that what they ship is usable, secure, and maintainable. Accessibility as an operational capability rather than a compliance checklist or end-of-project audit, and what that looks like in practice.

This article has been kindly supported by our dear friends at Level Access, who help organizations create accessible and legally compliant websites, mobile apps, software, and other digital experiences. Thank you!

We know that right now, a senior engineer is shipping a checkout flow they “built” in a single afternoon. AI assistant does the heavy lifting, happy path runs clean, and a rotating chevron spins on the order summary. Two weeks later, engineering gets a notice from customer support: a blind customer using a screen reader can’t complete the purchase because the “Pay Now” control is a <div> with a click handler. No role. Not focusable. Not working.

That gap — between code that runs and a product people can actually use — is becoming one of the defining engineering challenges of the AI era. Teams can generate UI faster than ever, but they still have to guarantee that what they ship is usable, secure, and maintainable.

Accessibility sits right in the middle of that problem.

This is not an article about compliance checklists or end-of-project audits. It’s about engineering systems. Specifically, why accessibility should be treated as an operational capability — alongside privacy, security, reliability, and observability — and what that looks like in practice.

The Audit Trap

For years, the default way to “do” accessibility was the one-time, audit-only approach: hire a firm, get a list of 200 findings, fix some of them, file the report. A lot of teams have now moved beyond this model — and the reason is worth looking into.

Audits do matter. For sales, procurement, governance — they’re essential. When a buyer asks for a VPAT or an ACR, you need one. When legal asks if you’re meeting requirements, you need documentation. Audits serve those purposes well.

But audits don’t help you build accessible features during sprint planning. Audits can cost points during a sprint. They don’t catch problems before merge requests. They don’t scale with deployment velocity. The mistake, essentially, is tackling accessibility as a snapshot when you really need constant monitoring. Six months after the audit, the product has shipped dozens of releases, multiple new features, and a redesigned nav. The report is now fiction. Compliance is not a state you reach — it’s a state you maintain, and complexity fights you the whole way.

The WebAIM Million report, which scans the top one million home pages every year, found that 95.9% of pages had detectable WCAG failures in its 2026 run, with an average of 56.1 errors per page. The number of page elements jumped more than 20% in a single year, likely driven by AI-enabled development and ‘vibe coding’ — and more elements mean more places to break. Accessibility debt behaves exactly like technical debt: every inaccessible component you ship becomes a future remediation project, and the interest compounds.

Any strategy that treats accessibility as a periodic event rather than a continuous property of the system is going to lose.

The AI Problem Nobody Wants To Name

With the scale at which teams now generate UI, the gap doesn’t just persist; it multiplies.

Start with how fast this arrived. In February 2025, Andrej Karpathy coined “vibe coding” — a way of working where you “fully give in to the vibes” and “forget that the code even exists”. You describe intent, the model generates, you accept the diffs without reading them. It was meant for weekend projects. It did not stay there. Y Combinator reported that 25% of its Winter 2025 batch had codebases that were 95% AI-generated.

Models don’t land on non-semantic markup by accident — three forces push them there. Most React code on GitHub uses non-semantic “soup”, so that’s what the models learn. Human reviewers and evaluators judge output visually, so the feedback loop rewards looks, not semantics. And <div onClick> is fewer tokens than <button aria-expanded="true" ...>, so absent a constraint, the model takes the cheap path.

Here’s the thing about AI-generated UI: it’s inaccessible by default. Not occasionally — by default. A developer writing in Frontend Masters tested AI-generated React components across multiple tools and documented the pattern. A typical AI-generated sidebar had ten distinct accessibility failures in twenty-nine lines: no landmark, no heading, no list structure, elements with click handlers instead of buttons, no aria-expanded, no keyboard handling, and unlabeled icons. The accessibility tree — the structure screen readers actually read — came back as flat, unstructured text. “Same pixels” as the author put it. “One is a door. The other is a painting of a door”.

Now connect this to security, because the two failures come from the same root. Veracode’s 2025 GenAI Code Security Report tested large language models across dozens of coding tasks and found that a large fraction of AI-generated code introduced security vulnerabilities — including OWASP Top 10 flaws. Cross-site scripting failures were particularly common, and security performance did not meaningfully improve with newer, larger models. The issue wasn’t model intelligence. It was process: developers generating code without specifying security constraints and accepting output without systematic verification.

The same shortcut that skips the security review skips the accessibility review. At scale, AI won’t close the accessibility gap — it has industrialized the very thing that creates it.

The fix is not to ban AI. Your developers are already using it. The fix is to constrain it and verify it — to treat AI as a very fast teammate who always needs guardrails.

Velocity and Accessibility Are Not Enemies #

This is usually where someone says, “Guardrails? Sounds great, but they will slow us down.”

In practice, the opposite tends to be true.

Shift-left is the entire DevOps thesis, and it applies cleanly here. An accessibility issue caught during design review is a comment. The same issue found in production is a remediation project.

Catching an accessibility issue as a component is built takes minutes. Fixing one after the fact — discovering it in an audit, diagnosing the root cause, restructuring the markup, applying the necessary fix, writing tests — can easily take hours. Multiply that across hundreds of findings from a late-stage audit, and you have weeks of unplanned work that earlier automated checks — whether in design reviews, development workflows, or CI — could have prevented.

Teams that integrate accessibility into everyday workflows avoid the expensive surprises: emergency audits, remediation sprints, procurement blockers, and redesigns that quietly break core user journeys. Accessibility doesn’t reduce velocity. Unexpected work reduces velocity. In-flow accessibility is one way of eliminating unexpected work.

What Enterprise-Ready Actually Looks Like

The organizations that scale accessibility successfully do not rely on heroes. They rely on systems.

The highest-leverage place to start is the design system. One accessible component can be reused thousands of times. The GOV.UK Design System is a useful example: components undergo both automated and manual testing using assistive technologies such as JAWS, NVDA, VoiceOver, and TalkBack. The team is explicit about the limits of automation and supplements tooling with user testing involving people with disabilities. They’re equally clear that using the design system doesn’t “magically” make a service accessible; it just gives you a higher starting point.

Accessibility becomes infrastructure. That’s the lesson.

From there, it moves into the engineering workflow:

• Accessibility requirements are included in the Definition of Done.
• Pull request reviews include explicit accessibility checks.
• Interactive controls use semantic elements (<button>, <a>) by default.
• Keyboard navigation and focus management are treated as standard engineering concerns, not optional polish.

Finally, accessibility becomes enforceable through automation:

• eslint-plugin-jsx-a11y catches common issues before code is committed.
• LevelCI, Pa11y, and similar tools provide automated testing in CI/CD pipelines.
• @storybook/addon-a11y surfaces issues during component development.

At that point, accessibility stops depending on memory and starts depending on the process. It becomes part of your platform.

Patterns That Actually Scale

A few implementation patterns consistently show up in teams that do this well.

Constrain AI Before It Generates

Instead of fixing accessibility after generation, bake requirements directly into tooling through Cursor rules, Copilot instructions, or repository-level standards. Tell the model to use semantic HTML. Tell it when to use buttons versus links. Tell it to expose the state and labels correctly. Models follow persistent constraints far more reliably than one-off prompts.

Stop Hand-Rolling Complex Widgets

Comboboxes, menus, tabs, modals, and similar controls routinely become accessibility hotspots. Libraries such as Radix UI, React Aria, and Headless UI already solve many of these problems. The scalable approach is not about repeatedly implementing accessibility correctly. It’s inheriting accessible behavior from well-tested primitives.

Capture Accessibility During Design Handoff

Focus order, labels, heading hierarchy, and interaction states should be specified before implementation begins. If accessibility requirements are absent from the design artifact, they are often absent from the final product. A simple memo at design handoff — what is the tab order, what are the labels, what happens on error — removes a huge amount of guesswork later.

None of these patterns is exotic. They’re just DevOps and platform thinking applied to accessibility.

The Broader Business Impact

Engineering leaders rarely prioritize accessibility solely because of regulations. But regulations, procurement requirements, user retention, and product quality all point in the same direction.

Legal pressure continues to increase. Digital accessibility lawsuits in the United States have stayed in the thousands per year, and they are not limited to large enterprises. The European Accessibility Act is now enforceable across the EU, applying to e‑commerce, banking, ticketing, telecoms, and more, regardless of where the company is headquartered. The message is clear: accessibility is no longer a “nice-to-have” in the eyes of regulators.

But compliance is only part of the story. The bigger story is the market you leave on the table. The World Economic Forum (December 2023) estimates that the world’s 1.3 billion people with disabilities, “along with their friends and family, has a spending power of $13 trillion”; disabled consumers alone control roughly $8 trillion in annual disposable income, per the Valuable 500.

In the UK alone, the Click-Away Pound Report 2019 found the “Click-Away Pound has risen to £17.1 billion” — more than 4.9 million users with access needs who abandon inaccessible sites and spend elsewhere, up almost 45% from £11.75 billion in 2016. People don’t file a bug report. They leave and buy from a competitor.

There is also a procurement reality that turns accessibility from a cost into a moat. If you sell B2B or to government, you will increasingly be asked for proof of accessibility — VPATs/ACRs or equivalent documentation. According to Level Access’s Seventh Annual State of Digital Accessibility Report, 75% of organizations now require proof of accessibility at least most of the time when purchasing digital products — essentially unchanged from 74% in the previous report, but with a notable shift towards stricter enforcement, as those that always require it rose from 27% to 31%. A strong ACR accelerates the sales cycle; a weak one, or none at all, creates redlines that stall or kill it. For some buyers, this is a hard requirement before your product can even enter evaluation. A strong accessibility story accelerates the sales cycle. A weak one creates redlines that stall or kill it.

Step back and the deeper pattern is clear: accessibility is a proxy for engineering maturity. A team that ships semantic HTML, manages focus, exposes state correctly, and tests it in CI is a team that has its house in order. The same discipline that produces an accessible component produces a maintainable, testable, less buggy one.

For dev and product leaders, that’s the real business case: accessibility work is platform work. It pays off every time a feature ships faster and more smoothly, with less rework, than it otherwise would have.

Systems, Not Sprints

If you take one thing from this, make it this: accessibility doesn’t come from an audit, a hero, or a heroic remediation sprint before launch. It comes from systems.

An accessible design system so components start right. A Definition of Done so they stay right. Automated testing and CI gates so regressions fail the build. Governance, so someone owns it. Guardrails for AI-assisted development so your fastest tool stops being your biggest liability.

None of those practices is particularly glamorous. That’s exactly why they work. They’re the same kinds of boring, reliable systems you already trust for security, reliability, and performance.

But there’s one thing no tool on that list can do. No linter, no automated scanner run, no dashboard will ever tell you what it’s actually like to use your product as a blind person with a screen reader, or to navigate your checkout with a keyboard because a tremor makes a mouse inoperable. So build the systems — you need them, and they’re the only way accessibility survives contact with a real release schedule. But test with real users with disabilities regularly. The first time you sit behind someone using JAWS to fight through a form your team thought was “done”, something changes. The tooling tells you whether you passed. A real person tells you whether it actually works.

Accessibility is not a feature. It’s an operational capability. Treat it that way, and you get something dev and product leaders already care about: a faster, safer, more reliable way to ship software.

Users Don’t Need More Tools: They Need Seamless Integrations

 A closer look at why users don’t need more tools in their daily lives. What they need are seamless integrations of useful features to match already existing, established mental models.

We often hear about shiny new tools that change everything (yet again). But in practice, most people don’t need more tools to deal with in their daily lives. What we actually need are better integrations of useful capabilities that neatly align with our existing and established mental models.

Users don’t get excited about shiny new “smart” workflows, or navigating Terminal commands, or jumping between endless back-and-forth chat interactions. They need seamless integrations of useful features to address problems with high severity, high frequency, and a high level of frustration.

Now, that’s useful: seamless integration of AI features when creating new folders. By Karthikeya GS. 

1. AI-First vs. Quiet AI

I’ve always been puzzled by the notion of “AI-first” products. They might speed up production, but we need to know really well first what we actually want to build. AI-first often doesn’t account for years of small and big design decisions that have shaped expectations and mental models over the years.

A neat Claude Excel integration, with users studying specific rows or columns, instead of switching between tools all the time. 

I love the notion of “Quiet AI”. These are tools that are mostly invisible, sit in the background, and do small tasks on the user’s behalf. They never scream for attention but happily assist in repetitive, frustrating tasks that can easily be automated or assisted with a smart helper.

Excellent examples of Quiet AI include Claude’s integration within Microsoft Excel, PowerPoint, and Word, providing assistance in context without disrupting the user’s workflow.

2. Folder Instructions For AI Actions #

So no wonder that I absolutely love the idea of folder instructions! There, users can define what a folder is supposed to do, based on the purpose they created it for. It sounds much more complicated than it actually is.

Users define instructions, choose system rules, and the system takes care of the task.

The instructions define what the folder is for, how files should be organized, how sub-folders should behave, and what actions can happen inside. Instead of manually maintaining a folder, you set its intent once and let the system follow it.

It’s a seamless integration of AI helpers just when and where users want and need it. With permissions and actions locally scoped to that specific folder on the user’s machine, unless the user extends access, permissions, or system rules on their own.

Users could automate tasks where the work actually happens, e.g., generating summaries on the fly. 

Here are some useful examples:

• For a passport renewal, get the form and collect all the documents I need for it. Inform about missing documents, and fill out the form to the best of your abilities.
• When new invoices are added to the folder, rename them according to the sequence, sort them by invoice number, and organize them in folders by client.
• When a new PDF is added to the folder, generate a summary, send it to my pocket, and send me a notification via email.

Note: For a deeper dive into this concept, you can jump to Karthikeya GS’s wonderful post “Folder Instructions: Instructions For System-Level AI”.

Wrapping Up

User’s value doesn’t emerge from users having to juggle between multiple applications, views, and sources every few minutes. That’s when they are slowed down, and that’s when they make mistakes.

It comes from helping users do the work they need to do — by reducing frustrations, slowdowns and mistakes, and taking care of tasks that otherwise would take too much time and too much effort to complete well.

Yet again, seamless integrations — a very underused but incredibly impactful way to deliver value fast, without adding the burden of installing and learning yet another tool.

 

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.