⚡️ Product design
Setting Volaby's rostering tool up for its next stage of growth
Enriching the rostering experience for managers and volunteers through visual overhauls and improved workflows.
The rostering tool that allows managers to connect volunteers to specific volunteering opportunities is one of Volaby’s most highly used features, and yet user feedback told us that it was an experience filled with frustration, confusion and distrust.
We realised that the roster system needed to be less restrictive and reliant on managers, and more scalable in every way to accomodate the rapid lateral and vertical growth in the organisations using our platform.
In leading this redesign, I looked to reduce confusion and boost user confidence through the addition of transition states and smarter interactions, and in the process set the rostering system up for scalable and sustainable growth.
The context
As our partners grew in size and scaled their operations up according, Volaby’s roster tool remained static in functionality and design.
From emails, support tickets and in-person feedback from our partners, a trend emerged around the complicated and confusing nature of the roster tool.
Users had started to lose trust in the way roster publications worked, and the manifestation of this lay in the gradual decline in the usage of the rostering tool over a number of months.
The number of published rosters fell, with an increasing number of managers beginning to look elsewhere for simpler, faster and more transparent ways of organising volunteer attendances, such as the use of social media groups and text messaging.
Setting goals
The primary goal was to reduce user confusion and increase populated and published rosters. We centred our project vision around how we wanted our users to feel as they interacted with the roster, focussing on growing our active user base and engagement levels through positive experiences.
For volunteers, rosters should be exciting and memorable, something that volunteers look forward to being notified of.
For managers, rosters should be accurate and effortless.
Identifying shortfalls
In Volaby, rosters belong to an activity, and historically when activities followed a stricter, more prescribed structure, rosters complemented them well. However, as activities became increasingly configurable, rosters remained stuck in its original design.
This led to users finding it difficult to track changes to published rosters. They could save changes but could not distinguish between unpublished changes and currently published information on the roster.
Managers couldn’t tell when communications about roster changes were being sent out; they had no visibility over when emails were being sent nor who the emails were going out to and they couldn't see who last edited the roster and when they did it.
Diving into user feedback, I synthesised the highlights into hypotheses that framed key user problems from both volunteer and manager perspectives.
Volunteers
Engagement → Volunteers are disengaged because they feel uninformed and powerless due to lack of visibility and control over their rosters.
Managers
Roster scalability — Managers are frustrated with both desktop and mobile experiences due to poor optimisation for activities with lots of sessions.
Lack of trust and control → Managers are distrustful of the system due to insufficient visibility and control over system-generated communications.
Reliance → Rosters are too reliant on managers to maintain and upkeep in order to be accurate.
Eliminating pain points
We knew what the roster tool was for, and what capabilities it had. What we lacked was an accurate understanding of what users were really trying to accomplish when they used the tool.
Using the collected user data, I worked towards solutions that targeted specific problem areas in the rostering screen and user experience.
Decluttering the interface
The cluttered layout of the page was a key cause of frustration as managers found that there was too much going on, leading to cognitive overload. This prevented them from being able to correctly understand key states such as when a roster has already been ‘published’ versus when it was still in a draft state.
Updated cells + transition states
We added a set of new cell states to paint a more accurate picture of volunteers who were about to be added or removed from the roster.
The current roster did not differentiate between users who were already rostered/removed and the users who were in the process of being rostered/removed.
A new 'To be rostered' status in blue was introduced to represent a draft rostering. If the roster's changes were saved but not published, managers will see the 'To be rostered' status for volunteers who aren't on the published roster.
Green 'Rostered' state only to be used for volunteers on a published roster.
Added a ‘To be removed’ status in red to represent currently rostered volunteers who were to be removed from the published roster. When an updated version of the roster is published, volunteers with this status will be notified that their rostering has been cancelled.
Summary card
Introduced a roster summary card including a change summary and Discard | Save Changes | Publish buttons. This means that only Roster Settings and Cancel Activity buttons are permanently located in the roster header.
Targeting scalability
Scalability was another common pain point that plagued the rostering experiences of our partners. In the existing roster tool, once the number of sessions (each represented by a dedicated column) exceeded a number, the columns would begin to run together and overlap. On smaller screens, the number of visible session columns would also be reduced, with some sessions becoming entirely invisible.
This caused situations of missed opportunities as managers did not realise that there were sessions where they have not rostered volunteers on to attend yet. This also meant that volunteers who had indicated that they were available to attend the session were left in a 'waiting' state without proper closure.
By comparing the different operation models of our partners, I realised that roster would need to be able to scale in different directions as there were 3 pathways that an activity's rosters would likely follow over time:
Lower number of sessions with high volunteer volume across the sessions
High number of sessions with a handful of volunteers for each session
High number of sessions with high volunteer volume for each session
To resolve this, minimum widths were introduced to each column that represented a single session. The next step was to allow horizontal scrolling so that the no sessions will be inaccessible going forward due to reasons such as limited screen space.
New roster mode
Rosters are heavily optimised for well-formed teams with highly active managers. This made rosters not ideal for more casual, self-sufficient activities that much less reliant on manager influence.
The solution for this extends beyond the limitations of the roster screen and crosses over into activity configuration. We added the choice for users to be able to select from two different roster types: Managed and Open.
Managed rosters are simply a new name to represent rosters as they currently work, whereas open rosters are entirely new. Open rosters are self-managed rosters where volunteers can manage their own attendances, but managers can still make and publish changes at their discretion.
Outcomes & learnings
Through this overhaul, we crafted a more natural experience for rostering. Managers are now able to tell at a glance what a volunteer's status is on the roster. Publication tools are visible on a as-needed basis which reduces confusion around when rosters have outstanding unpublished changes.
This was an incredible project to work on, as I could see every step of the way how each problem we targeted would relieve current pain points and bring increased value to the tool for our users.
As with every project, there are the challenges that make this a unique experience. These are some of the key takeaways that I took from leading the redesign of the roster tool.
Maintaining a firm bottom line
Shifting priorities, resources and timelines led to scenarios where the project scope had to be revisited frequently. I learned the importance of having a clear idea of what would be enough to constitute an MVP release and having the confidence to stick with it.
Staying flexible
As with all projects, there is always more that is dreamed up than may be realistically feasible. The challenge for me lay in working to identify where our key improvements should be, and which we would have to reprioritise for the next round of upgrades to the roster tool.
Collaborate
An issue that drove a lot of in-depth conversations and discussions in this project was to do with the new transition states we wanted to introduce. Having input from both Customer and Engineering teams gave us a more well-rounded perspective on how our initial solutions may not have worked as well without additional tweaking.