Design thinking, rapid prototyping | PaySwap App Concept

Below are the annotated slides from my final presentation of PaySwap to the class.

Everyone wants to address the gender pay gap - especially women themselves! In fact, women are often blamed for being part of the problem, by not being assertive enough when it comes to pay negotiations and "asking for what you want". But when there's so much secrecy around salaries, how do you go about figuring out how much you should be asking for and whether you're asking for enough? The PaySwap Project is about empowering women by helping them to close the gender pay gap themselves.

So what’s out there already? There are tools out there for assessing what you’re worth — salary reviews conducted by recruiters, online tools like Glassdoor and PayScale. Governments have a few toolkits encouraging businesses to tackle the issue. And there’s no shortage of media coverage on the pay gap, and content aimed at encouraging women to negotiate harder.

But where are they failing? Many are not available in New Zealand first and foremost (which is where I’m aiming this project). Most are not focused directly on closing the pay gap. And crucially, many tools like Glassdoor and PayScale have old or inaccurate data when it comes to evaluating what you should be earning - they might be very useful for one industry, but highly inaccurate in others.

Going wide with initial user research, I asked, what are women’s current experiences with the pay gap? What ‘hacks’ are they already implementing to figure out how much they should ask for salary wise? Who’s responsibility is it to fix the gap - and what, if anything, are these other players doing to help?

Five interviews with women in the potential target were conducted. Four were employed, one currently unemployed but looking to return to the workforce. One worked in the public sector. There were definitely some commonalities amongst them - “going in blind with negotiations” was a common chord struck and confirmed my suspicions. High awareness of the gender pay gap was also common amongst all recipients, along with a sense of it being in the ‘too hard basket’ to solve on their own. And a key realisation from one user that all her contacts that she would have asked for salary advice would be women who are similarly impacted by the same biases as she is.

Using affinity mapping, some clear actionable insights arose.
1. Awareness of the pay gap is high - meaning we don’t need to our product to play an education role.
2. Many of the women researched reported awkwardness and sensitivity around asking other people directly about salaries. Lack of transparency around salaries is the key problem and the observation that “nothing will change until men and women talk about it” - so, both men and women need to be involved in our solution, and that solution should help them communicate with transparency.
3. And lastly, while women want to be empowered to help themselves, they don’t think that all the responsibility falls on them, they believe it’s shared between individuals, organisations and government...highlighting a potential for them all to play a part in the solution.

During ideation, I experimented with ways that all three parties (individuals, businesses and government) could play a role in the solution. But on evaluation of the pros and cons of each solution, idea no. 8 was clearly the most empowering for our end user - delivering accurate, highly up-to-date salary information to women, whilst including men in the solution as well. It also had the potential to be a simple, intuitive concept (“I’ll tell you mine if you tell me yours”) which would be quick for users to grasp. It was only one step away from what they were already doing (asking friends, family and contacts for advice). And it enabled them to get over the sensitivity and awkwardness of asking other people about their salaries by using the anonymity of the web. This solution clearly solved the one big problem identified earlier.

The user flow shows a someone signing up for the first time. Considerations at this early stage were that sign up shouldn’t be onerous - fields of data collected should be kept to a minimum. After signup, a user would do a new search for similar people to themselves, or perhaps a step up. A result ‘match’ would then be presented to the user with the option to swap salary details with that person. If they go ahead, they would then wait for the other person to respond before their salary would be revealed. The user would then ‘earn’ another chance to swap salary details again.

User testing
The solution now needed to be tested by both males and females as it had become essential that men would also use the product, ensuring women would be served accurate salary information from both men and women. The main feedback was surprise and frustration at having to wait for a response rather than getting instant salary information back.
Pivot or iterate?
These revelations led me to question whether I needed to pivot on the solution drastically, or carry on with some improvements. By returning right back to my initial competitive research, I determined that this solution did have benefits over the alternatives. The key benefit relating to the one-to-one trade (in a sense, a peer-to-peer model) means that data is highly specific to the individual user’s needs and highly up to date, unlike competitors such as PayScale and Glassdoor.
Developing differentiation
In addition, I had some excellent feedback from one user, which helped me to realise the solution could be built on further to enhance those unique aspects - adding on the ability to have a conversation with that person, get their tips for negotiating, or even asking them to reveal their gender.
With these builds in place, I carried on, implementing some tweaks to the language to help users anticipate that egg timer page better (changing a ‘swap’ action to ‘request a swap’) and including a more information up front in a new intro screen to better explain what to expect with the one-to-one nature of the product and the on-going nature of ‘unlocking more swaps’.

You can test the Axure prototype here.

Above you can see the mid-fidelity prototyping of a sign up flow, showing the intro page which helps users anticipate what’s coming up and how the site works. Another question from a user test at this phase: “But what happens if I’m a student or on maternity leave?” prompted the addition of an ‘unemployed’ option to profile set up.
The completed profile screen was added to help create distinction and separation between the profile set up process and the first search.
The money bag icon from my paper prototype was replaced with an unlocked padlock icon to remove user’s incorrect assumptions that getting more swaps incurred a charge.

Here we see a flow of the user’s first search and swap request. A full list of search results was provided, instead of a single match result, due to user frustration that they wanted more visibility over the process, matching more of the mental model of other tools available, like PayScale or salary reviews.
The new Request a Swap? screen was added to help properly communicate to users that their details were being sent to the other user.
Finally, to reduce the sense of irritation on the final screen, I minimised the egg timer icon in size and added in a user’s suggestion of “helpful” language to anticipate an email notification when the swap is ready to view.

In this final flow, you can see the builds made to the concept to further differentiate it from the competition and to add to its unique proposition for the user, in market. Here a user can request to swap more information - gender, academic history, bonuses, workplace perks and more. Plus, a live chat option was also added, so users could potentially share negotiating tactics and other advice with one another. Hopefully, this would be the “delight” to the interface that would keep users coming back for more and encourage sharing and recommendations.

Wrapping up
As part of the General Assembly UX course, this project has been an incredible learning curve! I have been absolutely blown away by how informative and useful user research and testing is to leading you to the right design solutions. The fact that I returned often to various points in the process, in a non-linear way, proved to me how useful ‘design thinking’ methods can be at all stages of getting a product to market.
Useful discoveries
My ‘Goldilocks’ discovery was that I needed to give users just the right amount of information at just the right time - no more, no less - in order to help them anticipate what was coming, but not be overloaded and have to think too hard at any one time.
My ‘Vegemite’ moment was at the point of deciding whether to pivot on my solution. With half my users really disliking the core functionality of my site, and half my users describing it as “delightful” and loving the feeling of ‘gamification’. This is the point I returned to the very beginning of the process to reassess everything!
Where to next?
Next steps would be further testing naturally, but also to look into how governments and businesses could also be involved as per one of my big findings in initial user research that remains unresolved so far...could this be PaySwap 2.0?