Role
Lead UX Designer
Tools
Figma, Minimals UI, Miro
Timeline
Research 2024–2025, design began August 2026
Status
In progress
Responsibilities
Member interviews, personas, competitor analysis, wireframes
Corporate One is a corporate credit union, which means our members are credit unions and not consumers, and one of the things we offer them is a way to send immediate payments out to the businesses they work with. The existing product is called CU Corporate RTP, and credit unions use it to pay the companies that keep their branches running, things like payroll, landscaping, and utilities, as well as any other payments they need to make to their vendors.
That product doesn't run on anything we built. It runs on a platform we contract from a third party, so for as long as we've offered it we've been able to sell it and support it without being able to change a single thing about how it works, and in the meantime we were talking to members about what they needed from it and collecting findings we had nowhere to apply. In 2026 that changed, because we started moving off the vendor and building our own version of the product with the same functionality, inside a larger project called the unified system, which is planned to launch in 2027.
So this is a rebuild of a product that already exists and already has customers, and it's the first opportunity we've had to design the send experience ourselves. I'm the lead UX designer on the project, and I came into the design phase with two rounds of member interviews, three personas, and a competitor analysis already behind me, so the wireframes are being built against research we'd been holding onto while we waited for a system we could actually change.
We don't build the system our members use to send those payments. We contract with Juniper Payments for ACH, domestic wires, and real-time payments, so when a member sends an immediate payment they're logging into a third-party platform with our logo across the top of it. The technology underneath is new, since real-time payments themselves are new, but it has been built into an interface that is much older than the technology it's running.
We didn't own the user experience, so we were unable to make changes, and when we approached Juniper about updating the system they weren't going to do it, since by that point they had built a newer system of their own called JuniFunds and the one we were on was not what they were investing in. Moving our members onto that newer system may have been an option, but our executive leadership team decided to build our own experience in-house instead.
Sending one payment takes three separate pages.
The first page asks for the amount and the receiving financial institution, the second page asks for the receiver name, account number, related information, and any email addresses that should get a confirmation, and the third page is a final overview. There's no progress indicator anywhere in that sequence, so a user filling out the first page has no way to know how much is left.
Templates only exist inside the send flow.
To create a template a member has to act as though they are going to send a payment, so they start a payment, fill in every field across all three pages, and get all the way to the final overview screen before any option to save a template appears, and those save buttons sit in the same row as the button that actually sends the money. That isn't intuitive, because creating a template and sending a payment are two different things a member is trying to do, and you don't necessarily want to send money at the moment you're setting up a vendor you'll be paying for years. So that was something we wanted to address.
Juniper's "send payment" experience.
Research
We interviewed seven members about our immediate payments products in 2024, and then went back and interviewed six more in 2025 to see what had changed and to fill in gaps from the first round. We talked to the people who use the product day to day and to the executives who decide whether to buy it, and we also talked to members who had gone through the whole sales process and chose not to purchase. Some of the most useful conversations in our study came from these members, because they told us what the product would have needed to provide in order for them to move forward.
Three personas came out of the research.
There's the decision maker, a CFO who is looking at immediate payments as a way to get away from mailed checks and the fraud that comes with them, and who cares about cost, security, and service level. There's the front-end user, an electronic services staff member who is the one actually executing the payments, who works with templates for repetitive transactions, who coordinates with coworkers to get payments approved, and whose listed frustrations include difficulty using the templates feature. And there's the lost client, a CEO who evaluated the product and didn't buy.
The three CU Corporate RTP personas.
The lost client told us what was missing before we ever talked about the interface.
She didn't say no outright, she said she'd want more information and might be open to it down the road, and when we asked what that information would be it came back as: do they have use cases? Testimonials from other credit unions? Anything on fraud mitigation? She also couldn't tell which of our products required a core integration and which didn't, and she couldn't justify the product internally when she could only think of a handful of situations where she'd use it. None of that is a wireframe problem, but it shaped how I thought about education and support living inside the product and not only in sales materials.
Fraud came up on its own in a number of these conversations, since a real-time payment is instant and it isn't reversible, and several members were interested in immediate payments specifically as a way to get away from check fraud. Fraud prevention software is available separately and isn't something we're building into the product right away, so most of what came out of those conversations is something our sales team can speak to directly, and it didn't end up changing the wireframes.
I ran a competitor analysis comparing CU Corporate RTP against US Bank, JuniFunds, and Alacriti, working from demos of each system, and I looked at general navigation, sending a payment, templates, notifications and alerts, bulk capabilities, fraud prevention, fees, training and support, and the payment approval process. For each area I wrote up what we should do and what we shouldn't do, so the output was something the product team could actually make decisions against.
"Sending Payment" experience comparison from competitor analysis.
US Bank fits an entire payment onto one screen.
They also let users search for account numbers, addresses, and routing numbers instead of making people go find that information somewhere else and paste it in, several fields have tooltips explaining what's required, and there's a customer support page and a training center linked directly in the main navigation. Our system, by comparison, has no support page and no tooltips at all.
JuniFunds gave me the step list.
JuniFunds is the newer system Juniper had moved on to, so benchmarking against it meant looking closely at where our own vendor had landed after they stopped investing in the system our members were still using. Their wizard shows you where you are and what's left, and it lets advanced users drop out of the wizard and work in expanded forms instead if they'd rather do that. The flow I reviewed ran nine steps, but that was a wire, and a wire carries considerably more information than an immediate payment does, so the number of steps told me less about the pattern than it did about the payment type. What I took from it was the visible step list, and a sense of how much that pattern can hold.
Templates comparison from the competitor analysis.
Templates were weak almost everywhere.
US Bank has an address book but no real template feature, Alacriti lets you save frequently used accounts but has no templates either, and JuniFunds automatically saves every previous payment for pre-fill with no way to create or edit a custom template. Ours was rated better than two of the three and still wasn't good, which told me a dedicated, well-built template experience was somewhere we could actually be better than the systems we were being compared to.
I pulled the interview findings and the competitor analysis into a single set of opportunities and took them to the product and development team so we could agree on what was feasible for the first build.
Make templates a real feature.
Give members a dedicated place to create and manage templates that isn't buried at the end of a payment, and let them pick a template at the start of sending instead of the end.
Guide the send instead of paginating it.
Use a wizard with a visible list of steps so the member always knows where they are and what's left.
Make it obvious when something needs action.
Surface payments waiting on approval where people already are, instead of expecting them to remember to go check a tab.
Put help inside the system.
Support links, training links, and tooltips on the fields that are genuinely confusing, using the words our members use and not our internal terminology.
Make approvals easier to work through.
The unapproved payments table has no search and no filtering today, so an approver looking for one specific payment has to scan the whole thing, and payments can only be approved one at a time. US Bank lets approvers filter by date and act on many payments at once, and JuniFunds has a search feature for finding a specific payment, so both of those became opportunities for us.
Let members schedule a payment.
Right now a real-time payment has to be initiated on demand, and more than one member told us they'd like to be able to set one up in advance.
Show members what a payment costs.
Alacriti displays several payment speed options with the fee labeled on each one, so a member can see the tradeoff at the moment they're making the choice, and our system doesn't show fees anywhere in the send flow or on the confirmation screen.
Some of what came out of the research isn't in this build. Bulk send, built-in fraud prevention, and fee transparency were all identified as opportunities and all sit outside the scope of what we're delivering first, so they're documented and waiting.
We're moving off Juniper Payments and building our own version of this product with the same functionality, inside a larger project called the unified system. Today our members reach a set of separate applications through the waffle menu in Members Only, and the unified system brings all of those into one application, with immediate payments as one of them. So for the first time the send experience is something we can actually design.
I'm working inside a shell somebody else built.
The senior UX designer on our team designed the unified system's navigation and established the design style, and I'm inheriting both and building on top of them, because a member moving between immediate payments and any other application in the unified system should not be able to feel the seam.
Newly designed "Send Immediate Payment" experience wireframes.
We're using Minimals UI.
We had been on OutSystems and moved away from it because of the constraints it put on us, and instead of building an entire design system from nothing we picked a well-established one our developers can start from. So the components are consistent and documented, and the team isn't spending its first months arguing about button states.
Sending a payment is three steps with the steps visible.
Step one asks how you want to enter the payment, either starting from a template or entering the information manually. Step two is payment details. Step three is review and confirm. The step list stays on screen the whole time with completed steps marked, so there's no version of this where a member is three fields deep and doesn't know how much is left.
Templates are chosen at the beginning now.
Selecting the template option opens a searchable list of saved templates with the amount shown on each one, and a Create New Template button sits at the top of that list, so creating a template no longer requires starting and completing a payment.
Templates can be viewed and deleted, and not edited.
Each template has a menu with View Details and Delete Template, and deleting one asks for confirmation first and says plainly that it can't be undone. Editing isn't in this release, and that was a compromise I made. We validate the routing number when payment details are entered, and letting a template be edited would create one more place where that validation has to happen on the back end. I did push for delete to at least be an option, because otherwise a member who saved a template with an error in it would be stuck looking at that template until we shipped the functionality to fix it.
13
member interviews across two rounds of research
3
personas
4
payment systems compared
I'm building the wireframes in Figma, a business analyst on the project is writing the user stories, and we review the work together with our product owner, with developers weighing in on feasibility. Templates and the send experience are done and are what's shown above. Payment approval is the other major piece of this product and those wireframes are in progress, so this case study is going up before the project is finished, because the research behind it is finished and the send experience is finished and I'd rather show that than wait.
I'm building the wireframes as an interactive prototype and not as static screens, because our team plans to have members complete user testing on them in 2027, so we can validate the usability of the send experience with the people who will actually be using the product.
What comes next is the approval experience, then wires, then development and launch, and I plan to come back and expand this page as each of those happens. Bulk send, built-in fraud prevention, and fee transparency are all out of scope for the first release and are documented as future opportunities.
Want to talk through this project?
I’m happy to share more about the research, product constraints, and design decisions behind the new immediate payments send experience.
© 2026 Michelle Magruder