Details have been generalized and data anonymized to protect client confidentiality.
Enterprise SaaS·Workflow Design·Systems Thinking
Designing a rules management platform for finance operations — from 5 tools to one
Finance operations teams were managing accounting rules across Jira, spreadsheets, Teams, email, and phone calls. The work was getting done. Just not with tools built for it.
120+ hrs / yr
of clarification back-and-forth eliminated
5 → 1
steps to send a change for business validation
8 stages
of a fragmented workflow unified into one system
Role
Solo product designer
Timeline
August 2025 – April 2026
Collaborators
UX researcher, PM, engineering
Status
In development
The problem
A critical workflow held together by too many tools
The Accounting Controls Group (ACG) manages the financial rules that determine how transactions map to general ledger outputs. When something needs to change, a request comes in and ACG has to review it, build the rule change, get it approved, and deploy it.
In reality, that process was spread across Jira, spreadsheets, Teams, email, and phone calls. Requests came in incomplete. Clarification loops between analysts and the business teams who submitted requests got buried in Jira comments. A lot of the process knowledge lived with specific people on the team rather than in any shared system or documentation.
"The back-and-forth is what takes the longest. Easily 10 hours a month — just clarifying requests before any actual rule work can start."
A
ACG Analyst
User interview, March 2026
We started at the end of August 2025 but didn't get access to users until mid-January 2026. For that first stretch, the design work was exploratory, based on what the tech team could tell us about the workflow. Once interviews began, being able to observe how analysts actually worked was invaluable. Several assumptions shifted significantly based on what we heard.
✏️
Design note — No user access for five months. Several assumptions shifted once interviews began.
5tools
XLSTeamsEmailPhone
12–15requests / month
each needing multiple rounds of clarification before any rule work could start
310rule matrices
holding 22,000+ individual lines — managed entirely in spreadsheets
Why this was uniquely complex
Why the workflow couldn't be solved with a UI refresh
A few things made this harder than a typical workflow redesign.
018-stage workflow across 3 actor groups with no shared system of record
02High governance sensitivity, since rules directly impact financial outputs and audit trails
03A lot of process knowledge lived with specific people on the team rather than in shared documentation or tooling
04The business had no visibility into what rules already existed, making it hard to know if a requested rule was new, already active, or just sitting dormant in a spreadsheet
05No access to users for the first five months, so early design decisions had to be based on what the tech team described rather than observed behavior
06Changes were made directly in production with no test environment, so accuracy and confidence before sign-off mattered enormously
✏️
Design note — We assumed rule creation was the hard part. Interviews revealed the real bottleneck was request clarification.
Mapping the system
We couldn't design the future state until the team agreed on how the process actually worked
Documenting the end-to-end workflow was a core part of the research phase. Neither design nor the broader team came in with deep domain knowledge, so understanding how the process actually worked across all stages was necessary before identifying where the real gaps were.
It also gave stakeholders a clearer picture of where friction was happening and where requests were getting stuck. Seeing the full workflow laid out made it easier to have conversations about sequencing, ownership, and where the process was breaking down.
8-stage workflow across business teams, ACG analysts, and governance
Business
Submit request
Validate
ACG
Verify & challenge
Decision
Build rule
Test
Approve
Deploy
Governance
NPA review (conditional)
Business
ACG
Conditional
The design
The request page was where the whole workflow came together
The request details page needed to support active decision-making at every stage, not just display information. Because the workflow has distinct phases, and different actions are available at each one, the page adapts based on where the request is and what still needs to happen.
Role context
This view belongs to an ACG team member who can update rules and act on requests assigned to them, but can't reassign requests or access other teams' work. The locked and unlocked states reflect both workflow sequencing and user permissions. What's available changes based on role and where the request is in the process.
Two states show how the experience changes across the workflow.
Screen 01 of 02
Incoming request
A new request arrives. ACG reviews the details, verifies the intent, and classifies it to a rule before any build work begins.
Status banner as instructionTells ACG exactly what to do next in plain language instead of showing a status label. Replaces the tracking analysts were doing across Jira and side conversations.
Classification as the first actionACG links the request to an existing rule and initiates a cloned draft version for editing. Active logic is never touched directly. The decision point is now visible in the UI.
Downstream locked until classifiedOutput preview and deployment stay unavailable until classification is complete. The sequence is enforced by the interface, not documentation.
Screen 02 of 02
Ready for approval
Execution is complete. The rule has been classified, built, and verified. ACG sends it to the requester for confirmation before deploying.
Execution completeThe banner updates to reflect work done. ACG knows exactly where the request is and what to do next without checking another tool.
Diff view for rule impactACG sees exactly which fields changed, not just the proposed state. The side-by-side comparison is what makes confident approval possible instead of guesswork.
Gated deploymentDeploy stays locked until the requester confirms over email. The governance sequence is enforced by the system, not by convention.
Key decisions
Three decisions changed the direction of the project
01
Workflow state tied to actions within the system
Each stage advances because someone completed actual work. Classifying a request moves it forward, saving the rule change moves it to the next stage. Status changes happen as part of the work rather than as a separate manual update. ACG typically worked from cloned versions of rules with effective dates so active rules stayed stable until deployment. The activity feed captures what happened and when, which matters for audit traceability.
02
Aligning the workflow before scaling the interface
The workflow spanned eight stages across multiple teams, and without a shared picture of how it connected end-to-end, it was difficult to make design decisions that held up across the full process. Documenting it gave everyone a common reference point, which made sequencing, ownership, and cross-team decision-making significantly easier.
03
Designed for a two-sided platform, built for one side first
Business users were still working out of Jira at the time, so the design had to fit that reality. For now, the requester confirms the change over email with a structured summary of the rule diff and its impact. But the platform is already built to bring them in directly later. The approval steps and rule visibility they would need are designed in, so the workflow doesn't have to be rebuilt when they move into the system.
Outcomes
What it changed for the analysts
Not every part of the workflow changed. These three did, in specific, measurable ways.
✅
Intake validation
Complete submissions required before a request enters the system. Analysts described spending easily 10+ hours a month — over 120 hours a year — chasing missing fields. That loop doesn't exist if the system won't accept an incomplete request.
✉️
Business validation
One action replaces five manual steps. The structured summary — rule diff, evidence, and impact estimate — goes out automatically. Nothing to assemble.
🗂️
Audit trail
Approvals and change history move into the platform. Who approved what and when is one click, not a Jira search.
