During my time in college I was heavily involved with the clubs and societies on campus. When the pandemic hit, I discovered a particular challenge that I set out to solve as part of a HCI class.
Clubs and societies depend on their members’ monetary contributions to organize events and activities. Pre-Covid, the act of collecting money was exclusively done through cash transactions.
When the pandemic hit, clubs and societies were not only suddenly forced to move their activities online, but they were also left without means to collect money from their members. Clubs and societies tried to adapt by using services such as PayPal, Splitwise and Collection Pot to virtually collect money. However, serving on two society committees myself, I watched treasurers despair over their struggles with these platforms, none of which fully met the needs of clubs and societies.
In order to give my project a direction I needed to find out more about the circumstances of the financial transactions between a society and their members. I conducted three semi-structured interviews with treasurers, which focused on how society finances are managed, the occasions for which their societies collected money, the methods they had been using, as well as their experiences with cash versus virtual transactions.
What do college clubs and societies collect money from their members for and how do they go about it?
After laying out my insights from each interview I created an affinity diagram and discovered several overlapping themes.
A central topic was the categorization of transactions. Treasurers reported that it was very important for them to know what occasion a member was paying for, especially when they were collecting money for multiple occasions simultaneously. Part of what they enjoyed most about using PayPal money pools, for example, was that they could instantly see which pool a member contributed to, as well as how much money had been raised in total for a particular occasion.
Fixed sums vs donations
Cash vs virtual
There also appeared to be a clear distinction between collecting fixed sums of money (e.g. tickets or merchandise), and collecting unspecified sums (e.g. charity fundraising).
Collecting fixed sums of money virtually was much easier and faster, yet whenever societies tried to solicit unspecified amounts virtually they noticed a significant decrease in donations compared to in-person cash fundraising; members seemed to be much more prepared to dig up small change from the depths of their pockets than to take out their phones, put in their card details and transfer a small donation.
In both of these scenarios, the most successful method was when they allowed both cash and virtual transactions. Documenting virtual and cash transactions separately, however, made it much more difficult to accurately track contributions.
Another important pain point for treasurers were collaborations with other societies. Even before Covid, keeping track of how much money was contributed by which society and keeping all the money in one place was a messy process. One interviewee specified: “I wish it was like Google Forms where we can just add the other society and they can also view and manage the form.”
User Persona
Name: Rory Jones
Age: 20
Occupation: 2nd-year B.A. student, treasurer of the Culinary Society
“Being treasurer is fun and fulfilling, but it can be stressful to manage finances for several occasions simultaneously.”
Rory is treasurer of a big society that runs lots of events and frequently collaborates with other societies for themed food events. He is in charge of the society’s finances, and he needs to make sure the society follows university guidelines regarding documentation of income and expenditure.
Rory doesn’t have a lot of spare time, so he often multi-tasks his committee work with college work during the week. He likes to be organized and hates spending a lot of time trying to figure out how something works.
Frustrations: Since PayPal closed Money Pools, it is hard to tell what a member is paying for. He also hates having to manually track how much has been collected for a specific occasion, and having to create his own list of payments and refunds in a separate Excel sheet.
Goals: When someone pays, he wants to know who paid and what they are paying for. He wants to have a list of everyone that paid and he wants to be able to send refunds quickly if needs be. He also wants to see people who paid in cash and people who paid online in one place, and he wants to see, at a glance, how much money has been collected in total for a certain occasion. Finally, he wants to be able to create a collaborative fund with another society, so that they can manage the money together stress-free.
Based on my user persona I created a number of user stories that encompassed their main frustrations and goals. Using Red Route Analysis I selected the following two user stories as the main functionalities of the app:
“As treasurer of a big society, I want to create a fund for a specific occasion, so that I know exactly what members are paying for.”
“As treasurer of a big society, I want to check how much money has been collected and who paid, so that I can keep track of the fund’s progress.”
The next step was to build the information architecture of the app. After completing a card sorting activity with some of my users, I concluded that the app should have three main sections:
Funds
Reimbursements
Charity fundraising
Interestingly, despite the fund and charity fundraising actions serving very similar purposes, my users vehemently kept them separate in all card sorting exercises, which is why I decided they should be in separate sections of the app.
To start the wireframing process, I created task flows for both of the user stories I had chosen for priority development.
Considering the fact that treasurers tend to work on the go and multi-task, my aim was to keep the tasks of creating and viewing a fund as simple as possible, involving no more than three steps.
I sketched three very simple and low-fidelity screens to visualise the steps involved in each of the task flows, in order to start mapping out the actions required.
Before I moved on to more refined user flows, I completed multiple Crazy 8 exercises to brainstorm the basic layout some of they key screens involved in the task flows (for example, the dashboard).
I went on to develop two more refined user flows for each of the task flows, where I clearly defined all of the interactions between the screens involved in the task.
I put a lot of emphasis on the simplicity of the process, as well as giving the user as many opportunities as possible to move through the task flow flexibly and on their own terms.
They key principle I used in both task flows is progressive disclosure. At any point in time there is only the absolute most important information displayed on the screen, so that the user can navigate the interface and find what they’re looking for quickly and with ease.
The task flow I was most interested in testing was the creation of a new fund, because it is contingent on direct user input. I wanted to test the form I had created to see whether the users would understand what input was expected from them. I decided to run some low-fidelity tests using a paper prototype first, in order to focus in on the interactions themselves.
I gave the users the task to create a fund with just one specified condition: the fund should be for a fixed sum payment of €20 per member. I then asked them to describe everything they were seeing and to think out loud throughout the process.
The two main insights I gained from this testing scenario is that the time picker seemed to have caused some confusion, as well as some of the options potentially required tooltips to guide the users in making confident decisions.
I took the insights from the paper prototyping exercises and built them into my first high-fidelity digital prototype on Figma. I added in an indicator of the time format into the input field for the closing time, and I also added simple tooltips to the two optional form fields to explain their function.
In designing the user interface, I decided to follow the UI guide of the web committee management platform societies used for their day-to-day administrative tasks. I used the same primary, secondary and tertiary colours and the same typography, in order to invoke a sense of familiarity and to help the users navigate this new tool using existing visual and interactive patterns.
I then decided to complete another round of testing, this time using my high-fidelity clickable mock-up on Figma.
This gave me a chance to test the changes I made based on the paper prototype and also to test the user interface and its function in guiding the user through the task flow.
I gained more useful insights through this high-fidelity testing run, for example, that the iconography of the dashboard bottom menu was far from intuitive and mislead the users. I would also need to overhaul the time picker completely, since the users still had trouble entering the time in the intended format.
However, this is where my HCI module ended and I finished the project by laying out my final prototyping insights and recommendations for further development.
