Automated Rulesets
Overview
Role
Lead UX Designer
Teams
UX
Compliance Solutions
Platform & Architecture
Includes
UX Research
Usability Testing
Application Design
Project
Users of the platform were spending a long time on repetitive organisational tasks. This stuck out to us as a problem, since some users can have thousands of documents, and a system to be able to manage them efficiently didn’t exist. This lead to an overall reduction in user efficiency, and also the cause for some user frustrations.
Our users wanted a way to create custom conditionals rules, that are robust enough to help them save time doing multiple repetitive tasks.
Discovery
I kicked off this project with several internal meetings to get a deeper understanding of what we were aiming to achieve. It became clear that this feature was something our customers had been requesting for quite some time. While I grasped the overall goal, I wanted to dive deeper into understanding the specific repetitive tasks involved and how much time they were actually consuming.
After doing some additional research, it became apparent that the three primary objectives for this phase of the project were:
- Users want the ability to automatically decline trades
- Users want to automatically archive trades
- Users want to assign trades to specific team members
From there, I began documenting the insights gathered from my conversations and started organizing my thoughts into a clear plan of action.
My first step was to create a comprehensive list of all the rules we intended to implement. While I had already noted the actions users would need to take, I realized there were also various conditions they’d need to set. The key conditions I identified included:
- The sender of the trade
- The date the trade was received
- Trades older than a specific time period
- The current status of the trade
Where things could get complex was the idea of combining multiple conditions at once. After discussions with the development team and the Product Owner, we agreed that it would be best to set aside this functionality for now.
There was one more essential element: the document type attached to each trade. With multiple document types available, users would have greater control over their workflows. So, the final formula for this feature ended up being:
The idea for conditional logic for this feature
Discovery
The final layer of this cake, is that not every condition & action is available for each document type. Therefore, I ended up creating an excel document to create each individual action.
The Process
Ideation
There are many ways that this project could manifest itself on the platform. Due to its complex nature, i wanted to keep the design as integrated to the current design language, and to work in its most simple format. I started of with some simple information architecture and lo fidelity wireframes of my ideas.
There was also a lot of features and functionality that needed to be thought about, and scoped/descoped.
Creating a spreadsheet to communicate rules, and how they can interact with each other.
Some early lofi sketches illustrating different approaches to rule building.
Exploring some Mid-Fi visual representations of how to build rules. The left side was a rule builder using prebuilt sections that could be dragged and dropped in place – right was a draw which allowed the user to customise the rule using drop downs.
The Solution
So Far
The draw method of creating a rule was preferred when speaking to customers and internal teams. It fit the ShipServ brand a lot more, and was simplier to grasp for the user. I continued to create a flow for rule creation.
Creating a spreadsheet to communicate rules, and how they can interact with each other.
Some early lofi sketches illustrating different approaches to rule building.
An assorted collection of colours, typography and components from Lighthouse.
Project Stopped
So Far
Project End
Unfortunately, due to a change in leadership, this project was benched to prioritise other projects. i still wanted to include this project in my portfolio, even though it never made it to prod becuase of the complexity of rule creation, and how i had to think logically about achieving the outcome for the user.
Learnings
Even though this project never made it through to production, i still learnt a lot. This project was always a big undertaking. It could be viewed as very complex idea, with lots of features and functionality within. I was able to break the project down into various ideas, and validate and prioritise them.
I was happy in the direction the project was heading, and if we were able to get some validation on the idea, it could have been a very useful tool for our users.