top of page
Billing Platform
I worked with a design 'squad' on a new billing platform allowing clients to pay their bills digitally and manage their payment methods online.
1 designer
1 product manager
1 business analyst
4 developers
2 qa testers
ux research, ux design
background
at a cable company, the current online billing experience was behind its times. it lacked the functionality of allowing customers to pay their bills online, manage their payment methods, and view their billing cycle details. at the time, customers instead had to call in to support agents in order to inquire about their bill or make payments. this resulted in 70% of the calls agents received to be billing related issues.
working as a squad, the team collaborated heavily. we worked in agile in order to keep our process moving quickly and iterate on decisions often. overall, the process covered main areas: understand, discovery, ideate, test, and deliver.
the process
understand
the team sat together to view the current state of the billing platform, which was essentially just one page where customers could view and download their past historical bills. it was obvious that there was a lot of room for this platform to grow, but how can we get there?
the biggest problem the team would be solving for is the extreme lack of functionality on the current platform. we gathered and added onto the already established list of requirements and would prioritize tasks depending on the user and business goals as the project progressed.
in order to help us prioritize our requirements, we leaned into already existing data - data collected from the current platform and our support teams. analytics built into the larger system that the billing platform was a part of revealed very low amounts of visits to billing and very few downloads of previous bills. our support team also shared with us a breakdown of the types of calls they receive from customers: out of the 70% total related to billing issues, 30% was payment related. the team decided that the first focus would be to allow customers to make payments online in hopes to drive engagement to the platform.
observation & research
we as humans make payments almost every day in our lives and the concept of 'online shopping' has been around since the 1990s. later, amazon launched in 1995 allowing people to quickly and easily purchase items via the web. this idea wasn't new to anyone working on this platform redesign, we just had to expand upon the theme of 'billing' and think outside of the box a bit.
during the project kickoff, i tasked my peers to converge and note down over a week any kind of payments they were making digitally. this included everything from any bills that the team was making payments towards, or ones that were scheduled for autopay, to any online purchases they were making. during the discovery phases of projects, i think it's important to generate as many ideas as quickly as possible with the team. rapid idea generation allows the team to develop a shared understanding, eliminates concepts we don't agree on moving forward with, and kick starts the design process early on.
a week later, the team converged and i had everyone write stickys representing the different digital payments they made over the past week and any activity they did related to that. i grouped the main concepts into themes, payments, account, and support and for each, i crossed out items that may not be applicable to our specific system.
the team did a competitive analysis together on the indirect and direct competitors that we all used in some method of billing or purchase throughout the week. we focused on features offered, functions, main workflows, and overall experience for customers and users.
verizon
key highlights:
- total bill amount called out with high priority
- clear breakdown of total amount due
- payment center topics easily accessible
- autopay and last payment information
xfinity
key highlights:
- 3 step process easily called out so users understand amount of time it may take to complete tasks
- digestible chunks of information to fill out on form
- reviewal of payment prior to submitting
- confirmation with important details about the payment
t-mobile
key highlights:
- helpful autopay information called out on the payment form
- allows users the ability to set up payment arrangements for payments needed to be made at a later date
chewy
key highlights:
- payment method settings are called out in a separate area of the app
- users have the ability to set a primary method and the primary method is explicitly called out
etsy
key highlights:
- saved credit cards are shown in a card component for visual representation of actual object
- ability to default or change a default is simple and clear for users
other than our customers who would be using the portal to pay and manage their bills, the new platform would hopefully enhance the internal support agent experience, too. in order to understand what our agents needed and build empathy with them, we set up agent interviews.
we set up 5 agent interviews - 3 with regular support agents and 2 with lead agents. we wrote down our goals and objectives and created interview scripts so that we didn't create any bias during our sessions.
-
~70% of all incoming support calls are billing related
-
about half of that is specifically related to making payments
-
most calls about payments are clients inquiring if a payment was actually made and when (misplaced/missing payments)
-
the ability to even make a payment online would help lessen support agents workload
-
agents believe that there should be a mechanism to view fees and charges on bills
-
agents want clients to have the ability to control paperless billing and autopay onine
after most of our research was conducted, it was more clear that our product was lacking. we used those findings against our initial research within our everyday life to start gathering requirements for the product. we focused on both business and user needs and supported them with real use cases. we also worked together to prioritize what would be considered mvp and what could be developed later on.
user workflows
axure
at the end of discovery, i moved onto creating current state and future state workflows for the customer. it was important for me to outline the steps and processes a user could perform today because i wanted the team to realize how much the product was lacking in terms of functionality. that, compared to the robust future state flows, would emphasize the growth that needed to happen and give the team something tangible to march towards and work against. the future state workflows incorporated all of the future functionality we would incorporate into the platform.
future state
for a more detailed view on future state flow, please click here.
ideation
pencil sketches & sketch for storyboarding, axure for wireframes
we took one of our main personas, cindy the billing associate at a larger company, and storyboarded her experience with the platform in order to help visualize my ux ideas to the team. we focused specifically on the journey of making a one time payment and enrolling in autopay because we knew that those were of high priority and to be included in the mvp. working together with the team to sketch the sequence of events helped us connect more with cindy by visually predicting her emotions when navigating through our product. ultimately, the storyboard helped us connect the users, user stories, and user flows together for the make a payment and autopay features.
i started wireframing for mvp requirements while also taking into account the future long term vision of the platform as a whole. although most of my work on this project is proprietary, here are some examples of early wires i created. if you are interested in seeing interaction design within this work, please contact me.
billing systems are complex and rely on integration with a lot of systems, including internal invoicing teams, billing service teams, and banking platforms. i worked closely with data analysts and architects to identify what data was available in our apis to display to the client and what source systems we needed to work with in order to get new data to show.
working closely with these team members, i was able to rapidly iterate upon wireframes to ensure that i was designing with accurate data sets and that what i was designing for and testing with was actually feasible. this was my first time working with such complex data and i grew to love the analysis of and understanding of back-end development and how to read apis.
test
i took multiple rounds of my wireframes through usability testing working with our research team. the first testing phase focused on the ability to make a payment which was our largest mvp feature. the second encompassed enrollment and management of autopay, followed by the third that focused on settings.
the testing took place with a small group of customers, users on usertesting.com, our support agents, and also with other designers who worked on billing for different product platforms at the company. all of the usability tests brought forth undeniable data about what was working, what wasn't, and what needed to be included through testing of specific tasks and having users think out loud. i leaned on the research data to help drive my design decisions further while iterating on my wireframes.
after multiple rounds of testing within each usability phase, the wireframes were at a point where they were usable, engaging to users, and covered all business and user goals.
if you are interested in seeing more designs for this work, please contact me.
final thoughts
having different key team members accessible at all times due to being embedded in a multidisciplinary team allowed me to move quickly through design phases. i was able to solicit stakeholder feedback often, work with others to make sure i was capturing requirements, vet the feasibility of displaying specific data, understand the true impact of the platform with other teams within the company, and above all, develop new and lasting work partnerships and relationships.
even though this platform was specifically intended to allow users to pay and manage bills online, i encouraged the team early on to think beyond that. we purchase items and pay for things everyday in our daily lives and are either left satisfied by the experience or not. by empowering the team to really think through those types of payment related activities they perform daily allowed the team to be more empathetic towards our users and help to create a shared understanding of what we were designing earlier on.
bottom of page