Replacing our payment system
Do high-stakes situations, and difficult problems with short time frames thrill you? If so, I will take you through my experience working as the consistent UX resource on a development team as we performed the technical equivalent of open-heart surgery on a fully awake and operational patient. I’ll share with you how I grew to understand more fully the back-of-stage operations that support customer interactions and how I leaned on co-creation and quick understanding, to help the project meet its projected deadline.
Overview
The current payment system was not flexible enough to support the growth of the business. We needed to understand how the current system was used by multiple teams and departments, the customer’s goals when making changes to their billing, and map solutions to the capabilities and structures of the 3ed party service that was chosen to take its place. We also were working towards goals established by stakeholders in several departments.
Problem
Not flexible enough to support growth
Whiteboard from our initial interviews. These helped us understand who we should be speaking with, their role, and how this system impacts their work, it also guided which tasks and processes we needed to understand in more detail.
I was invited into this work by the UX Design lead, Tom. I began by identifying what the service owner and Tom needed most, and how best I could get involved. Tom invited my perspective on how we would approach understanding the different internal team's needs. We crafted the process we took together. The service owner, Alan, also included me in discussions with stakeholders, this helped me understand the direction of the project and the purpose behind the goals that would guide the work. It also helped me identify constraints later on, that were outcomes of the early vision cast for us.
We both collaborated with the product owner to understand what tasks were likely impacted most by the change to a new system, and to decide which tasks to prioritize, deprioritize, or we needed to understand better. To keep the project moving and test our process, we started with understanding workflows in depth with a handful of teams, not getting to every team who would use the payment system.
Approach
Started with understanding workflows in depth
Documentation of a team's tasks and the likely impact the change will have on each activity.
Leading the initial interviews gave me the opportunity to get to know my coworkers and those using the system in a new way. We found pain points that occurred when one team was in communication with the member but had to request a change to be made by another team. This was especially painful when not every team, or team member, had an understanding of internal policies. It was clear this breakdown in how they work had a direct impact on the relationships between the two teams as well as their interactions with the members and customers they help.
How they work had a direct impact on the relationships between the two teams
Interview with a friend who works with affiliates. She was showing me her process for one of the tasks we needed to understand better.
I worked closely with the internal teams to understand their processes. At first, this understanding took the form of interviews and workflow mappings. This along with conversations with stakeholders and multiple teams leads for different departments unearthed opportunities for improvements that the replacement system could improve. We chose to focus on improving experinces and processes that were in line with the projects goals and objectives.
Unearthed opportunities
The workflow digarams gave the team, and stakeholders a shared understanding of the current process. We used the diagram as a way of documenting and aligning multiple perspectives on the path forward.
We identified some concepts that where being confused as synonymousc. This lead to misunderstandings around how and when to use them, sometimes causing a lack of trust between teams, and beacuse the system had these concepts tightly coupled, it was impacting one teams ability to maesure the effectiveness of their efforts. Thankfully, knowing was half the battle.
My most fond moment of the project was learning from Tom as we mapped a new architecture intended to fix the painpoints we identified. We reviewed the new structure with the teams who would need to adopt new processes, the review was insightfull. We were able to identofy a direction and know how to prepare those teams for the change.
A new architecture
Tom and I drew out a new architexure and tested it with multiple scenarios then reviewed it with stakeholders and end-users, cultivating an understanding for both them and us, of how a change like this may impact their work.
We shipped a new payment system on time. The new system was rolled out in a way that did not impact all of the customer bases at once and supporting teams had only a few months of working with two different systems. The new system moved the ability to fulfill a few different types of requests into the hands of the support staff on the call with the member rather than downstream with another team. This made a positive impact on the relationship between departments and helped the team to resolve the issue a customer has on the first call.
We also improved internall processes for communication and change management between the tech department, design department, and teams of supporting staff. We paved the way for new communication channels and a mutual empathy and uderstanding between departments.
Results
We shipped a new payment system
I greatly appriciated the condor, honisty, vulnerability and the humor of our member support team. There was always something to smile and laugh about, even if the message I had delivered was not ideal.
As much as I may have been uncorftable with the process employed later in the project of solving problems without allocating time to understand the context of use first, this project did force me to lean into other ways of quickly getting user perspective. The way we worked helped us to foster good relationships and a deeper understanding of the work done in each department. These relationships and this deep understanding have helped me in later years with other projects. It also formed my understanding of what these departments needed for their team to feel prepared when helping members navigate change.
As a company, I believe we improved at cross-departmental communication with the launch of the new payment system, and have continued to grow in this respect with each project after.
Lessons Learned
Improved cross-departmental communication
There was a shift in approach. Tom had moved into leadership of another team, so the team was left with 1 UX designer. In order to make the progress necessary to meet the project deadline, we had to get good at knowing just enough to make a decision. Designing with incomplete information meant I needed to get feedback from the departments using this tool another way.
I become reliant on candid conversations with feedback from the managers and team members. Though the majority of the changes we made looked like UI changes, the conversations and feedback exposed the people and processes of the team. The rough prototypes were just a means to get at the necessary conversations. I also relied a great deal on the strengths of individuals within the departments who best knew how to communicate changes to their team. Through being hands on in a lot of this, I learned change management with our support team and what a kinds of information UX needed to provide to the team.
Knowing just enough to make a decision
With our member support team a lot of the changes discussed to support the new system impacted workflows, processes and policies, sometimes that needed to be called out in the UI of the tool they use.