Payment Portal
UX Design/UI Design
The Payment Portal offers patients the freedom and convenience to pay their bill outside of business hours online.
Imagine patients who have busy lives and need a convenient way to manage their bill payments—while also navigating something as overwhelming as cancer care. Between appointments, treatments, and time with family, paying a medical bill shouldn’t add stress or require waiting on office hours. Yet for many, that’s exactly the reality.
At the same time, billing departments are stuck in a slow, manual cycle—missing after-hours payment opportunities, juggling paper statements, and struggling to keep communication clear between staff and patients. The result is friction on both sides: delayed payments for practices and unnecessary effort for patients already dealing with enough.
This Payment Portal was designed to bridge that gap—creating a simple, secure, and always-available way for patients to take control of their payments, while helping healthcare providers streamline their revenue cycle and reduce operational strain.
Visual Design, Interaction Design
The Product
A patient-facing Payment Portal feature integrated with Unlimited Financials.
Project Duration
2019, 1 month
The Problem
Currently, patients cannot pay their medical bills online.
The Goal
Provide an easy way for patients to pay their bills online 24/7, resulting in faster payment posting for practices.
My Role
To identify key interactions of the portal login and create prototypes to test concepts. To do this, I needed to understand what the user was trying to accomplish, what business goals to keep in mind and technical constraints.
Research
Research showed that we could improve revenue cycle processes for our customers with a payment portal for their patients. Payments can be reconciled faster by making it easier and more convenient for their patients to pay their medical bills online.
We talked to Product Development Stakeholders and users to understand the interaction requirements as well as the technical constraints of the feature such as HIPPA compliance, dual security and API integration. We made a list of questions and concluded feasible solutions.
Assumptions
• Login would need to be HIPPA compliant and have multi-factor authentication
• API integration
• Practice branding would be required for patient-facing interaction
• Most people have made payments online and would trust this process with their healthcare provider.
Payment Cycle
Customer Pain Points
• Slow revenue cycle
• Poor communication between staff and patients
• Posting payments manually is inefficient
• Paper and mailing costs
User Story
As a patient receiving cancer treatment care, I want to login to a payment portal, so I can pay a bill from my Oncologist.
Patient Proto Persona
For quick alignment, we created a lightweight Proto Persona based on our team’s existing knowledge of who the users would be for the Payment Portal and what they would want.
Assumptions about our user
• Would know how to create a login
• Most likely have experience with online bill pay methods
• Most people are used to making payments online and would welcome this convenience with their healthcare provider
• Would trust the security of making payments online
• Has exposure to multiple platforms such as tablet, phone and desktop computers, smart displays and TV
• 50% of patients would like the convenience to pay online
User Needs
• Managing cancer care
• Wants to feel more in control
• Needs more time with family
• Keep finances in order
Wireframes
Solution
• Logo would need to sit on a white background due to the technical limitation for branding with practices.
• Text informing the user what task is to be completed.
• Label text occupies more space, which makes the screen busier, but indicates action for Fields.
• Ghost text would be used inside Fields.
• ReCaptcha Privacy will be required to add Security.
• Action button is in a secondary state, but active when the requirements are met, which will give the user the necessary feedback to click.
• Practices can add identifying text to build trust in the footer.
Design Considerations
• Screen size
• Interaction
• Content layout
• Functionality
• Consistency, continuity and context with brand guidelines
Takeaways
A Payment Portal allows practices to not only accept payments 24/7, but also to extend their care and has the potential to increase patient engagement through their online patient experience. Future features could include:
• Self-scheduling
• Access to patient data
• Prescription refill requests
• Medical records and lab results
• Appointment reminders and notifications
• Ability to complete required forms
• Secure online messaging to provider
Plot Twists/Challenges/Iterations
• Users do not want to create a login, so we switched the data requirement to the patient’s FAN and DOB.
• Some users needed help finding their FAN. Tooltip assistance was added for this field.
• Our platform changed from WorldPay to Stripe as the payment gateway. The authorization process required us to move steps in the payment wizard around because security measures were different between products.
• Our data conversion / translation tool failed because the scope of this feature was too large. We pivoted to use Splunk as our means of identifying data conversion issues. As a UX designer, I dislike this because it required us to rely on a 3rd party integration, forcing users to exit the portal and enter into another app.
Methodologies
• Stakeholder Interviews
• Product Research
• Personas
• Customer journey map
• Mockups
• Prototyping
• Testing• Iterations
Tools
• Miro -brainstorming
• FigJam – user flows & persona
• Figma – wireframes
• Sketch – mockup design
• Invision – prototype• Typeform – survey
Discovery
While researching this feature with our customers, we discovered they really like the ability to add a card on file for future payments as another solution to more efficient payment processing.
Outcome
The Payment Portal was was sent to backlog for future feature development.
