Gender Neutrality Tool
Case Study: Gender Neutrality
A web tool that shines a light on gender bias in web content
Date & Duration: 2 weeks, March 2018
Team: Technical Architect, Designer, Developer
My role: research, journey mapping, prototyping, guerrilla testing, UI design, illustration, data visualisation
A regular client of The Unit came to us to find out if there was a gender bias in the copy featured on their website. An easy enough job, we thought. And it was. One of us could go through and make a note of all the gendered words. But surely there was a quicker, more automated way? The Technical Architect, Mark Wallman, saw an opportunity to flex some devs muscle and create something that could be used for various interesting purposes. The idea was explored further during an innovation day at The Unit and led to an internal project to develop a first version.
To create a tool that helps to identify and review gendered copy on a website in an engaging and efficient way.
A website tool which crawls a given URL for gendered words and presents them visually in an understandable and engaging way through interactive data visualisation. It also acts as a reviewing tool by providing instance-by-instance viewing and replacing of words, feeding these changes into an exportable report for external use.
What did it need to do?
Clearly the tool had to collect information about a website’s content and present it back to the user in a meaningful way. The easiest way to begin that task was to allow the user to paste or type in a URL to a search bar. That part was easy, and we would make it the prominent component on the homepage.
But how would the user like to view and digest that information? How granular would they want it to be? Would they want a percentage figure of male vs female words for the whole website, or would they want to see individual uses on a single page? This was important because it determined a) how the data should be presented and b) how meaningful the tool could be to users.
Who would use it?
We were getting a little ahead of ourselves. It’s easy to presume that a tool like this could be of use to anyone and everyone, so was there really a need to design for particular users? Yes, absolutely. To deliver a truly valuable tool, we should know who would benefit from it (the most), then design for their needs. Finding the primary user(s) would help us answer the questions above about the tool’s purpose and function.
I reached out to my network, particularly those who worked with websites (business owners, designers, content creators) to ask:
a) whether they would benefit from a tool like this
b) how it could benefit them
These were the key user cases I identified from the responses I collected:
- The casual user — would be generally interested to see what the results are for websites they like or use. Benefit: general curiosity.
- The collector — likely to be an employee tasked by a senior to use the tool for internal purposes. Benefit: to be able to collect and distribute the information to others.
- The changer — a content creator, e.g. copywriter, or senior individual who has the authority and means to alter the text on a website. Benefit: they could use the data to review and amend website content accordingly.
Looking for overlap
If I could design for the two most valuable user cases — the ‘collector’ and the ‘changer’ — then the resulting design would, in theory, satisfy the ‘casual user’. So with this in mind I drew up user journeys. I was interested to see where there was an overlap as that would help determine the features and interface of the tool.
I decided that the ‘changer’ and the ‘collector’ should both be able to view instances but while the changer could go ahead and add an alternative word to replace a gendered word, the ‘collector’ might want the ability to flag an instance or word for later action by a senior person.
Searching, viewing and replacing
Initial sketched ideas were discussed and developed with the Technical Architect, resulting in lo-fi iterations featuring two main views after entering a URL and returning results: a ‘summary view’ showing an overview in a graphical way, and a ‘detailed view’ providing an in-depth, textual look at the results.
Early sketches (left), mid-fidelity iterations (right) showing two views — summary and detailed
Search / Understand / Review & Edit / Export Report
In my initial research, some people had said they would want to be able to be able to take away the results in the form of a report, which would make it possible to delegate a related task to others, say, in the office. Export a report — a spreadsheet — and ask someone (a changer, e.g. copywriter) to use it to make changes to the website.
The report feature added a lot of functionality and value to the tool, so it was important to understand how it would work. I had some questions at this stage:
- Would the changes a user has made be reflected in the report?
- Could you export a report with the raw — unchanged — results?
- How could the user understand what information would be in the report?
The most important functions of the tool were becoming clearer.
Making the review task easy
Let’s face it, if someone chooses to go one-by-one through all of the gendered words used on a website, it’s going to be arduous. Plus, the interface was getting a little cluttered with various buttons demanding action from the user. I wanted to make the task as quick and easy as possible, so it needed a rethink.
Up and down, or left and right?
Initially, a sentence with a gendered word in was presented on a card that the user would review, take action, and then dismiss so that it would fade away, allowing the next to rise upwards into view. But what happens if you want to revisit that previous card, or undo? The vertical design was problematic.
Test, iterate, test…
Through a mixture of guerrilla testing in the office, discussions with colleagues and further iteration, the design evolved to include three tabs in the header to afford the main views: overview, review, report. The colour palette also evolved to one which avoided gender associations.
Reducing mental load, removing decisions
Over various iterations the reviewing process evolved from the user actively ‘okaying’ instances, through clicking buttons, to requiring no action if the usage was acceptable. In other words, by viewing a sentence that includes a gendered word without taking action, the tool presumes the user has accepted the use of that word.
Many people using the Gender Neutrality website would be not be in a position to change the copy on a site they are searching, they'll just be curious to see how a site fares. Therefore it made sense to have a summary or ‘overview’ that communicates the data pulled and shows it in a meaningful and engaging way. I felt the best way to achieve this was through using interactive data visualisation.
The appearance and interaction of the data vis would be determined by the nature of the data the tool could pull from a website. So I began by listing out all the different types of data and researched data visualisation techniques, which of course included leafing through Information is Beautiful by David McCandless.
The site is currently in development and there are plans to expand its scope in the future to encompass political, criminal and cultural language.
Get in touch
I'm always happy to discuss projects, past and future.
Feel free to use the form below, or drop me an email at email@example.com