⚡️ Product design
Eliminating design debt in bite-sized wins
Addressing long-standing shortcomings to unblock workflows and inspire user confidence.
In Volaby, a considerable part of our design debt stems from UX compromises made to fulfil more immediate, time-sensitive goals. This resulted in the emergence of recurring issues such as low feature discoverability, blocked workflows and poor feature placement, leading to incomplete experiences across connected features.
Every one of these ideas stem directly from customer feedback; these are validated issues with straight forward solutions that will relieve and prevent user complaints.
I partnered closely with the Engineering and Customer teams to research, design and deliver a series of lightweight fixes that were released over a 4-week cycle.
The context
The purpose of this project was to address the figurative elephant in the room; the rocky experiences spread over a number of tools and missing functionality causing noticeable pain to our users.
We’d found ourselves accepting and releasing MVP versions of systems and features more often than we would have liked. The accumulated sacrifices seemed minor in isolation but over time led to high traffic areas becoming increasingly frustrating to use due to fragmented workflows and much-needed features being absent.
Working closely with the Customer team, I collated and analyse direct partner feedback, support tickets and feature requests. One of my key priorities was to reduce the emergence of new design debt by working with the Engineering team to run quality checks earlier in the build process and planning in-app support content for releases.
The vision
The goals of this project fit around the themes of confidence, quality and ease of use. The central vision focussed on eliminating shortcomings across various use cases, such as:
Volunteers struggling to access the right impact report to complete
Managers wanting to save more time when managing incoming and existing volunteers,
Admins wanting more data to be exportable from the system.
Workflows should feel natural, and users should feel confident as they navigate the app to achieve the tasks they set out to complete.
Problem spaces & solutions
Activity Reports — Promoting ease of access
The activity report page has featured prominently in user queries prior to the redesign. My first step in defining the problem space for this page was to revisit its intended use cases and audit its existing functions to better understand the challenges our users had been facing.
Primary use case: the Activity Report page is where volunteers who had attended an activity could go to fill in the corresponding report to document their attendance, quantitative and qualitative impact data.
From partner conversations, one of the most impactful learnings I took away was that volunteers found it incredibly confusing trying to access the correct report to complete. This was a result of volunteers needing to know which specific program, activity and date to select from the drop downs in order to access the activity report they were after.
Program, activity and activity date drop downs in the original Activity Report UI
Our process for this begun with a collaborative white-boarding session. As I worked with the Product Lead to brainstorm the redesign, I advocated for the following principles to be kept at the forefront of design decisions:
Increasing the level of discoverability for new and historical incomplete reports
Making relevant information available up front without the need for user action
Collectively, we arrived at the decision to maintain a volunteer-first focus on the page, to align more closely with the primary use case.
The UI itself was stripped back and simplified so that attention would not be drawn away from the focal point of the page - a curated list of the volunteer’s most recent rostered activities.
Redesigned Activity Report page (left) with a new secondary screen (right) for volunteers to access a full list of relevant incomplete reports
A secondary page (‘Find an incomplete report’) was added, for the purposes of:
Allowing the main Activity Report page to remain uncluttered keeping only incomplete reports from recent activities listed.
Having an accessible archive of incomplete reports relevant to the volunteer in an easily scannable list with filtering options to facilitate easier searching within the list itself.
The results of this redesign could be felt immediately, as we noted a significant drop in feedback coming through from volunteers and managers about difficulties accessing the right activity report within the first few weeks of release.
Incoming Volunteers — Giving managers more control
One of the main opportunities for improvement in the Incoming Volunteers page lay in equipping managers with the ability to remove applicants who had not yet completed their onboarding process.
This is an issue that had continuously eaten up pockets of dev time over the course of months. Prior to this project, applicant removals had to be handled via the Engineering team. Wait times and feedback loops between Support and end users stretched what should have been a relatively simple action out into a stepped out process.
Another use case we’d identified was that a lot of contacting and communication occurred outside of Volaby at the applicant stage for many partners and the lack of exportable data made it inconvenient for them to access and consume the pool of applicants outside the system.
Removing applicants — A ‘Remove Applicant’ button was added to the individual applicant view This should trigger a confirmation dialog informing the user that this action cannot be undone and that the applicant will not be able to resume their application.
CSV download — Introduced a download button in the Incoming Volunteers page to export a CSV file containing the list of current applicants, including details on their status, name, email, completion progress and more.
Future possibilities: Exploring alternative pathways such as blocking, pausing and rejecting applicants, especially focussing on introducing actions at a task-level as opposed to account-level.
Volunteer Database — More comprehensive data access & view customisation
For the Volunteer Database, which is where managers can view and manage all volunteers who have completed their onboarding process, our focus was on improving the usefulness of the feature by offering better customisability in what kinds of data can be viewed and exported.
We started out by white-boarding rough layouts and trying out different placements of customisation options. As part of our brainstorming, we also narrowed down the specific data points that were required in order for the improvement to have increased value in use.
For the Volunteer Database, the key changes boiled down to the following:
Add 'Privilege Level' column as a permanent column to show which permission level the user has to so that managers can easily sort volunteers into groups
Introduce 2 menus of additional data that can be viewed in the VDB as additional columns
Tasks [Volunteer Profile tasks - options will be dependent based on what tasks each partner have created]
Impact [Impact data metrics that we provide - this goes across the board for all partners]
Ensure the CSV download reflects the snapshot of the customised view
One of my key concerns for the Volunteer Database was that the new features would suffer from poor discoverability. The solution I crafted in response was to build out a feature tour using a third-party service.
This included an announcement on entry to the page with the option to take a step-by-step tour through the new functions available.
Outcomes & learnings
With workflow improvement and increased user confidence as goals, we set out to craft solutions that would supplement the individual feature experience so that the overall product experience was more cohesive.
Streamlining processes
Working with the Engineering team to identify test cases as part of the scoping process so that clear expectations on what should will be built matches up with the intended design and expected interaction behaviours.
This led to the team being able to push smaller, more realistic and achievable slices. The bottleneck on QA turnaround was significantly reduced (from an average of 1-2 weeks blocked-out to 1-2 days per released feature), and an added benefit was seeing feature knowledge spread more evenly amongst more of the team.
Supported, quality releases
With the addition of Appcues to our repertoire of tools, reducing user confusion and increasing new feature visibility became much easier to facilitate. I put together in-app announcements and/or feature tours for each mini release that had the potential to have noticeable impact on a user’s way of working in Volaby.
One of the key goals of supplementing our releases this way was to ease the dependency we had on the Support team to have to coordinate communications to the wider user base, as was the norm in earlier projects.
I also put up dedicated segments on our digital experience analytics tool for each shipped feature to track user adoption and monitoring for new pain points.