Who are we willing to exclude?

This is an exercise I like to run at the start of any project.

It’s based on a tweet a long time ago by Jamie Knight (and Lion, of course) which I can’t/won’t link to because, well, twitter. You can read Jamie’s bio on their site or LinkedIn profile.

The exercise is simple. At the start of any digital project, get the whole team – devs, testers, writers, designers, stakeholders, literally anyone you can round up – together, in-person or virtually, and ask the question:

Who are we willing to exclude?

Depending on the people in the room, I sometimes seed the debate with a few groups of people or other things we might choose to exclude. Some examples might be:

  • People who are blind
  • People who can’t turn their volume up because of their situation
  • People who have vision impairments
  • Search engines
  • People who can’t distinguish certain colour combinations
  • People whose first language is not English
  • People who only have access to an old mobile phone
  • People whose internet connection is slow
  • People who use a voice interface to interact with a web UI
  • Bots
  • Power users who use the keyboard rather than a mouse because it’s faster
  • People from certain geographies

You get the picture. It doesn’t need to be an an exhaustive list. Just a starter.

Give everyone 10 minutes to think of anyone, or anything, else that we might choose to exclude. For any reason. Technical. Architectural. Accessibility. Legal, even.

The meaty bit

When you’re done with that, ask people to move the notes into the “We will exclude” column.

In my experience, very few, or even no, stickies will move.

Well, maybe the AI or bot ones. Possibly some geographical ones if complex IP issues are involved, or there are sanctions issues at play.

What next?

Well, you’ve decided who you will exclude. So how are you going to do that?

There are actually good reasons to exclude certain groups.

It’s perfectly valid to, for example, block access from mafia states, or AI scrapers that want to train their models on your content for free. Or to block access from certain geographies because of IP or other legal restrictions.

What’s left is who you will, necessarily, include.

So, start to think about how you’ll do that.

Move or duplicate the stickies left in the “Who we could exclude” column to a new board, headed “Who we will include”.

So now you have a chance to think about who you will include in your design process, and how you’ll go about it.

Basically, this is your design strategy emerging. From a workshop you can do in an hour.

Why do I do this?

We talk a lot about being intentional in our design. We should be equally intentional in what we don’t design – the edge cases. The things we let slide into our mythical backlogs, or continuous improvement buckets.

If you ask people to intentionally exclude others, they don’t exactly queue up for it. They know it is not a good look, even if it’s what they think.

So you arrive at a team commitment, which everyone has accepted. And, as an agile team, we hold each other to that commitment. That’s what agile teams do – we are accountable to each other, and we hold each other to account.

These things may affect a small percentage of users, but 0.01% of 10 billion people is still ten million people.

And anyway, the numbers are irrelevant. Everyone has a right to access the information we publish and the services we provide. They are human. It’s a human right to be treated equitably.

Post by @joelanman@hachyderm.io
View on Mastodon

I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.