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
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.
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.
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.
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.
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.
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.