Skip to main content

A better UI/UX for Cookie consent banners

I'm sure you've seen them before; those pesky, inescapable Cookie consent banners!  They typically appear at the top or bottom of websites -- often obscuring important content.  For example, if you were to visit CNNZara, or Unicef today; or, any other news, e-commerce, or charitable website for that matter -- especially those with an international presence -- you'd likely see one; a UI/UX eyesore.  Such Cookie consent banners, ubiquitous and omnipresent, have become the defacto solution for complying with an important part of the European Union's (EU) ePrivacy Directive (ePD).

If you're unfamiliar with the ePD, it basically mandates that websites first obtain a user's consent before storing and/or retrieving any Personally Identifiable Information (PII) about them in and/or from HTTP cookies.  (HTTP Cookies are small pieces of data stored by websites in a user's web browser for easier retrieval later.)  The Cookie Law, as the ePD has become known, not only requires a website to notify its users about any PII it stores; but, also any PII its vendors might store too.  As a result, users have been getting bombarded with Cookie consent notices from every website that they visit.

But are those Cookie consent banners even necessary?  The original intent of the Cookie Law was to protect users' privacy; however, its implementation has actually had the opposite effect.  Rather than increasing awareness, the Cookie Law's instead led to users just blindly closing the banners due to information overload -- often without even reading them first.  In addition, the banners have created numerous UI/UX issues for websites in terms of their placement, copy/language, look & feel, etc.  One major issue with the banners is that they introduce unnecessary friction into the browsing/purchasing path of users.  This is especially true on mobile devices where the banners are often placed at the top of a webpage, taking up valuable screen real estate.

To address such problems, websites such as The Guardian and Amazon UK have started to experiment with novel ways of displaying their Cookie consent banners.  By far the best solution I've come across is ShakeShack's Privacy Badge (see, a small icon that's affixed to the lower-left hand corner of its webpages.  (It's akin to the way in which a back-top-top link is typically displayed.)  Clicking on the Privacy Badge brings up a modal window from which a user can learn more about Shake Shack's privacy policies.  The UI for the badge is dead simple; and, the UX for the subsequent modal is minimal; it's an approach that more websites ought to consider.  An even simpler solution though would be to embed a Cookie consent banner directly into a website's footer, thereby saving users any unnecessary aggrevation from having to interact with it.  After all, the footer's where most websites' Privacy Policy and Terms of Use are located anyway, so it makes sense to put the banner there too.

Regardless of whether any website chooses to adopt ShakeShack's Privacy Badge, most should seriously reevaluate their implementation of the Cookie consent banner -- if only to prevent users from bouncing from their sites or abandoning their shopping carts.  For example, a simple check of the "navigator.language" property in JavaScript to suppress the banner for non-EU countries could be enough for most websites.  (Remember, the Cookie Law only applies to websites that do business in EU countries).  For other websites, remember that nowhere in the ePD does it state that all Cookie consent banners must be implemented in the exact same way; nor has any website ever been sued by the EU over their implementation of a Cookie consent banner.  So, stop following the crowd; put your UI/UX designers to work on a better solution for your website (that still complies with the law).


Popular posts from this blog

Happy Father's, Mother's, Sister's, Brother's, Son's, and Daughter's Day

Today is Father's Day in the US. And to celebrate it, my wife and kids got me 6 pairs of socks, 2 shirts, several packs of sour candies, a $25 Domino's Pizza gift card, and a mug emblazoned with the phrase "Good Man, Great Dad". I'll probably never use any of those things; they're all crappy IMHO. (Well, maybe I'll use the gift card and eat the candies; I love sour candies.) But this post isn't a Father's Day rant about the crappy gifts that men receive in comparison to women on Mother's Day; rather, it's about a conversation that I had with my son Kyle about why there isn't a Brother's or Sister's Day too. To quote him: "The world should really have a Brother's Day and a Sister's Day. If not, they should get rid of Mother's Day and Father's Day. I know it's traditional but It's really not fair."  Clearly, he felt left out! Not wanting to let a good opportunity to have an in depth conversation w

A case for WordPress; or, not your own CMS

I've worked at several major companies thus far in my career; and, at each of those companies, I've had to use an in-house Content Management System (CMS)  to create and modify digital content.  For a long time, I couldn't understand why those companies would choose to allocate time, resources, and ultimately money to create a customized CMS in spite of having functionally equivalent, open source solutions readily available in the marketplace.  What was their rationale for doing so, I often wondered?  Was their businesses so unique that an off-the-shelf CMS simply wouldn't cut it; were the security risks associated with an open source CMS too great of a burden to bear; or, was it because the software engineer(s) in charge at the time simply wanted to showcase their PHP, Java, Python, etc. programming skills by building yet another CMS from scratch.  Well, in the years since I first pondered that question, I've come to realize that the answer is often the latter rea