flexible
signing
alfa-bank
product designer
2022-2023
flexible
signing
alfa-bank
product designer
2022-2023
flexible
signing
alfa-bank
product designer
2022-2023
flexible
signing
alfa-bank
product designer
2022-2023
flexible
signing
alfa-bank
product designer
2022-2023
about
project
Flexible signing rules for approvals in business banking
The Signing Rules feature helps businesses set up approval flows: who signs each operation, under what conditions, and in which order. It reduces manual checks and makes signing logic clear across the team, so operations stay secure and predictable.
VOC (from 3,6 to 4,43 out of 5)
4,43
Rule builder usage growth
+37%
Successfully created rules
87%
MAU
+32,2%
my role
In this project, I identified UX issues in the signing rules product and redesigned its structure and main flows to improve clarity and prepare the interface for future features.
problems
• The homepage was overloaded and hard to navigate • Users could not understand where to create or edit signing rules • The rule setup flow lacked structure, which caused confusion and slowed down work • Users couldn’t review rule logic from the homepage without opening each rule • Primary actions (“Create rule” and “Edit”) were easy to miss, blocking the start of the workflow
business goals
• Reduce time spent on configuring signing rules to speed up operations • Decrease user mistakes during operation signing and rule setup • Strengthen security through a more transparent and controlled signing flow • Reduce support load and manual reviews by making rules easier to audit • Improve customer satisfaction with a clearer and more reliable signing process
actions
• Identified key UX issues and success metrics for the redesign • Ran interviews and usability walkthroughs with SMB users • Reworked the core flows to make rule setup faster and more predictable • Aligned design with product, QA, and engineers to ensure correct implementation • Validated impact post-release using product analytics and VOC tracking
results
• Time to audit complex rules: −80% • First-time success rate for creating valid rules: 87% • Median time to create and validate a new rule: 3× faster • VOC: from 3,6 to 4,43 out of 5 • MAU post-release: +32.2% • Rule builder usage growth: +37%
about
project
Flexible signing rules for approvals in business banking
The Signing Rules feature helps businesses set up approval flows: who signs each operation, under what conditions, and in which order. It reduces manual checks and makes signing logic clear across the team, so operations stay secure and predictable.
VOC (from 3,6 to 4,43 out of 5)
4,43
Rule builder usage growth
+37%
Successfully created rules
87%
MAU
+32,2%
my role
In this project, I identified UX issues in the signing rules product and redesigned its structure and main flows to improve clarity and prepare the interface for future features.
problems
• The homepage was overloaded and hard to navigate • Users could not understand where to create or edit signing rules • The rule setup flow lacked structure, which caused confusion and slowed down work • Users couldn’t review rule logic from the homepage without opening each rule • Primary actions (“Create rule” and “Edit”) were easy to miss, blocking the start of the workflow
business goals
• Reduce time spent on configuring signing rules to speed up operations • Decrease user mistakes during operation signing and rule setup • Strengthen security through a more transparent and controlled signing flow • Reduce support load and manual reviews by making rules easier to audit • Improve customer satisfaction with a clearer and more reliable signing process
actions
• Identified key UX issues and success metrics for the redesign • Ran interviews and usability walkthroughs with SMB users • Reworked the core flows to make rule setup faster and more predictable • Aligned design with product, QA, and engineers to ensure correct implementation • Validated impact post-release using product analytics and VOC tracking
results
• Time to audit complex rules: −80% • First-time success rate for creating valid rules: 87% • Median time to create and validate a new rule: 3× faster • VOC: from 3,6 to 4,43 out of 5 • MAU post-release: +32.2% • Rule builder usage growth: +37%
about
project
Flexible signing rules for approvals in business banking
The Signing Rules feature helps businesses set up approval flows: who signs each operation, under what conditions, and in which order. It reduces manual checks and makes signing logic clear across the team, so operations stay secure and predictable.
VOC (from 3,6 to 4,43 out of 5)
4,43
Rule builder usage growth
+37%
Successfully created rules
87%
MAU
+32,2%
my role
In this project, I identified UX issues in the signing rules product and redesigned its structure and main flows to improve clarity and prepare the interface for future features.
problems
• The homepage was overloaded and hard to navigate • Users could not understand where to create or edit signing rules • The rule setup flow lacked structure, which caused confusion and slowed down work • Users couldn’t review rule logic from the homepage without opening each rule • Primary actions (“Create rule” and “Edit”) were easy to miss, blocking the start of the workflow
business goals
• Reduce time spent on configuring signing rules to speed up operations • Decrease user mistakes during operation signing and rule setup • Strengthen security through a more transparent and controlled signing flow • Reduce support load and manual reviews by making rules easier to audit • Improve customer satisfaction with a clearer and more reliable signing process
actions
• Identified key UX issues and success metrics for the redesign • Ran interviews and usability walkthroughs with SMB users • Reworked the core flows to make rule setup faster and more predictable • Aligned design with product, QA, and engineers to ensure correct implementation • Validated impact post-release using product analytics and VOC tracking
results
• Time to audit complex rules: −80% • First-time success rate for creating valid rules: 87% • Median time to create and validate a new rule: 3× faster • VOC: from 3,6 to 4,43 out of 5 • MAU post-release: +32.2% • Rule builder usage growth: +37%
about
project
Flexible signing rules for approvals in business banking
The Signing Rules feature helps businesses set up approval flows: who signs each operation, under what conditions, and in which order. It reduces manual checks and makes signing logic clear across the team, so operations stay secure and predictable.
VOC (from 3,6 to 4,43 out of 5)
4,43
Rule builder usage growth
+37%
Successfully created rules
87%
MAU
+32,2%
my role
In this project, I identified UX issues in the signing rules product and redesigned its structure and main flows to improve clarity and prepare the interface for future features.
problems
• The homepage was overloaded and hard to navigate • Users could not understand where to create or edit signing rules • The rule setup flow lacked structure, which caused confusion and slowed down work • Users couldn’t review rule logic from the homepage without opening each rule • Primary actions (“Create rule” and “Edit”) were easy to miss, blocking the start of the workflow
business goals
• Reduce time spent on configuring signing rules to speed up operations • Decrease user mistakes during operation signing and rule setup • Strengthen security through a more transparent and controlled signing flow • Reduce support load and manual reviews by making rules easier to audit • Improve customer satisfaction with a clearer and more reliable signing process
actions
• Identified key UX issues and success metrics for the redesign • Ran interviews and usability walkthroughs with SMB users • Reworked the core flows to make rule setup faster and more predictable • Aligned design with product, QA, and engineers to ensure correct implementation • Validated impact post-release using product analytics and VOC tracking
results
• Time to audit complex rules: −80% • First-time success rate for creating valid rules: 87% • Median time to create and validate a new rule: 3× faster • VOC: from 3,6 to 4,43 out of 5 • MAU post-release: +32.2% • Rule builder usage growth: +37%
about
project
Flexible signing rules for approvals in business banking
The Signing Rules feature helps businesses set up approval flows: who signs each operation, under what conditions, and in which order. It reduces manual checks and makes signing logic clear across the team, so operations stay secure and predictable.
VOC (from 3,6 to 4,43 out of 5)
4,43
Rule builder usage growth
+37%
Successfully created rules
87%
MAU
+32,2%
my role
In this project, I identified UX issues in the signing rules product and redesigned its structure and main flows to improve clarity and prepare the interface for future features.
problems
• The homepage was overloaded and hard to navigate • Users could not understand where to create or edit signing rules • The rule setup flow lacked structure, which caused confusion and slowed down work • Users couldn’t review rule logic from the homepage without opening each rule • Primary actions (“Create rule” and “Edit”) were easy to miss, blocking the start of the workflow
business goals
• Reduce time spent on configuring signing rules to speed up operations • Decrease user mistakes during operation signing and rule setup • Strengthen security through a more transparent and controlled signing flow • Reduce support load and manual reviews by making rules easier to audit • Improve customer satisfaction with a clearer and more reliable signing process
actions
• Identified key UX issues and success metrics for the redesign • Ran interviews and usability walkthroughs with SMB users • Reworked the core flows to make rule setup faster and more predictable • Aligned design with product, QA, and engineers to ensure correct implementation • Validated impact post-release using product analytics and VOC tracking
results
• Time to audit complex rules: −80% • First-time success rate for creating valid rules: 87% • Median time to create and validate a new rule: 3× faster • VOC: from 3,6 to 4,43 out of 5 • MAU post-release: +32.2% • Rule builder usage growth: +37%
terminology
What is going on here
We built Flexible Signing Rules so companies can configure custom signing flows instead of relying on fixed templates. In corporate banking, signing logic often depends on amount, product, or company structure, so complex operations stay safe and consistent.
terminology
What is going on here
We built Flexible Signing Rules so companies can configure custom signing flows instead of relying on fixed templates. In corporate banking, signing logic often depends on amount, product, or company structure, so complex operations stay safe and consistent.
terminology
What is going on here
We built Flexible Signing Rules so companies can configure custom signing flows instead of relying on fixed templates. In corporate banking, signing logic often depends on amount, product, or company structure, so complex operations stay safe and consistent.
terminology
What is going on here
We built Flexible Signing Rules so companies can configure custom signing flows instead of relying on fixed templates. In corporate banking, signing logic often depends on amount, product, or company structure, so complex operations stay safe and consistent.
what are signing rules?
Signing rules define who must approve an operation and in what order. A rule can include multiple signers, limits, conditions, and sequential or parallel signing logic. Rules are applied automatically based on operation parameters.
who is a signer?
A signer is a user with a role that allows approving specific operations. A signer can participate in a signing process only if their role meets the rule conditions and they have permission to sign the selected product.
what makes a rule flexible?
A flexible signing rule is a configurable approval logic that replaces default signing templates. It allows companies to define custom signer sets, limits, and sequences for different products and scenarios without rigid constraints.
discovery
Validating how teams set signing rules for real operations
Together with a UX laboratory, I ran user research to see how companies configure signing rules for operations and where complexity breaks the flow.
discovery
Validating how teams set signing rules for real operations
Together with a UX laboratory, I ran user research to see how companies configure signing rules for operations and where complexity breaks the flow.
discovery
Validating how teams set signing rules for real operations
Together with a UX laboratory, I ran user research to see how companies configure signing rules for operations and where complexity breaks the flow.
discovery
Validating how teams set signing rules for real operations
Together with a UX laboratory, I ran user research to see how companies configure signing rules for operations and where complexity breaks the flow.
discovery
Validating how teams set signing rules for real operations
Together with a UX laboratory, I ran user research to see how companies configure signing rules for operations and where complexity breaks the flow.
methodology:
• 4 participants from small and medium businesses (owners and accountants) • In-depth interviews combined with usability walkthroughs (30–40 min each) • Internal review with product and QA teams to validate flow logic
research goals:
• Understand how users create and apply flexible signing rules across different products • Identify unclear steps and usability issues during the setup process • Define opportunities to simplify and automate signing rule configuration
key tasks:
• Observe how users set up rules, assign signers, and manage limits • Collect feedback on difficulties and confusing parts of the flow • Propose UX improvements to make the process faster, clearer, and more consistent
methodology:
• 4 participants from small and medium businesses (owners and accountants) • In-depth interviews combined with usability walkthroughs (30–40 min each) • Internal review with product and QA teams to validate flow logic
research goals:
• Understand how users create and apply flexible signing rules across different products • Identify unclear steps and usability issues during the setup process • Define opportunities to simplify and automate signing rule configuration
key tasks:
• Observe how users set up rules, assign signers, and manage limits • Collect feedback on difficulties and confusing parts of the flow • Propose UX improvements to make the process faster, clearer, and more consistent
methodology:
• 4 participants from small and medium businesses (owners and accountants) • In-depth interviews combined with usability walkthroughs (30–40 min each) • Internal review with product and QA teams to validate flow logic
research goals:
• Understand how users create and apply flexible signing rules across different products • Identify unclear steps and usability issues during the setup process • Define opportunities to simplify and automate signing rule configuration
key tasks:
• Observe how users set up rules, assign signers, and manage limits • Collect feedback on difficulties and confusing parts of the flow • Propose UX improvements to make the process faster, clearer, and more consistent
methodology:
• 4 participants from small and medium businesses (owners and accountants) • In-depth interviews combined with usability walkthroughs (30–40 min each) • Internal review with product and QA teams to validate flow logic
research goals:
• Understand how users create and apply flexible signing rules across different products • Identify unclear steps and usability issues during the setup process • Define opportunities to simplify and automate signing rule configuration
key tasks:
• Observe how users set up rules, assign signers, and manage limits • Collect feedback on difficulties and confusing parts of the flow • Propose UX improvements to make the process faster, clearer, and more consistent
methodology:
• 4 participants from small and medium businesses (owners and accountants) • In-depth interviews combined with usability walkthroughs (30–40 min each) • Internal review with product and QA teams to validate flow logic
research goals:
• Understand how users create and apply flexible signing rules across different products • Identify unclear steps and usability issues during the setup process • Define opportunities to simplify and automate signing rule configuration
key tasks:
• Observe how users set up rules, assign signers, and manage limits • Collect feedback on difficulties and confusing parts of the flow • Propose UX improvements to make the process faster, clearer, and more consistent
Research insights
Usability tests and short interviews showed that users struggled to understand role types and navigation. They had trouble finding options, creating rules, and locating key actions:
Research insights
Usability tests and short interviews showed that users struggled to understand role types and navigation. They had trouble finding options, creating rules, and locating key actions:
Research insights
Usability tests and short interviews showed that users struggled to understand role types and navigation. They had trouble finding options, creating rules, and locating key actions:
Research insights
Usability tests and short interviews showed that users struggled to understand role types and navigation. They had trouble finding options, creating rules, and locating key actions:
Research insights
Usability tests and short interviews showed that users struggled to understand role types and navigation. They had trouble finding options, creating rules, and locating key actions:
“I don’t understand the difference between standard and individual roles. It’s not explained clearly, which causes confusion.”
“I don’t understand the difference between standard and individual roles. It’s not explained clearly, which causes confusion.”
“I don’t understand the difference between standard and individual roles. It’s not explained clearly, which causes confusion.”
“I don’t understand the difference between standard and individual roles. It’s not explained clearly, which causes confusion.”
“I don’t understand the difference between standard and individual roles. It’s not explained clearly, which causes confusion.”
"I couldn't figure out how to create a rule. The interface doesn't guide me, and I spent a lot of time trying to find the right option"
"I couldn't figure out how to create a rule. The interface doesn't guide me, and I spent a lot of time trying to find the right option"
"I couldn't figure out how to create a rule. The interface doesn't guide me, and I spent a lot of time trying to find the right option"
"I couldn't figure out how to create a rule. The interface doesn't guide me, and I spent a lot of time trying to find the right option"
"I couldn't figure out how to create a rule. The interface doesn't guide me, and I spent a lot of time trying to find the right option"
"The page is too cluttered, making it hard to navigate. Everything seems mixed up, and it’s difficult to find what I need.”
"The page is too cluttered, making it hard to navigate. Everything seems mixed up, and it’s difficult to find what I need.”
"The page is too cluttered, making it hard to navigate. Everything seems mixed up, and it’s difficult to find what I need.”
"The page is too cluttered, making it hard to navigate. Everything seems mixed up, and it’s difficult to find what I need.”
"The page is too cluttered, making it hard to navigate. Everything seems mixed up, and it’s difficult to find what I need.”
"There is no clear structure of sections, and I constantly get lost while trying to find the information I need”
"There is no clear structure of sections, and I constantly get lost while trying to find the information I need”
"There is no clear structure of sections, and I constantly get lost while trying to find the information I need”
"There is no clear structure of sections, and I constantly get lost while trying to find the information I need”
"There is no clear structure of sections, and I constantly get lost while trying to find the information I need”
"Sometimes, it’s hard to quickly locate important features because they’re hidden or placed in unclear spots"
"Sometimes, it’s hard to quickly locate important features because they’re hidden or placed in unclear spots"
"Sometimes, it’s hard to quickly locate important features because they’re hidden or placed in unclear spots"
"Sometimes, it’s hard to quickly locate important features because they’re hidden or placed in unclear spots"
"Sometimes, it’s hard to quickly locate important features because they’re hidden or placed in unclear spots"
"The interface is overly cluttered with lengthy lists of operations and lacks a clear structure. Trying to understand and create a rule feels like a real struggle.
"The interface is overly cluttered with lengthy lists of operations and lacks a clear structure. Trying to understand and create a rule feels like a real struggle.
"The interface is overly cluttered with lengthy lists of operations and lacks a clear structure. Trying to understand and create a rule feels like a real struggle.
"The interface is overly cluttered with lengthy lists of operations and lacks a clear structure. Trying to understand and create a rule feels like a real struggle.
main page
Where signing rules start
It’s the starting point for managing signing rules. Users should quickly see which rules are set up, where they apply, and the key parameters, without opening each rule one by one.
main page
Where signing rules start
It’s the starting point for managing signing rules. Users should quickly see which rules are set up, where they apply, and the key parameters, without opening each rule one by one.
main page
Where signing rules start
It’s the starting point for managing signing rules. Users should quickly see which rules are set up, where they apply, and the key parameters, without opening each rule one by one.
main page
Where signing rules start
It’s the starting point for managing signing rules. Users should quickly see which rules are set up, where they apply, and the key parameters, without opening each rule one by one.
main page
Where signing rules start
It’s the starting point for managing signing rules. Users should quickly see which rules are set up, where they apply, and the key parameters, without opening each rule one by one.
Before redesign
The previous signing rules screen lacked structure making it difficult for users to assess active restrictions. Usability testing showed that key actions were hidden and the dense text layout forced users to read every line just to understand the basic setup.
Before redesign
The previous signing rules screen lacked structure making it difficult for users to assess active restrictions. Usability testing showed that key actions were hidden and the dense text layout forced users to read every line just to understand the basic setup.
Before redesign
The previous signing rules screen lacked structure making it difficult for users to assess active restrictions. Usability testing showed that key actions were hidden and the dense text layout forced users to read every line just to understand the basic setup.
Before redesign
The previous signing rules screen lacked structure making it difficult for users to assess active restrictions. Usability testing showed that key actions were hidden and the dense text layout forced users to read every line just to understand the basic setup.
Before redesign
The previous signing rules screen lacked structure making it difficult for users to assess active restrictions. Usability testing showed that key actions were hidden and the dense text layout forced users to read every line just to understand the basic setup.
Problems
The screen was overloaded with dense text and lacked visual hierarchy making it nearly impossible for users to scan the content and locate specific rules without reading every line.
Users consistently overlooked the «Create rule» primary action because it blended with the content blocking the start of the workflow and causing unnecessary friction.
The operations list failed to visualize the actual security coverage making it easy for users to miss critical gaps or inconsistencies in financial protection.
Interaction patterns varied across different sections of the screen which significantly increased cognitive load and the likelihood of operational errors during complex setups.
Problems
The screen was overloaded with dense text and lacked visual hierarchy making it nearly impossible for users to scan the content and locate specific rules without reading every line.
Users consistently overlooked the «Create rule» primary action because it blended with the content blocking the start of the workflow and causing unnecessary friction.
The operations list failed to visualize the actual security coverage making it easy for users to miss critical gaps or inconsistencies in financial protection.
Interaction patterns varied across different sections of the screen which significantly increased cognitive load and the likelihood of operational errors during complex setups.
Problems
The screen was overloaded with dense text and lacked visual hierarchy making it nearly impossible for users to scan the content and locate specific rules without reading every line.
Users consistently overlooked the «Create rule» primary action because it blended with the content blocking the start of the workflow and causing unnecessary friction.
The operations list failed to visualize the actual security coverage making it easy for users to miss critical gaps or inconsistencies in financial protection.
Interaction patterns varied across different sections of the screen which significantly increased cognitive load and the likelihood of operational errors during complex setups.
Problems
The screen was overloaded with dense text and lacked visual hierarchy making it nearly impossible for users to scan the content and locate specific rules without reading every line.
Users consistently overlooked the «Create rule» primary action because it blended with the content blocking the start of the workflow and causing unnecessary friction.
The operations list failed to visualize the actual security coverage making it easy for users to miss critical gaps or inconsistencies in financial protection.
Interaction patterns varied across different sections of the screen which significantly increased cognitive load and the likelihood of operational errors during complex setups.
Problems
The screen was overloaded with dense text and lacked visual hierarchy making it nearly impossible for users to scan the content and locate specific rules without reading every line.
Users consistently overlooked the «Create rule» primary action because it blended with the content blocking the start of the workflow and causing unnecessary friction.
The operations list failed to visualize the actual security coverage making it easy for users to miss critical gaps or inconsistencies in financial protection.
Interaction patterns varied across different sections of the screen which significantly increased cognitive load and the likelihood of operational errors during complex setups.
After redesign
I unified all rules into a single categorized table. This created a clear starting point for management and made key actions like «Create rule» instantly discoverable.
After redesign
I unified all rules into a single categorized table. This created a clear starting point for management and made key actions like «Create rule» instantly discoverable.
After redesign
I unified all rules into a single categorized table. This created a clear starting point for management and made key actions like «Create rule» instantly discoverable.
After redesign
I unified all rules into a single categorized table. This created a clear starting point for management and made key actions like «Create rule» instantly discoverable.
After redesign
I unified all rules into a single categorized table. This created a clear starting point for management and made key actions like «Create rule» instantly discoverable.
Problem and solution
Problem: The signing setup was a «black box». Critical details were hidden inside nested pages, making it impossible to assess the overall security posture. This forced users to open rules one by one, leading to slow reviews and frequent configuration errors.
Solution: I consolidated all rules into a single transparent table. By surfacing key logic like limits and signer sequences I empowered users to audit and manage the entire configuration at a glance eliminating repetitive navigation.
Problem and solution
Problem: The signing setup was a «black box». Critical details were hidden inside nested pages, making it impossible to assess the overall security posture. This forced users to open rules one by one, leading to slow reviews and frequent configuration errors.
Solution: I consolidated all rules into a single transparent table. By surfacing key logic like limits and signer sequences I empowered users to audit and manage the entire configuration at a glance eliminating repetitive navigation.
Problem and solution
Problem: The signing setup was a «black box». Critical details were hidden inside nested pages, making it impossible to assess the overall security posture. This forced users to open rules one by one, leading to slow reviews and frequent configuration errors.
Solution: I consolidated all rules into a single transparent table. By surfacing key logic like limits and signer sequences I empowered users to audit and manage the entire configuration at a glance eliminating repetitive navigation.
Problem and solution
Problem: The signing setup was a «black box». Critical details were hidden inside nested pages, making it impossible to assess the overall security posture. This forced users to open rules one by one, leading to slow reviews and frequent configuration errors.
Solution: I consolidated all rules into a single transparent table. By surfacing key logic like limits and signer sequences I empowered users to audit and manage the entire configuration at a glance eliminating repetitive navigation.
Problem and solution
Problem: The signing setup was a «black box». Critical details were hidden inside nested pages, making it impossible to assess the overall security posture. This forced users to open rules one by one, leading to slow reviews and frequent configuration errors.
Solution: I consolidated all rules into a single transparent table. By surfacing key logic like limits and signer sequences I empowered users to audit and manage the entire configuration at a glance eliminating repetitive navigation.
Problem and solution
Problem: The previous signer list was ambiguous. It showed names but hid the actual approval logic, making it impossible to distinguish between parallel signing (anyone can sign) and sequential signing (strict order). This created compliance risks, as users couldn't verify if the approval flow was secure without opening every rule.
Solution: designed a structured signer row that visualizes the exact signing sequence and role dependencies. This makes the entire approval workflow transparent and guarantees that the security-critical order of signatures is visible at a glance, preventing setup errors.
Problem and solution
Problem: The previous signer list was ambiguous. It showed names but hid the actual approval logic, making it impossible to distinguish between parallel signing (anyone can sign) and sequential signing (strict order). This created compliance risks, as users couldn't verify if the approval flow was secure without opening every rule.
Solution: designed a structured signer row that visualizes the exact signing sequence and role dependencies. This makes the entire approval workflow transparent and guarantees that the security-critical order of signatures is visible at a glance, preventing setup errors.
Problem and solution
Problem: The previous signer list was ambiguous. It showed names but hid the actual approval logic, making it impossible to distinguish between parallel signing (anyone can sign) and sequential signing (strict order). This created compliance risks, as users couldn't verify if the approval flow was secure without opening every rule.
Solution: designed a structured signer row that visualizes the exact signing sequence and role dependencies. This makes the entire approval workflow transparent and guarantees that the security-critical order of signatures is visible at a glance, preventing setup errors.
Problem and solution
Problem: The previous signer list was ambiguous. It showed names but hid the actual approval logic, making it impossible to distinguish between parallel signing (anyone can sign) and sequential signing (strict order). This created compliance risks, as users couldn't verify if the approval flow was secure without opening every rule.
Solution: designed a structured signer row that visualizes the exact signing sequence and role dependencies. This makes the entire approval workflow transparent and guarantees that the security-critical order of signatures is visible at a glance, preventing setup errors.
Problem and solution
Problem: The previous signer list was ambiguous. It showed names but hid the actual approval logic, making it impossible to distinguish between parallel signing (anyone can sign) and sequential signing (strict order). This created compliance risks, as users couldn't verify if the approval flow was secure without opening every rule.
Solution: designed a structured signer row that visualizes the exact signing sequence and role dependencies. This makes the entire approval workflow transparent and guarantees that the security-critical order of signatures is visible at a glance, preventing setup errors.
Problem and solution
Problem: Users couldn't verify rule logic without opening details. With new limits and account scopes, the list lacked context, making review slow and prone to errors.
Solution: To make rule behavior clear at a glance, I surfaced the most important new parameters directly in the list. I extended the rule row to show limits and applied accounts, so users can immediately understand where and under what conditions a rule works, without drilling into its details.
Problem and solution
Problem: Users couldn't verify rule logic without opening details. With new limits and account scopes, the list lacked context, making review slow and prone to errors.
Solution: To make rule behavior clear at a glance, I surfaced the most important new parameters directly in the list. I extended the rule row to show limits and applied accounts, so users can immediately understand where and under what conditions a rule works, without drilling into its details.
Problem and solution
Problem: Users couldn't verify rule logic without opening details. With new limits and account scopes, the list lacked context, making review slow and prone to errors.
Solution: To make rule behavior clear at a glance, I surfaced the most important new parameters directly in the list. I extended the rule row to show limits and applied accounts, so users can immediately understand where and under what conditions a rule works, without drilling into its details.
Problem and solution
Problem: Users couldn't verify rule logic without opening details. With new limits and account scopes, the list lacked context, making review slow and prone to errors.
Solution: To make rule behavior clear at a glance, I surfaced the most important new parameters directly in the list. I extended the rule row to show limits and applied accounts, so users can immediately understand where and under what conditions a rule works, without drilling into its details.
Problem and solution
Problem: Users couldn't verify rule logic without opening details. With new limits and account scopes, the list lacked context, making review slow and prone to errors.
Solution: To make rule behavior clear at a glance, I surfaced the most important new parameters directly in the list. I extended the rule row to show limits and applied accounts, so users can immediately understand where and under what conditions a rule works, without drilling into its details.
Problem and solution
Problem: The interface was fragmented. Custom and Standard rules lived in separate, disconnected blocks. This forced users to switch contexts constantly and made the configuration difficult to scan.
Solution: I unified the experience into a single table system with collapsible sections. This architecture prioritizes Custom rules while keeping Standard templates accessible, creating a single source of truth without the visual noise.
Problem and solution
Problem: The interface was fragmented. Custom and Standard rules lived in separate, disconnected blocks. This forced users to switch contexts constantly and made the configuration difficult to scan.
Solution: I unified the experience into a single table system with collapsible sections. This architecture prioritizes Custom rules while keeping Standard templates accessible, creating a single source of truth without the visual noise.
Problem and solution
Problem: The interface was fragmented. Custom and Standard rules lived in separate, disconnected blocks. This forced users to switch contexts constantly and made the configuration difficult to scan.
Solution: I unified the experience into a single table system with collapsible sections. This architecture prioritizes Custom rules while keeping Standard templates accessible, creating a single source of truth without the visual noise.
Problem and solution
Problem: The interface was fragmented. Custom and Standard rules lived in separate, disconnected blocks. This forced users to switch contexts constantly and made the configuration difficult to scan.
Solution: I unified the experience into a single table system with collapsible sections. This architecture prioritizes Custom rules while keeping Standard templates accessible, creating a single source of truth without the visual noise.
Problem and solution
Problem: The interface was fragmented. Custom and Standard rules lived in separate, disconnected blocks. This forced users to switch contexts constantly and made the configuration difficult to scan.
Solution: I unified the experience into a single table system with collapsible sections. This architecture prioritizes Custom rules while keeping Standard templates accessible, creating a single source of truth without the visual noise.
Problem and solution
Problem: Users struggled to find the main actions. “Create rule” and “Edit” were pushed to the right side and visually blended into the page, so people missed them and had to scan the screen to start the key flow.
Solution: I moved the primary actions to the top, right under the page header, so the next step is obvious immediately. I grouped “Create rule” and “Edit” into a single, consistent action area aligned with the title, making the entry point faster and removing unnecessary visual search.
Problem and solution
Problem: Users struggled to find the main actions. “Create rule” and “Edit” were pushed to the right side and visually blended into the page, so people missed them and had to scan the screen to start the key flow.
Solution: I moved the primary actions to the top, right under the page header, so the next step is obvious immediately. I grouped “Create rule” and “Edit” into a single, consistent action area aligned with the title, making the entry point faster and removing unnecessary visual search.
Problem and solution
Problem: Users struggled to find the main actions. “Create rule” and “Edit” were pushed to the right side and visually blended into the page, so people missed them and had to scan the screen to start the key flow.
Solution: I moved the primary actions to the top, right under the page header, so the next step is obvious immediately. I grouped “Create rule” and “Edit” into a single, consistent action area aligned with the title, making the entry point faster and removing unnecessary visual search.
Problem and solution
Problem: Users struggled to find the main actions. “Create rule” and “Edit” were pushed to the right side and visually blended into the page, so people missed them and had to scan the screen to start the key flow.
Solution: I moved the primary actions to the top, right under the page header, so the next step is obvious immediately. I grouped “Create rule” and “Edit” into a single, consistent action area aligned with the title, making the entry point faster and removing unnecessary visual search.
Problem and solution
Problem: Users struggled to find the main actions. “Create rule” and “Edit” were pushed to the right side and visually blended into the page, so people missed them and had to scan the screen to start the key flow.
Solution: I moved the primary actions to the top, right under the page header, so the next step is obvious immediately. I grouped “Create rule” and “Edit” into a single, consistent action area aligned with the title, making the entry point faster and removing unnecessary visual search.
Results
The redesign transformed a fragmented legacy setup into a transparent self-service workflow, significantly improving both efficiency and accuracy.
Results
The redesign transformed a fragmented legacy setup into a transparent self-service workflow, significantly improving both efficiency and accuracy.
Results
The redesign transformed a fragmented legacy setup into a transparent self-service workflow, significantly improving both efficiency and accuracy.
Results
The redesign transformed a fragmented legacy setup into a transparent self-service workflow, significantly improving both efficiency and accuracy.
Results
The redesign transformed a fragmented legacy setup into a transparent self-service workflow, significantly improving both efficiency and accuracy.
time to task
Median time from homepage to starting rule creation
3x faster
Homepage interaction rate
80%
Accuracy
First-time success rate for creating valid rules
87%
time to task
Median time from homepage to starting rule creation
3x faster
Homepage interaction rate
80%
Accuracy
First-time success rate for creating valid rules
87%
time to task
Median time from homepage to starting rule creation
3x faster
Homepage interaction rate
80%
Accuracy
First-time success rate for creating valid rules
87%
time to task
Median time from homepage to starting rule creation
3x faster
Homepage interaction rate
80%
Accuracy
First-time success rate for creating valid rules
87%
time to task
Median time from homepage to starting rule creation
3x faster
Homepage interaction rate
80%
Accuracy
First-time success rate for creating valid rules
87%
creating rules
Smart Rule Builder
Configuring financial rules requires precision. The previous form was unstructured allowing users to create conflicting logic. I designed a guided step-by-step flow that isolates complex decisions regarding accounts, limits, and signers ensuring every rule is valid by design.
creating rules
Smart Rule Builder
Configuring financial rules requires precision. The previous form was unstructured allowing users to create conflicting logic. I designed a guided step-by-step flow that isolates complex decisions regarding accounts, limits, and signers ensuring every rule is valid by design.
creating rules
Smart Rule Builder
Configuring financial rules requires precision. The previous form was unstructured allowing users to create conflicting logic. I designed a guided step-by-step flow that isolates complex decisions regarding accounts, limits, and signers ensuring every rule is valid by design.
creating rules
Smart Rule Builder
Configuring financial rules requires precision. The previous form was unstructured allowing users to create conflicting logic. I designed a guided step-by-step flow that isolates complex decisions regarding accounts, limits, and signers ensuring every rule is valid by design.
creating rules
Smart Rule Builder
Configuring financial rules requires precision. The previous form was unstructured allowing users to create conflicting logic. I designed a guided step-by-step flow that isolates complex decisions regarding accounts, limits, and signers ensuring every rule is valid by design.
Before redesign
The legacy creation form was designed as a static checklist. It treated signing rules as simple permissions rather than flexible logic preventing users from configuring specific limits, account scopes, or strict signing orders.
Before redesign
The legacy creation form was designed as a static checklist. It treated signing rules as simple permissions rather than flexible logic preventing users from configuring specific limits, account scopes, or strict signing orders.
Before redesign
The legacy creation form was designed as a static checklist. It treated signing rules as simple permissions rather than flexible logic preventing users from configuring specific limits, account scopes, or strict signing orders.
Before redesign
The legacy creation form was designed as a static checklist. It treated signing rules as simple permissions rather than flexible logic preventing users from configuring specific limits, account scopes, or strict signing orders.
Before redesign
The legacy creation form was designed as a static checklist. It treated signing rules as simple permissions rather than flexible logic preventing users from configuring specific limits, account scopes, or strict signing orders.
Problems
The form did not support transaction limits or specific conditions forcing businesses to use the same approval chain for both small and critical payments.
The interface treated signers as a simple group without defining the order making it impossible to enforce strict sequential approvals for security.
Rules applied to the entire company context by default. Users could not restrict high-risk rules to specific bank accounts creating potential security gaps.
All settings were presented as a long uniform list of checkboxes which made it difficult to focus on building a secure scenario.
Problems
The form did not support transaction limits or specific conditions forcing businesses to use the same approval chain for both small and critical payments.
The interface treated signers as a simple group without defining the order making it impossible to enforce strict sequential approvals for security.
Rules applied to the entire company context by default. Users could not restrict high-risk rules to specific bank accounts creating potential security gaps.
All settings were presented as a long uniform list of checkboxes which made it difficult to focus on building a secure scenario.
Problems
The form did not support transaction limits or specific conditions forcing businesses to use the same approval chain for both small and critical payments.
The interface treated signers as a simple group without defining the order making it impossible to enforce strict sequential approvals for security.
Rules applied to the entire company context by default. Users could not restrict high-risk rules to specific bank accounts creating potential security gaps.
All settings were presented as a long uniform list of checkboxes which made it difficult to focus on building a secure scenario.
Problems
The form did not support transaction limits or specific conditions forcing businesses to use the same approval chain for both small and critical payments.
The interface treated signers as a simple group without defining the order making it impossible to enforce strict sequential approvals for security.
Rules applied to the entire company context by default. Users could not restrict high-risk rules to specific bank accounts creating potential security gaps.
All settings were presented as a long uniform list of checkboxes which made it difficult to focus on building a secure scenario.
Problems
The form did not support transaction limits or specific conditions forcing businesses to use the same approval chain for both small and critical payments.
The interface treated signers as a simple group without defining the order making it impossible to enforce strict sequential approvals for security.
Rules applied to the entire company context by default. Users could not restrict high-risk rules to specific bank accounts creating potential security gaps.
All settings were presented as a long uniform list of checkboxes which made it difficult to focus on building a secure scenario.
Problem and solution
Problem: Creating a rule felt like filling out a “wall of settings.” Everything was packed into one block, so users had to scan a long mixed list, constantly losing track of what each parameter means and whether it’s already set. This made configuration slower and increased the chance of missing a critical setting.
Solution: I completely rebuilt the page into a modular structure so rule setup feels controlled and predictable. Each parameter group became its own section (operation, signers, accounts, conditions) with a consistent layout, so users move step by step, instantly understand what they’re editing, and can review the rule without hunting through a single overloaded block.
Problem and solution
Problem: Creating a rule felt like filling out a “wall of settings.” Everything was packed into one block, so users had to scan a long mixed list, constantly losing track of what each parameter means and whether it’s already set. This made configuration slower and increased the chance of missing a critical setting.
Solution: I completely rebuilt the page into a modular structure so rule setup feels controlled and predictable. Each parameter group became its own section (operation, signers, accounts, conditions) with a consistent layout, so users move step by step, instantly understand what they’re editing, and can review the rule without hunting through a single overloaded block.
Problem and solution
Problem: Creating a rule felt like filling out a “wall of settings.” Everything was packed into one block, so users had to scan a long mixed list, constantly losing track of what each parameter means and whether it’s already set. This made configuration slower and increased the chance of missing a critical setting.
Solution: I completely rebuilt the page into a modular structure so rule setup feels controlled and predictable. Each parameter group became its own section (operation, signers, accounts, conditions) with a consistent layout, so users move step by step, instantly understand what they’re editing, and can review the rule without hunting through a single overloaded block.
Problem and solution
Problem: Creating a rule felt like filling out a “wall of settings.” Everything was packed into one block, so users had to scan a long mixed list, constantly losing track of what each parameter means and whether it’s already set. This made configuration slower and increased the chance of missing a critical setting.
Solution: I completely rebuilt the page into a modular structure so rule setup feels controlled and predictable. Each parameter group became its own section (operation, signers, accounts, conditions) with a consistent layout, so users move step by step, instantly understand what they’re editing, and can review the rule without hunting through a single overloaded block.
Problem and solution
Problem: Creating a rule felt like filling out a “wall of settings.” Everything was packed into one block, so users had to scan a long mixed list, constantly losing track of what each parameter means and whether it’s already set. This made configuration slower and increased the chance of missing a critical setting.
Solution: I completely rebuilt the page into a modular structure so rule setup feels controlled and predictable. Each parameter group became its own section (operation, signers, accounts, conditions) with a consistent layout, so users move step by step, instantly understand what they’re editing, and can review the rule without hunting through a single overloaded block.
Problem and solution
Problem: The previous checklist allowed mixing different operations in a single rule which prevented setting specific limits or unique signing logic for each transaction type
Solution:I changed the logic to one operation per rule to ensure granular control and allow users to configure precise security settings for each specific process.
Problem and solution
Problem: The previous checklist allowed mixing different operations in a single rule which prevented setting specific limits or unique signing logic for each transaction type
Solution:I changed the logic to one operation per rule to ensure granular control and allow users to configure precise security settings for each specific process.
Problem and solution
Problem: The previous checklist allowed mixing different operations in a single rule which prevented setting specific limits or unique signing logic for each transaction type
Solution:I changed the logic to one operation per rule to ensure granular control and allow users to configure precise security settings for each specific process.
Problem and solution
Problem: The previous checklist allowed mixing different operations in a single rule which prevented setting specific limits or unique signing logic for each transaction type
Solution:I changed the logic to one operation per rule to ensure granular control and allow users to configure precise security settings for each specific process.
Problem and solution
Problem: The previous checklist allowed mixing different operations in a single rule which prevented setting specific limits or unique signing logic for each transaction type
Solution:I changed the logic to one operation per rule to ensure granular control and allow users to configure precise security settings for each specific process.
Problem and solution
Problem: The signing logic was buried in a cluttered block with operations, making it nearly invisible. This lack of structure prevented businesses from building secure approval sequences, leading to high security risks and human error.
Solution: I moved the signing setup into a standalone, easy-to-read block to create a clear visual hierarchy. By adding a sequential mode with numbered steps, I transformed a chaotic list into a transparent and secure approval process.
Problem and solution
Problem: The signing logic was buried in a cluttered block with operations, making it nearly invisible. This lack of structure prevented businesses from building secure approval sequences, leading to high security risks and human error.
Solution: I moved the signing setup into a standalone, easy-to-read block to create a clear visual hierarchy. By adding a sequential mode with numbered steps, I transformed a chaotic list into a transparent and secure approval process.
Problem and solution
Problem: The signing logic was buried in a cluttered block with operations, making it nearly invisible. This lack of structure prevented businesses from building secure approval sequences, leading to high security risks and human error.
Solution: I moved the signing setup into a standalone, easy-to-read block to create a clear visual hierarchy. By adding a sequential mode with numbered steps, I transformed a chaotic list into a transparent and secure approval process.
Problem and solution
Problem: The signing logic was buried in a cluttered block with operations, making it nearly invisible. This lack of structure prevented businesses from building secure approval sequences, leading to high security risks and human error.
Solution: I moved the signing setup into a standalone, easy-to-read block to create a clear visual hierarchy. By adding a sequential mode with numbered steps, I transformed a chaotic list into a transparent and secure approval process.
Problem and solution
Problem: The signing logic was buried in a cluttered block with operations, making it nearly invisible. This lack of structure prevented businesses from building secure approval sequences, leading to high security risks and human error.
Solution: I moved the signing setup into a standalone, easy-to-read block to create a clear visual hierarchy. By adding a sequential mode with numbered steps, I transformed a chaotic list into a transparent and secure approval process.
Problem and solution
Problem: Previously, signing rules were applied globally, leaving high-value accounts vulnerable and unprotected by specific security protocols. This «all-or-nothing» approach created massive compliance risks and made it impossible to manage complex corporate finances safely.
Solution: I introduced a dedicated account binding block that allows for granular security policies on a per-account basis. This enables businesses to enforce strict multi-level approvals for high-risk accounts while keeping standard operations fast and flexible.
Problem and solution
Problem: Previously, signing rules were applied globally, leaving high-value accounts vulnerable and unprotected by specific security protocols. This «all-or-nothing» approach created massive compliance risks and made it impossible to manage complex corporate finances safely.
Solution: I introduced a dedicated account binding block that allows for granular security policies on a per-account basis. This enables businesses to enforce strict multi-level approvals for high-risk accounts while keeping standard operations fast and flexible.
Problem and solution
Problem: Previously, signing rules were applied globally, leaving high-value accounts vulnerable and unprotected by specific security protocols. This «all-or-nothing» approach created massive compliance risks and made it impossible to manage complex corporate finances safely.
Solution: I introduced a dedicated account binding block that allows for granular security policies on a per-account basis. This enables businesses to enforce strict multi-level approvals for high-risk accounts while keeping standard operations fast and flexible.
Problem and solution
Problem: Previously, signing rules were applied globally, leaving high-value accounts vulnerable and unprotected by specific security protocols. This «all-or-nothing» approach created massive compliance risks and made it impossible to manage complex corporate finances safely.
Solution: I introduced a dedicated account binding block that allows for granular security policies on a per-account basis. This enables businesses to enforce strict multi-level approvals for high-risk accounts while keeping standard operations fast and flexible.
Problem and solution
Problem: Previously, signing rules were applied globally, leaving high-value accounts vulnerable and unprotected by specific security protocols. This «all-or-nothing» approach created massive compliance risks and made it impossible to manage complex corporate finances safely.
Solution: I introduced a dedicated account binding block that allows for granular security policies on a per-account basis. This enables businesses to enforce strict multi-level approvals for high-risk accounts while keeping standard operations fast and flexible.
Problem and solution
Problem: The product was missing a critical feature: amount-based rules. Businesses had no way to set specific conditions for different transaction sizes, leaving them stuck with a rigid process that completely ignored their real financial workflows.
Solution: To make rules more flexible, i designed a flexible engine that allows users to create and manage custom payment limits from scratch. This closed a massive functional gap and gave companies the power to build their own complex signing logic for the first time.
Problem and solution
Problem: The product was missing a critical feature: amount-based rules. Businesses had no way to set specific conditions for different transaction sizes, leaving them stuck with a rigid process that completely ignored their real financial workflows.
Solution: To make rules more flexible, i designed a flexible engine that allows users to create and manage custom payment limits from scratch. This closed a massive functional gap and gave companies the power to build their own complex signing logic for the first time.
Problem and solution
Problem: The product was missing a critical feature: amount-based rules. Businesses had no way to set specific conditions for different transaction sizes, leaving them stuck with a rigid process that completely ignored their real financial workflows.
Solution: To make rules more flexible, i designed a flexible engine that allows users to create and manage custom payment limits from scratch. This closed a massive functional gap and gave companies the power to build their own complex signing logic for the first time.
Problem and solution
Problem: The product was missing a critical feature: amount-based rules. Businesses had no way to set specific conditions for different transaction sizes, leaving them stuck with a rigid process that completely ignored their real financial workflows.
Solution: To make rules more flexible, i designed a flexible engine that allows users to create and manage custom payment limits from scratch. This closed a massive functional gap and gave companies the power to build their own complex signing logic for the first time.
Problem and solution
Problem: The product was missing a critical feature: amount-based rules. Businesses had no way to set specific conditions for different transaction sizes, leaving them stuck with a rigid process that completely ignored their real financial workflows.
Solution: To make rules more flexible, i designed a flexible engine that allows users to create and manage custom payment limits from scratch. This closed a massive functional gap and gave companies the power to build their own complex signing logic for the first time.
Results after 6 months
This redesign turned a rigid checklist into a guided rule builder built for real banking scenarios. By separating complex decisions into clear blocks (operation, signers, accounts, conditions), the setup became easier to complete, more predictable, and “valid by design” even with more flexibility and parameters.
Results after 6 months
This redesign turned a rigid checklist into a guided rule builder built for real banking scenarios. By separating complex decisions into clear blocks (operation, signers, accounts, conditions), the setup became easier to complete, more predictable, and “valid by design” even with more flexibility and parameters.
Results after 6 months
This redesign turned a rigid checklist into a guided rule builder built for real banking scenarios. By separating complex decisions into clear blocks (operation, signers, accounts, conditions), the setup became easier to complete, more predictable, and “valid by design” even with more flexibility and parameters.
Results after 6 months
This redesign turned a rigid checklist into a guided rule builder built for real banking scenarios. By separating complex decisions into clear blocks (operation, signers, accounts, conditions), the setup became easier to complete, more predictable, and “valid by design” even with more flexibility and parameters.
Results after 6 months
This redesign turned a rigid checklist into a guided rule builder built for real banking scenarios. By separating complex decisions into clear blocks (operation, signers, accounts, conditions), the setup became easier to complete, more predictable, and “valid by design” even with more flexibility and parameters.
Builder completion
Rule creation conversion (builder start → rule saved)
68%
Share of users who successfully save a rule on their first attempt
74%
Quality and satisfaction
Rules saved without validation errors
87%
VOC (from 3.6 to 4,43 out of 5)
4,43
Builder completion
Rule creation conversion (builder start → rule saved)
68%
Share of users who successfully save a rule on their first attempt
74%
Quality and satisfaction
Rules saved without validation errors
87%
VOC (from 3.6 to 4,43 out of 5)
4,43
Builder completion
Rule creation conversion (builder start → rule saved)
68%
Share of users who successfully save a rule on their first attempt
74%
Quality and satisfaction
Rules saved without validation errors
87%
VOC (from 3.6 to 4,43 out of 5)
4,43
Builder completion
Rule creation conversion (builder start → rule saved)
68%
Share of users who successfully save a rule on their first attempt
74%
Quality and satisfaction
Rules saved without validation errors
87%
VOC (from 3.6 to 4,43 out of 5)
4,43
Builder completion
Rule creation conversion (builder start → rule saved)
68%
Share of users who successfully save a rule on their first attempt
74%
Quality and satisfaction
Rules saved without validation errors
87%
VOC (from 3.6 to 4,43 out of 5)
4,43
scroll on top
scroll on top
scroll on top
scroll on top
scroll on top