ZIVA
Details and data below have been genericized to respect confidentiality.
Making policy management easier for processors and their issuing banks through issuer groups
I designed issuer groups, a new feature in Ziva’s rules tool, so a processor can gather its issuing banks into a group and apply one policy to all of them in a single step. It launched to a small group of processors first, who said it made managing policies across their banks much easier.
ROLE
Sole product designer
SCOPE
Issuer groups page, group creation, policy assignment, moving issuers
PLATFORM
Web, rules tool (desktop)
TEAM
1 PM, 6 developers
TIMELINE
9 months, 2024–2025
THE PROBLEM
Issuers weren’t using the policy tool, and testing showed why
A policy could only be created and applied for one issuer at a time, even for processors managing several hundred banks.
Use of the policy creation tool was low, and user testing with customers showed issuers were frustrated with it. Our PM heard it by word of mouth from issuers in our test sessions and saw it in our analytics dashboards.
WHAT TESTING SURFACED
Writing policies for many issuers took too long.
Creating a policy took too many steps, in a two-step process that made people leave the page mid-task.
There was no way to create a top-level policy and apply it to every bank.
Issuers depended on help from internal teams to get policies set up.
Processors
Felt it most, repeating the same setup for every bank they manage.
Issuing banks
Found the tool frustrating and leaned on internal teams.
Ziva
Spent internal time on setup, with frustrated clients a risk to revenue.
THE GOAL
WHO I WORKED WITH
I was the sole product designer, working with one product manager and a development team of about six. The PM ran testing and brought the processor requirement, and the developers shaped what the existing application could take on. I created the issuer groups concept and led its design, shaping it so the team could build it without reworking the rest of the application.
THE PROCESS
The central decision: assign a policy from the policy page, or from the group?
Testing gave us four complaints: too slow, too many steps, one issuer at a time, and needing help. Most came from one gap. There was no level above a single issuer, so every policy had to be repeated bank by bank. So the real question was where processors should connect one policy to hundreds of banks.
REDESIGN THE WHOLE FLOW · RULED OUT
Too big, for now
One builder for rules, policies and groups. The cleanest long-term answer, but more change than the team could take on.
INSIDE THE POLICY EDITOR · REJECTED
One task, two pages
I mocked it up, but groups still had to exist on the Groups page first, and a screen built for ordering rules ended up holding a list of hundreds of banks.
ON A GROUPS PAGE · CHOSEN
Built for hundreds of banks
The hard part is organizing hundreds of banks, so that work gets a page of its own. A group gets its policy when it’s made, and the policy editor stays focused on rules.
Low-fidelity wireframes of the three options. Each one answers the same question: where does a processor connect a policy to its banks?
Why a Groups page
Each page in the rules tool already owned one kind of thing: rules, policies, lists. A Groups page that owns banks follows the pattern processors already knew, so it felt like part of the tool on day one (Jakob’s Law, applied to the product itself).
THE TRADE-OFF
The policy editor doesn’t show which groups use a policy, so processors go to the Groups page to see that. I accepted this because the processors’ real pain was setting policies up, not reviewing them. To make up for it, each group’s policy name links straight to the policy.
Which policy wins
A processor creates a global policy and applies it to whichever of its banks it chooses. Those become its managed issuers. A bank that needs something different can keep its own custom policy outside the group. Once a group gets a policy, it overrides any policy its banks had before, and a bank can’t override its processor.
This was based on the product’s existing patterns and team feedback, not a formal study of the decision itself. What I’d test next is below.
Finding what the team could ship
I started out wanting to redesign the whole flow, because rules, policies and assignment lived on separate pages. The PM and developers pushed back: it was more change than the team could take on. I scoped down to a single new page that plugs into the existing policies. That let the team ship what processors needed without reworking what already worked, and we showed an early version to the issuers in our test sessions to shape it.
Constraints, and what I did with them
CONSTRAINT
MY CHOICE
The existing rules and policy flow couldn’t be overhauled.
Add Groups as its own page that reuses existing policies, so nothing about building a policy changed.
One processor can have several hundred issuing banks.
Collapsible groups with an issuer count, select all, and an “Issuers to move” tray, so moving banks is one batch action instead of hundreds of edits.
We didn’t yet know how a bank in several groups would resolve competing policies.
Each bank belongs to one group at most until we had more data, so every bank has exactly one group policy.
Each bank sees only its own rules and data; the processor sees all of its banks.
Groups live at the processor level only, so a bank never sees other banks or how they’re grouped.
One global policy, room for exceptions
How a processor’s banks are organized in the rules tool. Bank names are placeholders.
THE SOLUTION
One new page that plugs into the policies processors already had
Organize banks into groups, give each group its policy as it’s made, and confirm before that policy replaces what the banks had.
Screens from the shipped feature are in the full case study, which I’m happy to share on request.
ISSUER GROUPS
Where processors organize their banks
Policy at a glance. Each group shows its policy as a link, so a processor sees what protects those banks and can jump to it.
Built for hundreds. Issuer counts and collapsible groups keep a long list of banks scannable.
Move in one action. The “Issuers to move” tray collects banks across groups, then moves them together.
Room for exceptions. Banks that keep their own policy sit under “Not in a group”, so the default is clear.
CREATE A GROUP
A group gets its policy as it’s made
Two fields. Name and policy are all it takes, so a group is ready to use when it’s saved.
Reach stated up front. The hint says every issuer in the group will use this policy.
CONFIRM THE OVERRIDE
The critical step
Saving a group with a policy overrides any policy its banks had before. Because the change reaches every bank in the group, the processor confirms it first.
Names what changes. The group, the policy and the number of issuers affected.
A clear way back. “Go back” sits beside “Save and override”, so nothing changes by accident.
OUTCOME
What it led to
Built and launched. Issuer groups launched in the rules tool to a small group of processors first.
Welcomed by the people it was for. The three processors we tested with were excited about it, and reported that groups made managing and applying policies across their issuers easier.
One step instead of one per bank. Applying a policy to every bank in a group became a single action.
No rework. Rules, policies and lists kept working as before, so the team took on one new page instead of a redesign.
I don’t have usage numbers to share. This is how I’d measure it:
Satisfaction
A short survey after setting up a group, and repeat sessions with the three issuers we first tested with.
Adoption
The share of processors who move from per-bank policies to group policies after launch.
Engagement
How often processors come back to move issuers or change a group’s policy.
Setup time and support
Time to set up a processor’s banks, and fewer requests to internal teams for help.
REVISIT
The bigger redesign
Looking back, starting with a separate Groups page was the right call. It let processors try groups for real without risking the rules and policies they already relied on. With groups proven, I’d go back to the idea I started with: a single flow where a processor writes rules, builds a policy and picks the groups it applies to, all in one place.
This is an idea to test, not a finished answer. I’d have processors set up a policy for a group in today’s flow and in a prototype of the single flow, then compare the steps, the time and how confident they felt. If the new flow isn’t clearly better than a page they already know, I’d keep groups as they are.
TODAY
Three pages
Rules, then a policy, then the Groups page to apply it.
IDEA TO TEST
One flow
Write rules, build the policy and pick its groups without leaving the page.
RETROSPECTIVE
What I’d test next
Show a policy’s reach
Add a line like “Used by 3 groups” to the policy editor, to close the gap my trade-off left.
Move banks at scale
Test the move tray with hundreds of banks, and add search and filters if people get lost.
Preview before a change
Show which banks a policy change will affect before it’s published.
What I’d do differently
Bring evidence for the full redesign earlier, like a step count of today’s flow, so the team could plan it as a later phase.
FULL CASE STUDY
Want the full story?
The detailed case study covers the screens, flows and design rationale in more depth. I’m happy to share it, or to walk you through it on a call.
NEXT PROJECT
Transaction summary →
Merchant portal · Data visualization