Dark Patterns Are Decisions
Dark Patterns Are Decisions
In a recent conversation regarding design governance and operations, the topic of managing design debt came forward. This was great as there was another convo (panel) regarding dark patterns on deck. A chance to get some symmetry and homework done at the same time.
What are dark patterns? Well, they are essentially methods found as a result of a design asking a person to do something that they would not ordinarily do, or outright deceiving the user (several types of them). As a matter of preference, I’ll try not to use the word “user“ because it’s not just a pattern that results in something bad for the person that’s using the system, but often result in a pattern of thought or activity or measurement that often serves to be a black hole to the company/organization as well.
One of the areas of conversation that is worth diving into when talking about dark patterns happens to revolve around the decision that causes these dark patterns to come about. You see, not everything that a developer or designer does is malicious from the outset, but often has its grounding in another decision that happened before it got to the designer or developer. These are decisions such as “move quickly and iterate later“ or “we will get the requirements after we designed the thing.“ These kinds of decisions, and others like them often set fertile ground for dark patterns to arise out of various behaviors.
How do we prevent these decisions that foster, nurture, dark patterns? One Of the first things that we can do is to think thoroughly about the entire course that a product or service needs to take. Meaning we don’t just think about it from the lens of the business, or the lens of the person consuming the product or service. We wanna take a look at every decision which needs to be made, which may include looking at platform limitations. It may be the case that we have to add a form in order to collect a certain amount of information, but because of the platform that we’ve chosen, we need to collect more information in order to kick off workflow to do what the business needs to have happened, so that we could ensure a better customer experience. The decision to use that platform, or decision to not customize that platform is what nurtures the dark pattern of asking for too much information.
Unfortunately, this type of thinking, decision based design, is not the norm for many programs and projects. Because of other decisions which may need to be made, or other fires, we often find decisions, made or not, as the fertilizer to what ends up being the experience regarded as dark, light, illuminating, or defeating. Those persons who are not in the decision making capacity can assist in making sure that the right decisions are made by introducing the right kind of friction to their respective projects. Instead of simply “just making the thing,” the designer offers outcomes as a result of the outputs (“if we design this, here’s what our outcomes are projected to be; if we don’t make this decision here, this is the kind of design debt/fractured experience/etc which will develop”).
Fortunately, dealing with dark patterns is a lot easier than many people give themselves credit for. You have to introduce just a little bit of friction, slow down a little bit, so that the thing that you are designing truly gives both the business and the consumer the best experience. And from that, you’re no longer looking at design as an output to support your business, but good design is going to be what’s understood because your business supports the outcomes that a person/team/organization most needs to happen.