Inclusive design: paying people part 1

When developing something, it can be easier to focus on “core users” and neglect what we think to be outliers or edge cases

Every month we get payslips from employers and these seemingly innocuous things can sometimes cause frustration and anxiety for some people. When developing something, it can be easier to focus on “core users” and neglect what we think to be outliers or edge cases.

The truth is that these edge cases are a lot more common than we think and in the same way that changes for accessibility improve the experience for all users, the same can be said for being respectful of all our users. When we try and make a product or service better for our edge case users, we actually make it better for everyone.

This is the first post in a series which will look at the example of designing a new employee and payroll process in an inclusive way. We’ll be exploring some of the problems of payroll systems that don’t use inclusive design. We’ve also included some examples of what a payroll service could look like that would improve the experience for everyone, and some conversations that we had about this type of service.

What’s the user need?

To keep this post grounded in reality, and so that we can provide some practical ways to improve our services and products, we’re looking at a specific issue with payroll. We’ve summarised this with a user story:

Why does payroll want these things? For identity verification and because HMRC requires it.

Some payroll systems require gender, title, and other data points as part of their identity verification. These systems may need to pass this information on to HMRC so that they can correctly calculate tax or national insurance. While we can certainly argue that some data points shouldn’t be used, that’s a problem for another day.

Payroll systems may also want specific information for other reasons such as pay related communications. Companies may want to maintain an air of formality and choose to do so by including a title in their emails. After all, this is a professional email from an employer and they’ll have a specific tone of voice that they’ll want to use. They may also want to show that they’ve taken a personal interest in the individual by adding bespoke parts of the email for them. It’s that content design balance of professional and personal that we need to resolve.

Why could this cause problems? You can be oblivious to the unintentional problems associated with asking questions like this. But then designer training kicks in and you remember that you’re not the user, you have to limit your bias and assumptions. You need to explore each change and see how it can impact the product or service as a whole.

One approach is to assume this is a problem and try and work out why. I’ve done some reading and know that gender is fluid and it’s non-binary. And that where a person identifies on this scale can change over time, for good and bad reasons.

Let’s talk about gender

F: Can I interject for a second? This is only part of the picture. Gender is fluid, but it’s not represented well by a scale.  It’s more like a cloud (or as my favourite sticker says: a universe). People don’t all fit somewhere between “man” and “woman”, and some people don’t consider themselves to have a gender at all. Where would that go on the scale?

For some people, gender shifts over time, but the time between those shifts might be measured in days or even hours. One day they might feel close to “man”, but the next, closer to “non-binary woman”, for example. Even if you consider gender as something that shifts over time, it might be different when the user ends the journey from when they started it.

It’s also worth pointing out that while “non-binary” can refer to a specific person’s gender or apply as an umbrella for many genders that are neither “man” or “woman”, there are also some people whose gender doesn’t fit into a binary who would rather not be referred to as non-binary (myself as an example). They might prefer specific gender terms like genderfluid, genderqueer, or agender…

Rich: So let’s take a second and break that down. The idea of a cloud to (forgive me for saying this) “define”…

F: Try “describe”.

Rich: Okay, thanks. The idea of a cloud to describe gender is an interesting concept and perhaps something that someone like myself wouldn’t have thought of initially. I understood that it was a complex thing that changed over time but it’s interesting that even though I was trying to be thoughtful and considerate I was still not fully appreciating the problem. 

F: This is why it’s important to talk to your users!

Rich: Yeah, my personal experiences really seem to have constrained my appreciation/understanding of this, so not only do you need to think about why, but also why you think that.

F: Yup!

Rich: Okay, so not all people fit in the categories of “man” and “woman”. It’s a good start down the path to understanding, but it’s a lot more complicated than that.

I also got that people might identify one way, then over time feel like their identity shifts but I didn’t think the speed of that mental change could be as quick as the time it takes to complete the user journey.

F: Don’t forget that an interaction with this service can be a trigger of sorts in itself. People may get gender feels due to the sorts of questions they’re asked, and have their identity shift with it. This stuff is complicated!

Rich: So one apparently innocuous question can change how a person identifies, as they try to answer it?

F: Yeah. If you ask someone about whether they’ve been in a leadership role, for example, that might bring them closer to the aspect of their gender that they experience most in those situations, and shift their perception of how they fit into the world.

Rich: I guess this is also compounded because they may have identified one way when they signed the job contract, then a week later identified another way when filling out payroll with HR.

F: Yes. Though bear in mind that most people who experience this are at least partially aware that their gender identity changes over time or in different contexts. This is often what the term “genderfluid” is used to mean.

How can we ask these questions in a sensitive way?

Rich: It’s really difficult.

I think we should look at the reasons why we’re asking these questions and challenge the need for them. It might be that a payroll system needs a gender or title, but perhaps we can tailor the form so that we don’t need to use these pieces of information again?

F: This sounds great. How much control do we have over those systems? Can we see how that data will be used now, or might be used in the future?

Rich: I think it’s safe to assume that we only have control of the systems we actively build or work on and even then the amount of influence varies. However, if we can find why our downstream data users want this information and prove that they don’t need it, perhaps we can provide a stock answer or none at all if the payroll system doesn’t use it as part of the output.

F: In that case, let’s try to do the least harm. Some of that will be about informing our users how their data will be used, even if it’s to disappear into a black box at HMRC.

Rich: Yeah, transparency and honesty don’t make a question less difficult, but I think it can certainly help. “We are sorry for asking but we need to have this bit of information so we can do this thing for you.”

F: Let’s have a go at building a mockup, then, and see where we are?

Rich: It’ll take a bit of time to create the mock up and this seems like a good place to end it today. Shall we pick this up again next week?