UX/UI Design Process / Workflow
Research
Working closely with the Product Owner to understand how Rules Management works as part of the Enterprise Software, Users identified that the old application:
• Was not intuitive or user-friendly.
• Lacked features for creating global rules.
• Had a cumbersome UI.
• Needed implementation improvements—there were too many limitations, and more flexibility was required.
Global Business Rule
Event Triggered => Rule is Applied (transaction based on context) => Run Qualifiers => Validate Base on Conditions/Expressions => Apply Rule.
Example of Rule Assignment Subtype Mapping:
WorkFlowEventCode => WorkFlowRuleEntityTypeCode => WorkFlowContextCode
[Bond_Added] [Assignment_Rules] [Bond]
Brainstorming & Prototyping
I worked closely with Software Engineers and Developers to brainstorm ideas, solutions, technologies, and best practices to address the identified issues. We looked at Kendo’s Query Builder and jQuery QueryBuilder. Based on the team’s analysis, neither met the requirements. Due to the complexity of the application and its requirements, we decided to use jQuery Builder to develop a custom logic backend and UI.
Development
Once the Product Owner and key stakeholders approved the proposed solution and prototype, I handed off the finished prototype to the Development Team. I worked with them to address any UX/UI design and development concerns. Using Azure to track sprints based on individual tasks, the Project Manager ensured the team stayed on track to meet all deadlines. During the process, we made modifications and enhancements to solve unforeseen challenges to the logic and UX/UI prototype.
Initial mock showing placement of elements and properties.
End Result
During the development stages, the QA team was involved to ensure that the logic and prototype met the requirements and that the application worked as intended.
1. Ensured proper labeling of sections. Implemented UX patterns as part of enterprise global standards i.e. accordions and cards.
2. Showed logic/validation when the User initiates the “Run/Test” button. This simplifies the UI so that the User can focus on setting Rule Qualifications and Expressions.
3. Implemented Qualifers confirming criteria are properly identified. Tree logic are nested and labelled “WHEN/IF/THEN” with buttons grouped in their respective areas resulting in an intuitive UI.
4. “IF/THEN” conditions were then sub-grouped to show the User the end results when the rule passed all criteria and conditions.
A Rule can potentially have tens or hundreds of Conditions. In such a scenario, the “Save, Approve, Run Test, Validate” buttons, initially located at the top and bottom of the Qualifier area, would be difficult to access. Users would have to scroll all the way to the top or bottom to gain access. To solve this problem, a floating toolbar was implemented. The User now has access to all buttons, validation and testing, and logic expressions.
Final Prototype – default view showing floating expandable menu with Qualification & Expression Viewer.
Final Prototype – grid view showing rule test simulator.
Users can toggle between Tree View and Grid View. The Grid View is a compressed view of all Conditions and Criteria including the logic “IF/THEN/OR”. This is a user-friendly view if there are tens or hundreds of Conditions and Criteria in a rule.
