Interruptions and Garden Paths

When we talk about accessibility in software we usually talk about screen readers, tab-ordering, alt texts, colors, contrast, and the WCAG standard. But consider this: according to Forbes Health in 2023, more than 8.7 million adults in the U.S. have been diagnosed with ADHD. The rate is now over 10%, which means that except in specific niches you likely have far more users with this or another executive function disability than any other.

I myself have ADHD (diagnosed by a professional). I use software for 8-10 hours in my average day. I can tell you that the software I use has a great impact on my productivity, and that's the case for others with my condition.

If you're designing an application that is meant to be used productively, you should be designing for ADHD. The good news is that designing for ADHD improves your software for everyone. It will improve your NPS and CSAT directly, because what it's about is driving task-engagement and maintaining clarity of purpose.

Interruptions

See what I did there? Honestly, if I were to click on that Subscribe button above and it navigated me off the page to congratulate me for signing up, there's a good chance I wouldn't make it to this part of the article. I'm not always that distractible, but the longer I've been working, and the more things that have gone onto or come off my mental pile of "things to write down or take care of" the more likely that I look up at the back button of my browser and my eye tracks across a tab I needed to do something on.

Sometimes your software has to interrupt someone. Sometimes they type invalid data into a field. Sometimes the calendar needs to remind them that they have a call in 5 minutes. Sometimes the system experiences service interruptions.

The point is that if you're going to fully interrupt the user the reason has to be critical. And I'm going to define what I mean by critical: If your user were to continue operating your software without dealing with the interruption it will cause them to lose data or greatly degrade their experience.

That's not to say you can't have visual cues on the screen for things like "oh, hey, try this new feature!" There are degrees of interruption. They will still degrade my experience, and I'd love a checkbox in your app's Settings that let me turn non-essential notifications off or simply dial down the noise a bit. But I understand the need to engage in in-product Product Marketing. Just don't make it a modal.

Degrees of interruptfulness in notifications:

1. Modal dialog. Pops up on the screen and I can't do anything else until I clear it. Use these only for critical notifications.
2. Ever-growing stack of notifications in a default-on feed. This just feels like a to-do list I have no control over, and the longer it gets the more anxious I get. Ask me how I have my Macbook's notification center configured...
3. Brief notifications that clear themselves after a few seconds without forcing me to look away from my task if my attention is at a critical moment.
4. Badges.
5. Blissful quiet.

The longer you can keep the application in degrees 3 or higher, the more productive someone is, and ironically the more likely they are to pay attention closely to the content of items in degree 1. The more modals there are, the more likely I'm going to click "OK" without reading it when I am trying not to lose focus.

Honestly, the biggest cause in my experience of these kinds of problems lie in design or workflow afterthoughts. And I actually mean "afterthought" literally. The problem is introduced when a feature is basically in release testing or UAT and someone catches an edge case, or realizes something was missing from the design, and the easiest thing to do is to pop up a banner or a dialog to cover it. This is the point in feature development when the team is feeling the crunch and reworking design to incorporate the item correctly is going to cost a lot. It's tech debt, really, but once it's in production that way it's unlikely to get taken care of.

Overall, my advice here is to think about your user's attention span and what you're asking of it. In workflows and tasks that require concentration (even filling out a form) the less you pull them away from that task, the better.

Garden paths

The more subtle problems than interruptions in your app are garden paths.

Poorly designed components or screens. Take a list of people. If I'm looking for a specific person in a list, and I can't put it in alphabetical order then I have to scan it line by line. Now if I'm familiar with these people then the chance that I remember something about one of them as I read their name is high. That reminds me of an email I meant to send or something I promised them I'd do, and it might feel compelling enough that I switch tabs and leave your app, then come back and have no idea what I was doing.

Workflows that drag you all over the place. Ahhhh, MyChart, how I loathe thee. Let me count the ways. I click an email to check lab results on the web client. That takes me to the login page. I have a password manager, so first I unlock my password manager, then it enters the username and password for me, then MyChart sends me a code, which I have to unlock my phone to find (dangerous, so much Reddit to catch up on!), then I enter the code, it asks for my birthdate and to confirm contact details that haven't changed in 5 years. Reminds me forcibly in a modal I have to close that I haven't uploaded my insurance card to the portal (everyone who needs it already has it), and then it forgets the email click and I'm belched out onto the homepage where there are a dozen notifications I have been ignoring, but I suddenly read hoping that one of them is the link for the lab results so I don't have to go find the email I clicked again. It's not there, of course (but the 7 year old notification for my old doctor who changed practices before I moved is), so I have to open my email again and try to find it. But one of my dear readers has written me and made a great point, and I realize I want to go get it into a draft post before I forget it.

At which point it will be most of a day before I remember to do it. And instead of stressing myself out all over again, I will literally make a 15 minute appointment for myself on Friday to remind me to do it again because I just can't deal with another garden path today.

The most galling part of this "workflow" (can "flow" really be used in any word to describe this?) is that no-one wrote it. Instead it's an unholy confluence of lazy design and coding choices combined with real regulatory requirements that results in someone like me having to set aside specific time where I force myself to navigate all the way through it without distraction. Each individual feature that I run into on my way is in service of some other purpose – plus one bug where one of the many notifications causes the forward destination to be lost to the browser app.

That's an extreme (if real) example, but there are other garden paths, such as ones where the app knows what you need to do but forces you to stop what you're doing and go through the motions to satisfy it:

• "to enable editing this field, please navigate to Settings > Labs > Layout, and Check 'inline editing of subtitle.'"
• Or where I have to copy structured data from one part of the app into the one I'm working on, even though the link between the two should be obvious.
• Or where to avoid a conflict, I have to check another screen than the one I'm on, even though again it's obvious to an algorithm that the screens would be in conflict.

I really think AI agents may be a great way to generalize solving these garden path problems. If an agent can understand your intent, it can make a non-intrusive suggestion making the change or pulling the content in from the other part of the app that's obviously relevant. Providing an avenue to train an agent on common clickstreams and on places where data is entered redundantly in an app may make it possible to write a generic agent that solves such cruft as a service.

Even without them, though these problems are avoidable. Engineering and Design should work together on design and workflow, and practice should be put in place to prevent people from glossing over these problems until they're too late in the development process to design well.

Making it real.

I have actually seen inattention to this design sink NPS, feature acceptance, and renewal numbers. It's not that people are clamoring for ADHD accessible design, but that lack of attention to the details that matter to people like me slows everyone down and makes your application more full of friction.

When I saw it happen, we were trying to get a major feature out before a hard deadline that there was no way to avoid. Somehow, someone had missed ever specifying that lists needed a sort order to them, and so all the list components for the entire feature, whether they included names, vendors, dates, whatever, were all in database insert order and couldn't be changed. Because it wasn't part of a standard and the team was new and not practiced, no-one caught the mistakes until they compounded in front of angry customers who had already been told they had to wait to do a big yearly thing with our product until after we'd made the change-over.

The result was that the new interface took around 30% longer to use and more clicks than the old one did. And although it would crush people like me, even for people who trend more neurotypically in their attention span were frustrated as hell because it seemed like we just didn't care about their time or their usability.

Wrapping up

I got a bit longwinded today, so let me recap:

• For any given productivity application, more than 10% of your userbase has ADHD or another executive dysfunction that can make everyday usage more difficult.
• Designing for ADHD accessibility increases CSAT and NPS across the board because it takes everyone fewer clicks to do what they came to do.
• Failing to include ADHD accessibility in your designs risks CSAT and NPS if standards around workflow consistency and clarity are otherwise too lax.

To design for ADHD accessibility:

• Minimize artificial stopping points
• Design (or train AI agents to help your users through) workflows that carry them from one task to the next towards their goals.
• Train Engineers and Designers to work together on workflow and design and not gloss over the kinds of details that end in unwanted dialogs and notifications or arbitrary garden paths in your products.