When we’re designing services I see too much time and energy spent thinking about and designing around fraud. What we need to do is draw a line between people who are using our services with good intentions and honesty, and those people who might be attempting to defraud or take undue advantage through dishonesty.

I’d like to make a clear distinction. Let’s call the first set of people “users”, and the others we’ll call “fraudsters”. The important thing is that these two groups are mutually exclusive. A Venn diagram would look like this.

One person cannot sit in both circles at once, there is no overlap.

We design for users, we put their needs first, we try and create a service which is quick and easy for users to understand and use. We shouldn’t be designing for fraudsters.

We need to mitigate against the effects they might have. We need to try and reduce the damage they can do. But the things we put in place to this end should not have a detrimental effect on the users. If they do, then we are not putting user needs first.

However, the culture of suspicion and mistrust is so embedded that the majority of design decisions seem historically to have been taken exclusively with fraudsters in mind. So the idea of not designing for them seems anathema to a lot of people. The focus has been on them so long.

I think this stems from a kind of availability bias which bends people's minds. The sensational aspects of fraud, the shock of it, the audacity of it, the way it makes such a great story to tell your colleagues, means we expect fraud to be far more prevalent than it actually is.

By the way:

This is the same availability bias which leads people to believe that 15% of the population are Muslim, when actually only 4.8% are. The easier we find a thing to remember, the more often we feel like it is mentioned, the more common we think that things are. Our brains are wonderful things but we are proven to be absolutely crap at intuitive statistics and probability.

And so when we talk about services, when we talk about transforming them, it doesn’t take long for someone to pipe up with the “What about fraudsters?” angle. This is almost always a blind alley. It only serves to muddy the waters. It’s not that fraud doesn’t exist and that it doesn’t need to be dealt with but when you are dealing with a complicated service, with many moving parts, where the user needs are often hidden within a mass of process and technology, it’s important at that point to maintain the most clarity about the intention of the service and it’s purpose.

I’m not arguing here for some kind of fantasy-land, blue sky, utopia with no restrictions and purity of design. Of course, there will be restrictions. We’re all constrained by time, limited funds and most of us are bound by the laws of physics. Designing is never going to be an exercise is unrestrained creativity (it’s not Art for god’s sake!). Security considerations are always going to play a part in the context of design.

Nowadays though as we digitise services, as we design with data and get cleverer about the way we monitor and track the usage of the things we build there are loads of ways of detecting and preventing fraud which need not damage or even slow down the user’s experience. It is our responsibility to use these techniques in such a way as users don’t need to worry about them. This is what we mean when we talk about doing the hard work to keep things simple.

What I am arguing for is a better understanding of when and where considerations of fraud need to be brought in. When discussion of them is helpful and when it is counter-productive. By making a clear distinction between users and fraudsters and sticking to the principle of starting with user needs, we can design better services, make progress quicker, and stay focussed better during those phases of a project where that kind of clarity of thinking is all important.