A
Work / 360 Control deliberately no AI
Contact
100% ▾
PAGES
Home Work / 360 Control About
CASE STUDIES
Disputes Workspace 360 Control CPQ Design System
SECTIONS
00 · Cover
01 · Context
02 · Dual Role
03 · The Problem
04 · Research
05 · System First
06 · The Solutions
07 · Why No AI
08 · Validation
09 · Impact
10 · Learnings
PROJECT
360 Control
clientFiserv
launch clientDesjardins
roleUX + product owner
domainIssuer admin
platformsDesktop + mobile
OUTCOMES
Shipped on time
contractual Desjardins deadline met
Division-wide DS
design system adopted beyond the project
FR + EN, themed
bilingual, client-branded platform
UP NEXT
CPQ →
enterprise quoting, 18 → 10 min
◇ 00 · Cover
CASE STUDY 02 · FISERV × DESJARDINS

360 Control: rebuilding a financial admin system from the ground up

360 Control is the issuer administration console financial institutions use to run commercial card programs, managing cardholders, setting spend controls, handling credit limits, auditing every change. This is the story of a new information architecture, a design system built before a single screen was drawn, and a hard contractual deadline for one of Canada's largest financial cooperatives.

360 Control, one platform, four roles, zero confusion
◇ 01 · Context

Context

A platform showing its age

By 2024, 360 Control carried the wear of years of incremental development by different teams: no shared UX language, desktop-only, and navigation organized around system features rather than user intent. Admins held a mental map of the system's architecture just to do their jobs.

Then Desjardins signed

One of Canada's largest financial cooperatives came with specific requirements, bilingual support, custom data fields, a branded experience, mobile access, and one immovable constraint: a contractual onboarding deadline. The rewrite was no longer optional.

THE BRIEF

Consistency, mobile access, and a better experience for the admins and cardholders who spent hours in this system every day, delivered on a deadline that couldn't move.

◇ 02 · Dual Role

Designer and product owner, at the same time

I was the sole UX designer and an embedded product owner simultaneously. That structure wasn't a formality, it changed how the whole project ran. Design intent wasn't handed off; it was built into every refinement session, every backlog call, every sprint.

There were moments when the right UX approach needed more time than the timeline allowed. In those moments the product owner in me had to make the call: scope it for Phase 1, protect the intent for Phase 2. Knowing when to defer UX ideals without losing them entirely was one of the harder skills this role demanded, and what made the dual structure work.

End-to-end UX Backlog ownership IA redesign Design system Scope & phasing decisions CAT release validation
◇ 03 · The Problem

The problem

The system made users think like engineers to do basic operations work.

PAIN 01

Feature-based navigation

The IA reflected how the system was built, not how anyone used it. Completing a single task meant jumping between disconnected modules.

PAIN 02

High-risk actions, no safety net

Updating a credit limit, replacing a card, changing permissions, actions with real financial consequences had no preview, no confirmation patterns, no undo.

PAIN 03

No meaningful landing page

Admins navigated blind into deep menus with no context about which issuer they were managing or what had recently changed.

PAIN 04

Audit by support ticket

A compliance officer wanting to know who changed a credit limit last quarter had to raise a support request and wait for a database lookup.

◇ 04 · Research

Research under constraints

Direct access to issuer administrators wasn't feasible, client-access constraints and timeline pressure made it a non-starter. So I used every input available and organized the work around one question:

"What does an issuer administrator actually do when the system makes this hard?"

Heuristic evaluation
Mapped every core workflow in the legacy platform and where it failed the user.
Structured SME sessions
Domain experts who knew how admins actually worked around the system.
BRD review
Business requirements translated into design constraints and priorities.
Support-ticket analysis
Where users got stuck, in their own words, at volume.
RISK INSIGHT

In financial systems, predictable is trustworthy. Every inconsistent interaction pattern added risk for admins moving real money.

STRUCTURAL INSIGHT

Configuration ≠ Operations. Keeping them separate in the IA removed the single biggest source of admin confusion.

On research constraints: stakeholder-driven research works, but it's not a substitute for watching real users. Validation happened through weekly stakeholder reviews, engineering refinement, and monthly CAT releases with real data.

◇ 05 · System First

The design system came before the screens

I built the design system before designing any product screen, working from Fiserv's Pixel design language as a foundation and extending it for everything 360 Control needed: foundation elements, data-dense grid patterns, form conventions, confirmation and safety patterns for high-risk actions.

The single highest-impact decision: a unified grid pattern, the same interaction model across Users, Cards, Transactions, and Audit Logs. It did more for platform cohesion than any visual design choice. Learn the grid once, and every section of the platform behaves the way you expect.

Unified patterns, wizard flow screens Unified grid pattern across modules
◇ 06 · The Solutions

The solutions

One guiding principle behind all of them: users should be able to complete a task without jumping between sections. Everything needed to complete an action lives where that action lives.

SOLUTION 01

Intent-based information architecture

The key decision: explicitly separating configuration workflows (setup mode) from operational workflows (day-to-day mode). Admins know what kind of work they're doing before they touch a single feature.

Result: the IA redesign had more impact on usability than any visual decision on the project.

Role and structure mapping, cardholders, issuer, program admins
360 Control landing dashboard
SOLUTION 02

A landing page with actual context

The legacy platform dropped admins into deep menus blind. The new dashboard answers the first three questions of any session: which issuer am I managing, what changed recently, and what needs my attention now.

SOLUTION 03

User & card management, end to end

The most heavily used part of the platform, redesigned as complete flows instead of disconnected modules. Add User and Add Card became wizard flows with manageable steps and consistent patterns, one admin tester described the new flow as something they "could finally teach in one sitting." When Desjardins admins noted that cards are sometimes delegated to them, I added a dedicated "My Cards" space for program administrators managing both their own and delegated cards.

Result: single tasks no longer span multiple modules; new-admin onboarding became a teachable flow.

SOLUTION 04

Spend controls you can preview

The legacy spend controls had hardcoded rules and no preview of impact before applying. The UX problem wasn't rule complexity, it was that the interface forced engineers' mental models on admins. I consolidated everything into one focused task flow: progressive disclosure for advanced options, and a clear distinction between defining a rule and seeing its impact.

Result: CAT issues on Advanced Spend Controls were medium-severity observations, not blockers, baseline usability held even at full complexity. The feature drew interest from other banking clients previewing the platform.

Spend control configuration flow
SOLUTION 05

Audit logs in the UI, not in a ticket queue

A comprehensive Business Audit Log built directly into the interface, accessible at company level, card level, and user level, filterable by action type, date range, and actor. No more backend lookups for a question the UI should answer.

Result: Desjardins' security team could immediately see the oversight required for regulatory compliance. Audit visibility became a client trust signal, not a compliance checkbox.

360 Control mobile, program admin navigation 360 Control mobile, users and cards with quick actions
SOLUTION 06

Mobile: a requirement, not an afterthought

Mobile was a Desjardins requirement from day one. I introduced it after core desktop flows stabilized, a deliberate sequencing decision to avoid compounding complexity during the IA redesign. The unified patterns made the translation systematic rather than bespoke.

360 Control as a native presence on the phone
SOLUTIONS 07–09

AutoPay, theming, and what's queued next

Native Manage AutoPay

Integrated with Users, Cards, and a new Billing Control Accounts view, configure autopay for one card or an entire account.

Desjardins theming + bilingual

Custom brand theme and full French translation support, designed into the system rather than bolted on.

Transactions + disputes (planned)

The transactions grid redesigned as a query-and-reporting surface, with dispute integration queued for a later phase.

◇ 07 · Why No AI
A DELIBERATE DESIGN DECISION

Why 360 Control has no AI, on purpose

Everything in 360 Control is strategy-driven: human-defined authorization strategies, configurable spend-control logic, one-to-many rule application, real-time deterministic enforcement. Every outcome traces to a specific rule that a specific administrator defined. These are not AI inferences, they're explicit business rules the system executes predictably.

Knowing when to use AI and when to deliberately avoid it is the more mature design skill. 360 Control isn't limited by the absence of AI, it's made more trustworthy by it. This contrasts directly with my work on Disputes Workspace, where ML was strategically applied to cut call time and improve classification. Two different domains, two different answers, one principle: the technology serves the trust model, never the other way around.

Compare: where I did use AI → Disputes Workspace
◇ 08 · Validation

Validated in production-like conditions

Rather than designing everything upfront and launching once, we used CAT environments for incremental, limited-scope releases. Each monthly drop validated designs with real data and realistic workflows, design assumptions met reality every four weeks, not once at the end.

CADENCE

Monthly CAT releases with real data; weekly stakeholder reviews; design refinement embedded in every engineering sprint.

SIGNAL

Advanced Spend Controls, the platform's most complex feature, produced only medium-severity observations in CAT. The baseline held.

PULL

Other banking clients previewing the platform before full launch expressed interest, the redesign became a sales asset.

◇ 09 · Impact

Impact

Shipped on time

Meeting the contractual obligation to onboard Desjardins on schedule was the primary business outcome. Phase 1 delivered it.

Beyond the project

The 360 Control design system is becoming the foundation for a unified design language across Fiserv's Issuer Solutions division.

Trust made visible

Built-in audit visibility turned a compliance requirement into a client trust signal during Desjardins' security review.

360 Control, themed operational view
◇ 10 · Learnings

Learnings

360 Control isn't a flashy consumer product. It's a complex enterprise system where UX mistakes have real financial and regulatory consequences, and that context made every decision matter more.

01

Structure matters more than surface

The IA redesign from feature-based to intent-based navigation had more impact on usability than any visual decision. Get the structure right first, separate config from operations, then refine the surface.

02

Being embedded in delivery beats handoffs every time

Owning refinement meant design intent was built into every sprint rather than translated (and diluted) through documents.

03

Restraint is a design skill

Choosing deterministic rules over AI, phasing scope without losing intent, sequencing mobile after desktop, the hard calls were about what not to do yet.

What I'd do differently

Think about mobile constraints earlier

Sequencing mobile after desktop was intentional, but considering its constraints during desktop design would have made the translation smoother.

Watch a few real admins

Stakeholder-driven research worked, but observing even a few real issuer admins would have validated assumptions and uncovered edge cases earlier.

NEXT CASE STUDY
CPQ: from 18 minutes to 10 per quote
© 2026 Abhikant Nirbhavane case study · 360 control