VidaPay’s Multiline Design System and Process
Incrementally upgrading VidaPay’s web experience
Multiline or Family plans are not a new concept to most of us users here in the states, but in the prepaid cellular world this is unfamiliar territory. The idea of estimating totals, adding lines, even grouping lines was completely new. VidaPay’s existing system could not support these many processes. So, it was time to build a something new!
The Business Goal:
Diversify VidaPay’s offerings, in order to enable VidaPay’s consumers to better serve their customers. More specifically create a process that would allow VidaPay’s consumers to manage multiline / shared / family plans for their customers.
Develop a scalable strategy that will accommodate present and future business, vendor, and consumer needs.
- In the future, beginning with this process, we could consolidate our user’s experiences on VidaPay into what seemed to be a single process.
- By consolidating we have the ability to overhaul many parts of the VidaPay platform, allowing us to fix inconstancies and quality across the many product offerings
Iterate on the UX teams process provide better documentation and facilitate better communication among team members and stakeholders.
The teams process began by meeting with stakeholders to establish the preliminary business goals including:
- Envisioned Features
- High level system limitations & variability among vendors
From the prior step, we had identified a number of variations and commonalities among our vendor’s requirements and APIs. By grouping these together visually our starting pointing started to become clear.
We now had a list of user facing components that each system would need.
In parallel, the team began creating wireframes and testing to reduce pain points and streamline the userflows.
The team determined that a design system would facilitate both our need for a scalable strategy and the development team’s need for richer documentation. So we began building the component assets. Borrowing from the team’s Scrum experiences in the past we created a mini scrum board to track and evaluate the team’s work.
Each component was documented in a separate, numbered file. These files were stored on Atlassian, so everyone including the development team had access to them. This transparency allowed for a number of great discoveries and insights.
With a large part of the design system complete, a few full flows were able to be built with the components and wireframes. But just before “handoff”, the vendor’s requirements and API changed drastically.
All was not lost! The team took a step back to evaluate what we could salvage. The entire design system was still viable! But what of the wireframes and flows documents? Well due to the changes these were no longer usable and we didn’t have the time to recreate all of them.
We took the advice of the Nielsen Norman Group, and their wireflow deliverable.
This new process allowed us to work much faster, reduce redundancy, and reduce loss when handing off to the development teams.
The implementation of three key pieces into our workflow proved overwhelmingly valuable when the team was faced with unexpected vendor changes.
The Design System:
The Design System allowed us to design highly detailed components that could be reused for all vendor with minor modifications. The system also allowed us to move forward with key design and time saving pieces when the business direction was not clear.
The adoption of the Scrum Board created transparency for the business and team members alike. The “Evaluation” step allowed us to easily get the work in front of the entire team before going to development, thus weeding out many potential issues. We also were able to track the work very accurately. With this new team data we will be able to optimize our process for upcoming projects.
After “handoff” I met with the development team, to evaluate the UX team’s deliverables. The overwhelming consensus from the developers was that the wireflows had helped them understand the project more completely than ever before. Once again iterating on our own processes had rendered a better “handoff” and more concise communication of the project’s goals and features.