When to add friction

When building a data platform I’m often thinking about how to reduce friction for my users. I want them to have a great experience that allows them to get/build what they need quickly and easily.

For example, I want to limit the amount of times they need a review from me or a member of my team, by ensuring they can self-serve their request and do so knowing there are guardrails in place to prevent them accidentally breaking something important.

But other times, I choose to add friction.

Typically this is in areas where I want to improve security, reduce risks for the organisation, or influence the users behaviours.

For example, we want to configure our infrastructure as code, because doing so reduces the permissions a user requires, prevents common mistakes and breakages, and forces a review from another person before a change can be applied.

It adds friction, because using the cloud providers UI or CLI is easier and quicker, but for us the trade-offs are worth it.

Similarly, with our implementation of data contracts we deliberately chose where we want to reduce friction, and where to add friction.

For example, a non-breaking change to an existing contract is an operation that can be made with low friction. Just create a PR and have it reviewed by another member of your team.

However, we deliberately add friction when a breaking change is required. We have checks in place to prevent a breaking change to an existing contract, forcing the user to create a new version of a contract.

They then need to consider how to migrate users to that new version, which encourages them to discuss the change with their consumers. So now, the friction we’ve added is driving the behaviours we want to see.

There’s no single rule for where and when to add or remove friction. View it as a lever you can pull to manage the risks you need to manage and to encourage the behaviours you want to see.