In true form, this article’s topic came about as I’ve had the opportunity to bring Design Literacy into organizations, with one of those manifestations being through the selection of tools one uses in Design departments. The process of choosing Design tools is always riddled with assessing a variety of factors, such as cross-collaboration virtuosity, learnability factors, multi-platform capabilities, integration with pre-existing tools, costs, among others. It’s at the point of choosing tools, or creating a document proposal on what to invest and how to invest, that one wants to have a clear case that substantiates what each of those tools entails, and what is being advocated for. During these periods of trial for unknown tools, is when questions appear, but also when one starts realizing how these products behave, their ecosystem, patterns, which extends beyond the product itself, but how the organization selling it behaves towards its current customers and potential buyers. And it’s at times like these that a Designer needs to understand how to evaluate a product, not only as a professional who understands the genesis of these tools, but also as a consumer who will be using them. What I’m illustrating of course, is focused on the Design discipline, but the topic for this article extends far beyond it. Much to my dismay, I’ve been witnessing more and more the pervasiveness of certain dark UX patterns, which are seeded throughout product experiences, invariably leaving high levels of discomfort, frustration and dare I say it, repulsion. This article aims to bring forth considerations on these topics, and how invariably lacking attention, thoroughness on Product Design approaches, can be met with dire consequences for Organizations in general, and the Design & Product teams bringing these experiences into market.
Dark UX Patterns. There’s a considerable amount of articles on Dark UX Patterns, what they entail and where they can be observed. I recommend reading this article on that topic from Princeton University. The article succinctly defines these patterns into the following buckets: Sneaking, Urgency, Misdirection, Forced Action, Scarcity, Social Proof and Obstruction. These are in reality tactics and interactions that can be found in Digital products, produced/devised with the intent to coerce users into an expected outcome. For the sake of this article, I’m going to illustrate two distinct situations, that illustrate how these types of behaviors are embedded in products with large footprints. The following section of this article focuses on why some of these considerations come into play while the Design Thinking process is taking shape, and the consequences that may be produced in the aftermath of these decisions.
The first situation I want to illustrate came as a direct result of a Design Audit I recently conducted. This Design Audit was a response to a need to identify patterns, behaviors, metaphors, artifact considerations exhibited across a product suite of a variety of product offerings. As the Audit progressed and was divided into logical sections, one of the items tackled pertained to Help Centers/FAQs/Communicating with support teams. We collectively decided to unify this experience across all products, essentially creating a Help center, which functions as a central repository for all information regarding all products on the suite, with additional information available in the shape of tutorials, FAQs and the opportunity to submit questions/tickets to the support team directly (while also contemplating the addition of chat bots for instance). This strategy is of course devised and applied by other Organizations on the market, namely Invision and Marvel being two of them. Having used these tools quite frequently and for some time, I’m always pleasantly surprised by the transparency of their process in helping users, their follow up, even if at times, there are glitches, and the user never really knows if the question submitted did go through or not. Theirs is an example, of presenting a feature, and delivering on the premises of what is being promised. In the context of the Jobs To Be Done philosophy, the phrase would read: “I want to get help with the Freehand tool, so that while I’m in a Remotely held Workshop, I can collaborate with my team members effectively”, just as an example. While Invision & Marvel adopt a clear enough stance on how users & clients can reach out to get clarification on their issues, while doing additional research on this topic, I also went to the Adobe website. Adobe has a huge legacy on the market, and I should also say that I love using their products, have taught classes on how to use their products, but their Help center has a series of situations that are somewhat puzzling and illustrate some Dark Patterns. While looking for issues pertaining to some application crashes, I kept being routed into their community page, which in itself is a rather common tactic (Envato does the same for instance), however, they also make a Contact Us button available on their Help center, in the main navigation hub, and also within the pages themselves. However, clicking these hyperlinks will either get you nowhere, or direct you back to the Help center. Essentially, there’s no contact us, it’s a misdirection, which intentional or not, produces frustration in users. Now, more so than ever, when so many users are on their own, it’s important that transparency exists across products being delivered to the market or already within the market. In this particular case, if there’s no direct help, no way to reach out to understand or clarify an issue, be clear to users on that. Making users & clients go in circles, only not to get a satisfactory response, produces a distaste towards the brand, the product, and we’re at times where the monopoly of solutions no longer exists.
The second situation that I’d like to illustrate pertains to Social Proof and statements of veracity of product quality. A variety of businesses create Lead Capture Pages, which include in their body, social proofing of sorts, typically client statements advocating the use of a certain solution or endorsing some (or all) of the services. Social proof is a pattern that can and should be taken with some reservations, particularly in Product Pages or Webpages such as the one I mentioned, mostly because users have no way of confirming the veracity of statements. While Honesty is a Design principle that everyone should abide by, statements that fall under Social Proofing can be manicured or doctored, in order to further boast whatever product or service is being sold. Again and for the sake of providing actual real context, while researching for a substantial re-branding effort I recently did, I skimmed and researched through a series of Web Products, with the intent of understanding how organizations are utilizing Social Proof and UX Copy (Copywriting) to convey their messaging. And again while some organizations do it sparingly, clearly identifying the subject and organization affiliated with the statements, some others pile on quotes, without much consideration to veracity, authenticity or for that matter, credibility. And users, potential clients, appreciate reading some of these statements, since it corroborates decision making processes (much like the Laws of UX indicates, specifically Hick’s Law, the time it takes to make a decision, increases with the number and complexity of options to choose from). Further applying this to a case directly pertaining to my consumer experience, I went to Envato to purchase a WordPress plugin in order to have a more usable portfolio for a website I was building. I needed something usable, cost effective and while looking at the considerable list of options, I looked to reviews, and comments available on a variety of them. In hindsight, one should always probe deeper and investigate further, but there are time constraints driving some decisions. I ended up buying a plugin that was for the most part effective, until recent updates to it, produced outcomes that are both unexpected and undesirable. Once the process of getting support to handle some of the issues started, the darker aspect of client support, and what underlines some of the veracity of social proofing came about. To this day, I still haven’t gotten a response to my issues, but my point can be summarized with this statement: unless your product and services are consistently usable and reliable, don’t create hyperbolic statements or worse yet, pass them as “socially proofed” statements. Users will likely be frustrated, and less likely to ever purchase your product, and worse yet, start leaving reviews, comments throughout social media, generating a bad brand perception that will take time to overcome.
Dark Patterns in Design Thinking Processes. After reading articles on the topic of Dark Patterns across a variety of publications, one may ask why are these even considered, and why are Design teams and their Co-pilots in the Design Thinking process advocating them. Firstly I should state, that in Design Thinking processes that truly abide to its fundamental principles, these patterns should never be contemplated. Design Thinking processes are essentially about uncovering solutions that resonate with clients and users, doing so in a flexible, agile manner, simultaneously creating unity between diverse team members while also delivering financial rewards to the Organization, results that are measurable, quantifiable and rewarding. The process also aims to promote brand advocacy and expand its footprint, and that of course can’t be done while relying on practices that are not transparent. And while these are topics always being discussed across a variety of publications, it should always be stated that Designers and their teams, should always and as a matter of principle, put the interests of their Users/Clients firstly, while also considering all the other factors that permeate in the Design thinking process (internal product strategies, market awareness, competitive edges, among many others). There are decisions that are made in the context of an ongoing Design process that at times pertain to scalability of implementation of certain services or features. For instance, creating a Help center with the inclusion of contact forms going to customer support groups, may be something that a small organization can’t handle if they’re expecting a lot of issues or feedback. Therefore, while creating the product or feature, be transparent about how clients/users can solve their issues. Being honest in Product approaches (I’ve written an article on this topic as well), is always the best stance: users and clients have expectations mitigated, and as the product evolves, these are additions that can be considered and deployed. While in the Design Process, understanding the path that lies ahead, helps Designers and their teams strategize on what the solutions should (and can) be, testing them accordingly, iterating, and as time permits, deploying these ever evolving solutions. When dark patterns and situations prompting them occur, is typically a best practice to discuss it thoroughly, understand its consequences, and avoid at all costs going down that path.
Reality Check. Every Design and Product Team wants their solutions to be all encompassing and as resonant with users/clients as possible. It’s a fair ambition, something that brings results for the Organization, to the brand itself, a towering expansion of client retention and footprint on the market. However, the sense that solutions have to be all encompassing and immediately solve all issues upon release, should be reconsidered. Chances are, products and solutions that are effectively Designed and considered, will be long lasting, and therefore as clients/users evolve, so do these products. Creating a lasting relationship with a user/client is much like any relationship: based on transparency, respect, honesty and the ability to listen.
I’ll conclude this article with a quote from one of the most well known authors in the world, William Shakespeare:
“No legacy is so rich as honesty.”
Dark UX Patterns, Client Losses & Staggering Costs was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.