Workflow & systems UX/2026
Speedchain’s transaction coding system relied on rigid, CSV-based logic that required manual updates for every client configuration.
As the business scaled, this approach became increasingly fragile, introducing inconsistencies in data handling, slowing down operations, and creating heavy reliance on error-prone spreadsheets.
The challenge was to transform this static system into a flexible, rule-based framework that could scale with operational complexity, reduce manual effort, and standardize how coding logic is defined and maintained.
TIMELINE
2 Months
THE TEAM
Tejaswini (me) - Designer
MY ROLE
Led the design of Flex AI, taking over early-stage concepts and evolving them into a cohesive, production-ready system. Built upon initial low-fidelity workflows, refining and restructuring key experiences while translating them into high-fidelity designs.
Defined core interaction patterns and end-to-end flows for rule creation, configuration, and application, enabling a more flexible and scalable approach to transaction coding.
Partnered closely with stakeholders to navigate legacy constraints, align on product direction, and ensure the system could support real-world workflows and future growth.
Enable Scalability Through ConfigurationReplace rigid CSV-based workflows with a flexible rules engine that supports growing operational complexity and future integrations. Reduce Manual Effort and ErrorsEliminate dependency on manual spreadsheet updates by introducing structured, system-driven logic, improving consistency and reliability.Establish Structured Rule ManagementCreate a clear and reusable framework for defining, managing, and organizing rules, making complex logic easier to build, understand, and maintain.
After taking ownership of the project, I focused on transforming an early, low-fidelity concept into a scalable and cohesive system. Rather than directly translating CSV workflows into UI, I stepped back to understand the underlying logic and redefine how transaction coding should function at a system level.
Reframing the Problem
Analyzed how users managed project and transaction coding through CSVs to uncover patterns, edge cases, and failure points. This revealed that the core issue wasn’t just usability, but a lack of structure, scalability, and control in how logic was defined.From Static Files to Dynamic Rules
Shifted the model from file-based configuration to a rule-driven system, enabling users to define logic through flexible, reusable conditions instead of manual spreadsheet updates.Designing a Scalable Logic Model
Established a clear framework for how rules are created, combined, and evaluated, introducing structured AND/OR logic, hierarchy, and validation to support increasingly complex workflows.Systematizing Configuration
Replaced manual CSV editing with structured inputs and UI-driven configuration, allowing users to manage data and logic directly within the product while reducing dependency on error-prone processes.Building for Extensibility
Aligned the system with a service-based architecture, ensuring the rules engine could scale beyond the initial use case and support future integrations with external systems like ERPs.
Centralized CSV vs Structured Rule System
Decision: Shifted from a single monolithic CSV file to a modular, rule-driven system with attribute-level configuration.
Considered: Maintaining a single CSV file with incremental updates.
Rationale: The existing system relied on one large CSV containing all codes and relationships. Any update required re-uploading the entire file, increasing the risk of errors and making even small changes operationally expensive. By breaking this into attribute-level configurations, each dataset is managed independently through structured inputs. This improves maintainability, reduces dependency on full-file updates, and creates a more scalable foundation for future expansion.
Flexibility vs System Control
Decision: Introduced controlled flexibility using toggles and active state management.
Considered: A fully open, free-form configuration system.
Rationale: While flexibility was important, unrestricted rule creation introduced risks of conflicting logic and inconsistent outputs. The final approach allows multiple configurations to exist, but enforces a single active state per attribute—balancing adaptability with system integrity and reducing user-driven errors.
Reusability vs Redundancy
Decision: Enabled rule duplication and reuse across workflows.
Considered: Rebuilding rules from scratch for each new use case.
Rationale: Users frequently needed variations of similar logic across different scenarios. Allowing duplication reduced repetitive setup work and ensured consistency, while still allowing modifications where needed. This improved efficiency without sacrificing flexibility.
Simplicity vs Configuration Depth
Decision: Designed a guided, step-by-step rule builder.
Considered: A single-screen interface exposing all rule parameters at once.
Rationale: Rule creation involves multiple layers of logic that can become overwhelming if presented all at once. A progressive, step-by-step flow reduces cognitive load, helping users build complex rules more confidently while maintaining clarity throughout the process.
solution
To address the limitations of the existing CSV-based system, I designed a rule-driven configuration model that allows users to define transaction logic through structured inputs instead of static files.
The solution introduces a flexible rule builder that supports conditional logic (IF/AND/THEN), reusable components, and controlled data mapping. This shift transforms coding from a manual, file-dependent process into a scalable system that can adapt to increasing operational complexity while maintaining consistency and control.
Flex AI transforms manual CSV-based workflows into a structured, rule-driven system for defining and applying project and transaction logic.
At a high level, the system works in three layers:
Data configuration: Admins define and map structured inputs (previously managed through CSVs)
Rule creation: Logic is built using conditional IF → THEN rules
Rule application: The system validates and applies these rules across transactions
This approach replaces manual file handling with a scalable system where logic is visible, reusable, and easy to manage.
1. Data configuration and mapping
overview
The existing workflow relied on large, manually maintained CSV files containing thousands of rows of interconnected codes and relationships. Any update required rebuilding and re-uploading the entire file, making the process difficult to maintain, error-prone, and hard to scale.
To simplify this process, I redesigned the system into a modular configuration model where administrators could upload, map, and manage individual data fields independently through the UI instead of relying on flat-file maintenance.
key improvements
Replaced a single monolithic CSV workflow with structured, field-level configuration
Enabled independent uploads for specific data attributes instead of full-file replacements
Introduced dynamic column creation and mapping directly within the interface
Allowed admins to customize field names to align with ERP terminology and internal workflows
Reduced operational dependency on manually editing and re-uploading large spreadsheets
1.1 .csv upload
This flow allows administrators to upload independent code lists for specific fields instead of maintaining one large CSV containing all relationships and configurations.
1.2 Adding a new field
Users can dynamically create and map new fields directly within the platform, allowing the system to adapt to different client and operational requirements.
1.3 Replace files
Users can replace individual datasets while preserving the rest of the system configuration, reducing manual effort and update complexity.
2. Rule builder (IF -> THEN logic)
overview
One of the biggest challenges in the existing system was translating complex accounting and coding relationships into a process that administrators could actually configure without relying on engineering or manual spreadsheet logic. I designed a structured rule-building experience that allowed users to define conditional logic through a guided, step-by-step workflow using IF → THEN relationships.
key improvements
Transformed static spreadsheet logic into a dynamic rule-based workflow Designed a guided builder for creating multi-condition logic using IF / AND relationships Enabled reusable conditional structures through configurable rule definitions Reduced cognitive overload by breaking complex logic into manageable steps Introduced visual chips, grouped conditions, and editable states for better readability and control Designed the system to support scalability across multiple workflows and future ERP integrations
2.1 rule builder wizard
This flow guides users through creating conditional IF → THEN logic using a structured, step-by-step rule-building experience.
3. Rule Management & Iteration
overview
Creating rules was only one part of the workflow. Administrators also needed a scalable way to manage, update, duplicate, and maintain rule logic over time without rebuilding configurations from scratch. I designed a centralized management layer that made rules easier to search, maintain, and iterate on as operational needs evolved.
key improvements
Designed a centralized rules table for visibility and management Enabled quick access to edit, duplicate, and delete rule actions Introduced rule duplication to reduce repetitive configuration work Improved scalability by allowing existing logic to be reused and adapted Added searchable management states to support growing rule libraries over time Structured the interface to make complex rule systems easier to navigate and maintain
3.1 Rule list
This screen displays all created rules in a centralized table where users can search, organize, and manage rule configurations.
3.2 Edit rule
Users can modify existing rules and update logic without needing to recreate workflows from scratch.
3.3 duplicate rule
This flow allows users to duplicate existing rules and quickly adapt them for similar operational scenarios.
3.4 Delete rule
Users can safely remove outdated rules through confirmation states designed to prevent accidental deletion.
4. Conflict Resolution & Rule Hierarchy
overview
As the system became more flexible, multiple rules could overlap or produce conflicting outcomes across the same transaction scenarios. Without a clear hierarchy model, rule execution could become unpredictable and difficult to manage at scale. To address this, I designed a hierarchy management system that allowed administrators to organize, prioritize, and control how rules are applied across the platform.
key improvements
Introduced rule hierarchy management to resolve conflicting logic Enabled administrators to reorder rules based on execution priority Designed clear visual indicators for rule relationships and precedence Reduced ambiguity by making rule behavior more transparent and predictable Structured the experience to support scalability as rule libraries grow over time Balanced flexibility with system control to maintain data consistency
4.1 Rule conflict
This screen identifies overlapping rule conditions that may create conflicting outcomes within the system.
4.2 Rule hierarchy
Users can rearrange and prioritize rules to control execution order and resolve conflicts between overlapping conditions.
4.3 Archive
Older or inactive configurations can be archived to keep rule libraries organized without affecting active workflows.
Operational Efficiency
The new configuration model significantly reduced dependency on manually maintaining large CSV files for every client update. By shifting configuration into structured UI-driven workflows, administrators could manage fields, mappings, and rules more efficiently without rebuilding entire datasets.
Reduced manual effort involved in maintaining large spreadsheet-based workflows
Simplified rule and data management through structured configuration flows
Improved maintainability by separating data fields into modular inputs instead of one monolithic file
Reduced operational friction during updates and configuration changes
Scalability
The system was designed to support growing operational complexity beyond the initial Flex AI use case. By transforming static spreadsheet logic into reusable rule-based architecture, the platform became more adaptable to future integrations and evolving business requirements.
Established a scalable foundation for future ERP and API-driven integrations
Enabled reusable rule logic across multiple workflows and configurations
Supported growing rule libraries through centralized management and hierarchy handling
Reduced reliance on engineering support for operational rule updates
Visibility & Control
A major improvement was giving administrators clearer visibility into how rules were structured, managed, and applied across the system. This improved transparency made the platform easier to govern, troubleshoot, and trust.
Improved visibility into rule behavior, hierarchy, and execution logic
Enabled easier editing, duplication, and maintenance of existing rules
Introduced clearer ownership and governance over configuration workflows
Made complex system logic more understandable and manageable for non-technical users
/Systems Thinking
Designing Flex AI strengthened my ability to think beyond individual screens and structure products as scalable systems with interconnected workflows, logic, and governance.
/Balancing Flexibility
One of the biggest learnings was balancing configurability with usability—creating a system powerful enough for complex operational needs while keeping interactions clear and manageable.
/Designing for Scale
This project reinforced the importance of designing for long-term scalability, maintainability, and future integrations rather than solving only for immediate workflows.