Your Products Will Never Be Used as Designed

4 min read

As the quote goes "no plan survives first contact with the enemy". When designing and building products, you never truly know how people will use them until you put them into market.

Design processes are largely formed around a Golden Path. That is to say the optimistic usage of a product. Design artifacts like personas and user journeys are idealized narratives of who and how the designer imagines the product will exist in the market.

On the beneficial side, when someone uses the product in ways you never imagined, it is very encouraging. This opens the door to create new forms of value that were previously not considered.

On the harmful side. It is horrifying when people use the product for harm. For many years, Designers rarely thought of adversarial or illegal uses of their products. The number of Design processes and industry standard artifacts for gaming out these threats are far fewer than those that sell a shiny happy product to leaders and VCs. The majority of adversarial planning was centered around intrusion of the system (hacking) than harmful usage of the product.

If you accept that whatever you design will be used in unintended ways then then how do you design? People fall into two camps.

1) Plan harder - many people will argue the answer is better planning. On the beneficial side, more user research, more usability studies could uncover unmet needs or hacks people will employ when using the product. On the adversarial side, more red team exercises, ethical frameworks and increased rigorous reviews before shipping can mitigate risk.

2) Be like water - the other approach is reactive. Build the product to maximize for flexibility and responding to the market. This approach treats product development as a big feedback loop. As long as you can respond fast enough you don't have to anticipate the unintended usage you just need to react to it.

Of course the answer is, you need a bit of both.

Option 1 will never completely work. As Thomas Schelling wrote: "One thing a person cannot do, no matter how rigorous his analysis or heroic his imagination, is to draw up a list of things that would never occur to him." (forgive the gendered pronouns).

Similarly, Option 2 will fail since no team can fix things as quickly as millions of users can break them.

In a startup, option 1 is too much process and too slow. The prudent path is option 2. If the product is successful it will scale exponentially and the team will not be able to keep up.

In larger more established products, there are more formal processes and resources to try and mitigate unintended usage but launching new features means there are a lot of potential users on day 1. increasing the odds that people will bend the product to their will faster than you can respond. This is why large companies will try and roll out in smaller tranches to mitigate risk (e.g. 1% tests, country tests, 20% tests). This does uncover issues but many of the beneficial and harmful uses only emerge with time.

Coda

One of the first products I worked on at Facebook was check ins. The ability to create a post with where you are. In North America, this was largely used to communicate status "look at this cool place I am at and you are not.". But in parts of South East Asia it was used as a way to gather friends (come to this spot) and even more importantly for personal safety. Young women would use it as a way to broadcast "this is where I was last seen" to friends and family in case something were to happen to them.

This use of "check ins" was not something the product was explicitly designed for but was well suited for this use case.

Whenever North Americans would snidely comment "who still uses check ins?", I would tell this story.