“Business Rules”

Summary

For this project I was primarily responsible for design, but also engaged in research.

• Gained familiarity with business rules engines
• Conducted comparative analyses to understand system architectures and common interactions
• Conceptualized a new way to interact with business rules by thinking about the users’ needs and drawing on outside experience
• Sketched wireframes and researched APIs to communicate with and support the development team

Project Background

The client operated in a tightly-regulated space, and had to comply with many frequently-changing rules around interactions with its customers. To support this, our team proposed a business rules engine (BRE) that would automatically communicate to its employees based on the status of customers.

My role was to architect the system and to design the interface by which users could create new rules, test rules before they go live, and manage existing rules.

Research

To begin collecting ideas for system architectures and interfaces, my team and I conducted a comparative analysis of several notable BREs. From this and through conversations with stakeholders, it was determined that the core components of the system needed to be a rules Manager, Editor, and Sandbox. This was also a chance to begin forming a taxonomy used throughout the project.

Sketching system diagrams and sharing the sketches with stakeholders was an efficient way to clarify, communicate, and validate my understanding.

All of the BRE interfaces in the comparative analysis either placed very technical demands on the user such as requiring them to write code (ethnographic data we gathered about our users revealed they were not tech-savvy) or else featured dull, inflexible interactions composed of complex file trees and Mad Lib-style fill-in-the-blank worksheets.

Around that time I had been introduced to graphical programming languages such as Scratch.

Scratch: a graphical programming language.

Graphical programming languages are commonly used to teach children how to code, but they are also capable of forming very complex commands. This knowledge provided a key insight: a graphical programming language could allow non-tech savvy users to write sophisticated business rules and even have fun doing it.

Wireframing

Sketching and further iterating on wireframes led to another key insight: the power of this system would come from the ability to reference similar rules or pieces of rules in the existing database–while the new ones are being written.

A graphical programming language for business rules meant that users might be able to identify the rules they were working on by thumbnails, adding to the intuitiveness of the rules Browser.

By dynamically showing the graphical and text-based programming side by side, the rules Editor was designed to gradually turn novices into power users.

Highlighting a section of graphical code was designed to present the user with a powerful ability to find and reference it in the live database, and test it in a Sandbox.

Results

The wireframes communicated the design to the development team. I also researched and shared with them the APIs for several graphical programming languages, one of which was used to build the system.