A deep dive in the “Exit this page” button
Trauma-Informed Design Reflections #5
Introduction
Welcome to the fifth edition of the trauma-informed design blog, a weekly series of thoughts and reflections on the intersection between trauma and design.
This week (18–24 Mar) I’m exploring what’s important to consider when building an “Exit this page” button, focusing especially on nuances, good case practices, and anti-patterns.
How to safely exit a page
What does it mean to have a trauma-informed design system? I often find myself with that question, and unfortunately I do not have an answer for you. But, I may be able to offer some insight on a specific trauma-informed component: the “Exit this page” button.
The “Exit this page” button allows a user to quickly and safely exit a website. It is particularly useful for users who might be at risk if seen browsing that website. Think, for example, of a woman in an abusive relationship looking for help, or of a trans teenager in an unsupportive house looking for information online. For these people, having a quick way out is a huge deal.
This component may seem easy to implement, but there are some nuances that are worth looking at. In this piece I will dive into them, and talk about some best practices and some anti-patterns. Please keep in mind that this isn’t meant to replace user research; the best way to find out what really works for you is to talk with your users. Instead, this piece will hopefully be a good starting point for you on what’s worth considering when implementing the “Exit this page” button.
On the button’s text
This button is becoming increasingly common in websites that support survivors and people in crisis, but it is by no means a widely used component on the web. This means that the lack of descriptive text can result in the user not understanding what this button does or why it exists.
“Leave this site”, “Exit this page”, “Exit site”, “Exit”, “Safety Exit”, “Hide this page”, “Quick Escape”; I’ve seen all these used interchangeably. I would argue that picking a common phrase to use can help users learn the behavior of that button and know what to expect. But regardless, most of these texts seem to be clear enough.
I particularly favor the first three, because they seem to bring the most clarity. “Safety Exit” is very interesting because the button does provide a safer way to leave this site (more on that later), but without further context this can be a bit unclear (safer how?).
I’m not a big fan of the “Hide this page” one because the page isn’t being hidden, it is closed. The word “hide” makes me think of a temporary page disguise, which is not what the button does. Also, I would hold back from using words like “quick”, because the button isn’t necessarily quicker in closing the tab, but it is safer.
In some websites there are keystrokes bound to trigger that button. This is done primarily to support accessibility for users who exclusively use keyboards. It also helps the rest of the users reach the button faster. I really like when this behavior is explicitly mentioned on the button, like in this case from Somerset:
Another approach I really like is the one Refuge took. Their button is initially very long, containing more information about what it does, and as the user scrolls down, it gets shorter.
Do keep in mind, however, that increased text in that button can potentially hurt the experience of users with screen readers. I recommend testing that case in advance.
On the button’s color
In most cases the brand’s accent color is used for that button. This is generally a great choice because it helps the button stand out from the rest of the page.
As far as colors go I would recommend avoiding red or similar colors. Microsoft, in its Mental Health and Cognition: Design pattern guidance states: “Limit use of red-ish colors to errors and urgent alerts. Evidence suggests red notifications are addictive and can easily pull people out of flow.” and “The red badge draws too much attention. It almost becomes too
distracting, especially when I’m trying to complete a task.” (the second quote is a coming from a user and is included in their guidebook) [1]
In contrast to that however, I was once in a training delivered by Chayn, and the facilitator stated that red isn’t associated with “danger” or “error” in all cultures. I have no data on how culturally diverse the Microsoft study was, but I would recommend testing with your users before going with red.
On “pressing” the button
Clicking the button is clearly the primary way to trigger its behavior. As mentioned above, binding a keystroke to it is also considered a good practice; especially when thinking about accessibility.
The gov.uk team took a very interesting approach around that. They initially tested the use of ESCAPE (ESC) as a key that would activate this button and found some technical limitations with it. [2] So instead, they replaced that with pressing the SHIFT key 3 times. They also added “visual ‘traffic light’ indicators” to further clarify that process.
In addition, they talked about accessing this button with Voice Control software. The problem with the traditional way of doing that, is that saying “Click exit this page” out loud can put a user in risk. After testing some solutions they concluded that: “alternative navigation options like the ‘item numbers’ tool for Voice Control are an adequate way for people using voice command tools to discreetly activate the Exit this page component”. [2]
On the button’s position
The most important part when positioning the button is making it very easy to reach at all times. This means:
- Keeping the button visible even if the user scrolls down.
- Making sure the button is present in all screens that include information that could put a user in risk.
- Avoiding forcing the user to make more than one click in order to reach the button (e.g. hiding it behind a hamburger menu).
In general, there seems to be consensus from websites that are using this button about the fact that it should be placed on the right side of the screen. It’s not clear why everybody positions the button in this way, but gov.uk has an interesting github thread about it. [3]
There is less of a consensus on the height in which this button should be placed, and on how it should be displayed on mobile.
I’ve found the button to be easy to spot regardless of the height. There were two exceptions to that:
- When the button was very small and simultaneously on the bottom of the screen.
- When the button was positioned vertically (90° from what you would expect), and was relatively small. In that case, the button was also very hard to click, because the scrollbar seemed to have priority on click events.
On the mobile version of most websites the button maintains its position. Few, choose to change it into a bar at the top or bottom of the screen. I found the following point from gov.uk very interesting on that topic:
After testing whether to continue having the button at the top of the page to mirror the desktop experience, we decided it was too prominent on the smaller screen, potentially putting the user at risk. We also considered interoperability issues with other components within a service, such as the accessibility of drop down menus. As a result, we decided to place the button at the bottom of the page, where it was easy to access, did not impede other elements of the service and was more discrete. [2]
On managing the browser history
In almost every case when the page is changed, the back button option on the browser is disabled. In that way, the user cannot go back to the previous page if prompted, which is an important safety feature.
I’ve found no case in which this button removes the current website from the user’s browser history. It seems that this is very hard to implement technically, especially in multi-tab sessions. However, gov.uk found in their research that users did expect their browser history to be cleared after that button was pressed. [4] They recommended explicitly communicating how that works and educating users on ways to hide their browsing history and delete their cookies. [5]
The mygov.scot website for domestic abuse hides the website’s name from history when the button is pressed which is a smart approach. This, however, only seems to work on the last tab of a multi-tab session.
On loading the new page
It’s important to consider that loading a new website can take some time, especially for users with slow Internet connection. To ensure the user is safe, it is common for this button to open two links simultaneously — one at a new tab and one replacing the old one. The user will be directly moved to the new tab, in order to quickly hide the “unsafe” one.
Even though this behavior seems to be a common practice, gov.uk found that users weren’t able to consistently understand that a second tab was opening. [4] In order to solve this problem they proposed opening only one link while also hiding the content of the current page (by clearing all content and adding an empty div). [2]
On the button’s destination
After pressing the button most sites are navigating users to the Google homepage. Other popular destinations are: weather websites, news websites, and the Wikipedia homepage. In cases where the button opens two links, a combination of those is often used.
A benefit of using the Google homepage is that most people have already visited that website, so it is already cached in their computer. This means that it can open very quickly, often without performing a network request.
Picking a news or weather website can be tricky. News tends to have a negativity bias, so those websites might be filled with scary headlines. For a trauma survivor this can be activating. As an alternative to that you can consider good news websites such as reasons to be cheerful. In terms of weather sites, BBC weather seems to have a very neutral home screen.
Chayn’s button directs users to a Google page that contains “cute baby animal memes”. This has the potential of helping a survivor regulate during a stressful moment. It’s a nice touch.
On persisting the website’s state
Gov.uk found in their research that users wanted to be able to return to the previous state they were in. [4] This is not an obvious feature of that button, especially when the user is not logged in. Storing the current state is technically possible, but it is potentially unsafe. I think that this should be a decision you take after conducting user research.
In addition gov.uk found that users were unable to return to their current journey independently after pressing that button. [4] I personally believe that this isn’t as concerning as it sounds. When a user presses that button (because they are at risk) it’s unlikely that they will return to the website right away. Instead, they will probably wait for a new safe enough situation before visiting again, and this could take a while. If this is the case they will practically be starting a new user journey, not continuing the previous one.
On clarifying what the button does
Gov.uk recommended the use of two supportive pages with this component: one to inform the user about what this button does, and one to provide more information about safety online. [5] You can read more about them here. I believe that these are very useful, and that they aren’t utilized by enough websites.
It is true that displaying an information page when the user first opens a website can feel a bit off-putting in many cases. Furthermore, displaying that information as a pop-up can feel unexpected and result in the user becoming activated. Microsoft states: “Pop-ups often interrupt an individual’s intended action; the resulting distraction and cognitive overload can trigger stress and anxiety.” [1]
A solution to that could be adding an “information” icon or some text near the “Exit this page” button. I haven’t seen that being used anywhere, and it could potentially overwhelm the user. As is usually the case in those situations, testing with your users can provide valuable insights.
On customizing the button
The important idea here is that it would be helpful for the user to have the option to customize where this button takes them. In that way they can pick a more believable destination and feel included in the process.
However, this is very hard to fit in the user’s flow, unless the user has an account from where they can manage it. If your users do sign up in order to use your product, definitely consider that option.
On native apps
I have yet to see this button being used in a mobile or desktop app. I believe this is because websites that provide online resources do not need native clients.
In those environments this button would probably be easier to implement. Most notably it wouldn’t have to manage the user’s browser history or the browser’s back button.
On desktops the “Exit this app” button only needs to close the current program and ensure that it doesn’t run in the background or send any notifications. On mobile, it would similarly have to close the current app (not simply navigate away from it), and ensure that its notifications are disabled. It would also have to open another app in its place.
Hopefully as more services that support trauma survivors become available on native platforms we will see this component more often.
Conclusion
I fear that reading all these might be overwhelming, and if you feel that way I apologize. If there are so many considerations when building a button, what chance do we really have of being trauma-informed in our design?
But here’s the thing, we don’t need to get it perfect; we can’t. What matters is taking steps in becoming more trauma-informed, and step by step, perhaps before we realize it, we will be able to build experiences that hold trauma survivors with compassion and care. Thank you for walking that journey with me. :)
Resources
[1] Microsoft Mental Health and Cognition: Design pattern guidance
[2] Gov.uk Blog Design in government: Exit this page fast with the Design System’s new component
[3] Gov.uk GitHub Discussions: Placement of the Exit this Page button
[4] Gov.uk GitHub Discussions: Summary of user research
[5] Gov.uk Design System Patterns: Exit a page quickly
TID Nuggets
- Being a trauma-informed organization is a prerequisite for designing trauma-informed products.
- “Can we build it?” is becoming less and less relevant. “Should we build it?” and “How do we build it compassionately?” are becoming more and more important.
- Frictionless is problematic. Intended friction is helpful.
- I recently read a very triggering Instagram post before an important meeting. I think that trigger warnings on social media are underrated.
- A website’s text might be the most important component of making it trauma-informed.
Notable on trauma-informed design
This section doesn’t include any personal reflections, instead it includes things that happened in the trauma-informed design field and are worth giving a look at (according to me). Enjoy! :)
- Jax Wechsler’s next training on trauma informed design research is coming up in April (3rd, 4th, and 9th, also depending on time zones). I have attended this training in the past and it is very good. You can find the registration link here. June and July registrations have opened as well. (online)
- The Trauma-Informed Design Discussion Group is an amazing community to join. They offer support, share knowledge, and organize monthly calls on trauma-informed design. I can’t recommend them enough! You can request to join the group using this form. They are also building a really great directory of resources, which you can find here. (online)
(This section does not include promotions. Everything is being shared with permission.)
