inclusive design

Last week we started looking at inclusive design. In particular we focused on the task of paying people. We started off with the user need:

As a payroll administrator, I need to know a payee’s title and gender, so that I can input them into the payroll system.

We discussed how some systems may ask particular questions because they need that information to pass on to another system to fulfil their purpose. Some of the questions can be difficult to answer like HMRC requiring a binary response. Not everyone can describe their gender with such limited options and being forced to do so doesn’t make for a great user experience.

I learned that gender is not a 1 or 2 dimensional scale. It’s more like a cloud, and a person’s gender isn’t fixed over time. A person’s gender can even shift over a period of days or hours.

We might not be able to control what data we need to provide for external or off-the-shelf systems, but we can be transparent about why we ask for it. We should also look for opportunities to question whether we really do need to collect this data at all.

Time for a mockup

Okay, thinking about title and gender, let’s sketch how we can capture that.

Let’s pretend we’re building a payment service for a company called Sow & Grow. Sow & Grow uses an off-the-shelf finance system called Money Manager.

A screenshot of a standard off-the-shelf payroll system with the following fields: employee ID, title, first and last name, date of birth, gender, National Insurance number, and address

This system allows the combined finance/human resources team to maintain a list of employees and pay them on a regular basis. We’re going to look at a fictitious user, Susan (Suze) Pumpernickel, who had recently joined Sow & Grow as an example.

Suze is fresh out of university and looking for their first real job. While at university they found the space to think about their gender. To look at it and question it with the support of peers who were more in touch with gender identity issues than their family. During that time they came out as non-binary to their friends. They are not out to their parents or family, who they’re currently living with, but want to be out at work. They’re also considering changing their name.

New starter process

Rich: On their first day at Sow & Grow, Suze went through the new starter process which included signing their contract and providing some details so that they could be paid.

While some of the questions above aren’t great, Suze expected that something like this would happen. Even though they’re not entirely comfortable with the answers they were forced to choose from, they just want to get on with their job and avoid having any difficult conversations with human resources.

F: I think this might be understating the impact making these choices would have on Suze. Suze may be accustomed to having to make them, but every time someone has to misgender or mislabel themself, it calls that part of their identity into question all over again.

It’s not easy having an identity that isn’t well recognised or understood by the people around you. It’s also exhausting to have to explain it every time, so many people choose their battles. This form also has no indication of where their data goes. Is it going to be put into an HR system and shared with everyone in the company, for example? Or does it get sent on to other systems which might have different information? Will it be on their post? They probably need to manage which system has what information, so they can have more control over what happens next.

Rich: It sounds pretty terrible. Every time you mislabel or misgender yourself you’re almost lying to yourself to try and fit in.

F: That’s exactly it. It’s hard to be comfortable in your identity if you’re constantly having to re-examine and reframe it every time you meet new people or interact with new systems.

Rich: Suze’s manager would then need to input that data into the finance system below.

This is a pretty standard payroll form. Its purpose is to collect all the information needed so that a person can be paid at the end of the month. One inevitable problem with generic off-the-shelf software is that they have to be a one size fits all solution. In an effort to cover themselves so that they can work in multiple countries, they’ll ask users to provide a broader set of personal information than might be required by HMRC for example.

We can see that the new starter form is derived from the information that’s required on this screen. As this is off-the-shelf software, we don’t have much control over what information is asked for, and how. We could appeal to the supplier of the software with a feature request, or upgrade our plan, but that costs time and money. Is there something we can do with what we have to make it easier for a new starter?

F: I think the pain points in that form are title and gender. They both contain a limited list of options, which may not include the correct option for the user.

For example, I bet that title list follows the usual format of Mr, Mrs, Ms, Miss, Dr, or worse, a list with things like Captain and Reverend, but no options for someone who doesn’t have an earned or inherited honorific, but doesn’t use a gendered title. A common title used by people without a binary gender is Mx but some use others, or none at all. It’s not part of your legal identity in the UK after all.

Rich: It feels to me like title and gender are things that we’ve inherited from legacy systems but are of less value and importance. Especially from the perspective of identifying an individual from multiple data points, and a label people would choose to describe themselves.

Perhaps the only reason we still have these fields is inertia? We’ve asked them for so long, and so many institutions ask them that changing this will take a long time.

F: This is why we should do better. Let’s set an example and help encourage other systems to be more inclusive too.

Rich: Also on a bit of a side note, if we’re all into gender equality then who cares what your gender is, we should all be treated the same.

F: Yup. Why does HMRC even need to know?

Rich: If we take this into consideration then we can look at improving the new starter form. We know that we don’t want/need to ask for a title so let’s remove that question and also understand that asking about gender on day one on a form that only gives binary options is problematic.

We may need this information to pass on to HMRC but we can defer asking the question until our new starters have settled in. Also by giving extra time to gather this information we give Sow & Grow the ability to ask for this information in different ways, be it a conversation in a safe space or by asking new starters to complete an online form in private.

We also have an opportunity to look at and change manual processes. If we provide some indication of who will see this information, where it will go and perhaps, how it can be amended, then Suze is more likely to feel better about completing the form. Transparency about data use can help remove some fears about providing that data.

F: This looks a lot kinder. Sow & Grow will need the information we’ve removed eventually, though, so if this were a real organisation, we’d probably want to take a look at the process for collecting that, too, but I think this is fine for now.

Rich: This feels like a good place to end it today. We’ve done a lot of thinking to explore the problems and we have some good and practical solutions to some of them. Next week we can look at what happens on pay day.