Sprink
Empowering union office admin with a modern & streamlined workflow.
Web app
Background
Local Union 669 is a pipe fitters union with 13,00 members. Admin in the office were using an AS400 from the 1980s to manage the members causing data errors, duplicative work, and user & member frustration. We conducted a discovery process to uncover crucial user needs and lay the groundwork for the Sprink MVP.
Client
Local Union 669
Year
2023 & 2024
Role
Lead Product Design, User Interview Facilitation, Product Strategy
Team
Shannon Hosmer, Creative Director
Justin Bend, Product Owner
and more at Mindgrub
Challenge
I needed to fully understand Local Union 669's office processes and how they had been utilizing the AS400 for the past 40 years so that we could establish the vision of the new product based on required parity functionality as well as user needs and pain points.
Process
I built my foundational knowledge on client-provided process documentation that I used to document high-level jobs to be done, I site mapped the AS400, and I completed a competitor analysis.
I collected any questions that surfaced to a questions register in Confluence that was later used during user interviews. This document became a vital tool for the entire team as we moved into and through the MVP phase because of the wealth of historical knowledge we were trying to "download" from an immensely complex and edge-case heavy process with 10 unique user types.
Mapping the AS400 was a cumbersome process, but intimately exposed me to the users' frustrating experience and revealed what parity features would be required for the MVP. This screenshot shows a fraction of the AS400 chaos.
I facilitated user interviews with 10 office admin to gain a deeper understanding of the overall processes that make the union run, users' daily job functions, and of course to uncover their wants and needs. We determined that the product would resolve these issues with the following solutions.
Pain Points | Needs | Solutions |
|---|---|---|
|
|
|
Solution
I used the culmination of my knowledge from all of the discovery work to create a new sitemap and preliminary wireframes demonstrating what the tool could be. By simply introducing modern paradigms and functionality, the product would streamline users' workflows and ease frustration.
Users could work from a single centralized location whether a table, a member's profile, or a contractor's profile instead of navigating through 10+ screens to find information they needed throughout the AS400. Information in one part of the system like Funds and Payments would be reflected in another part of the system like a Member's profile's funds and payments instead of isolated data entry into both locations.
The client was elated with the potential of how much easier their lives would be with the new product. They signed a contract to move forward with the MVP, but my work didn't stop there.
MVP Phase
The product owner asked me to assist in the creation of user stories because of my uniquely close understanding of the current AS400 system and user workflows. I wrote out the remaining 80% of the user stories for the MVP in Jira.
I was brought back onto the project for UX near the completion of MVP design work to design the dashboard experience, non-member and unemployment workflows, and re-design the funds & payments in the member profile. With the project nearing completion and time running short, I leveraged the design system to move directly to high-fidelity designs, bypassing low-fidelity wireframes.
The dashboard would feed the user information they currently needed to seek out through numerous reports down cumbersome workflows. It included live member metrics, member flags, and the ability to pin members and contractors. This functionality would save users hours of time per week.
Non-member and unemployment workflows required deciding how they would be treated within the new system (as a member type, status, or flag) compared to the AS400 lists.
Non-members were determined to be its entirely own entity outside of being a member. I identified that eight different use cases would be required to cover all scenarios of how a non-member could exist within the system across the lifecycle of membership. These workflows also covered the path to becoming a member and the unique requirements for each scenario.
I determined unemployment would be a flag manually marked by the user in a member's profile when the member reported their unemployment. The workflows included marking unemployment, updating a variety of unemployment information, automatic flags, and removing the flag.
Funds & payments required a re-design to make it easier to understand at-a-glance what a member owed and if they had any credit, as well as enhancement to payments made to a member, by a member, and by contractors on their behalf.
