Dinamico systems is a compensation forecasting software that was originally designed for education districts, but the principles and mathematics can be applied to other industries as well.
Dinamico's original problem was with its dashboard. They had received feedback from customers that it was confusing, but couldn't define what exactly was confusing about it.
Using Object-Oriented UX (OOUX), I was able to simplify their dashboard and information by embracing its complexity rather than hiding it from the user.
Lead UX Designer and Information Architect
Internal Developer and Database Engineer, Business partners
Primary Tools & Resources:
Object-Oriented UX (OOUX), Notion, Figma, FigJam
Because the DinamiComp™ software had already been developed and customers were using it, it was important to start with understanding the architecture of the system.
The purpose of Object-Oriented UX (OOUX) is to be able to identify the objects making up a user's mental model in order to then apply it to a product's system and information architecture.
Because this software is already developed and in-use, I used OOUX to identify the objects making up the current system in order to find gaps in how that information was being displayed to the user through the dashboard and UI.
The "objects" in this case were the real-world things that user's were coming to the DinamiComp™ software for.
The existing objects could be found both in the dashboard and UI of the product as well as in the back-end database. Being able to break down the existing application this way, allowed me to bridge communication between myself, the team's developer, and the business owner because I was translating what already existed into OOUX terminology. This made it much easier when I started to introduce changes and improvements later in the project.
I created the existing object map using Notion, which allowed me to explore the structure of the existing objects, the relationships between them, and the actions that users can do to those objects based on their permissions and the current software capabilities.
The blue Notion card below represents all of the attributes of an employee currently in the system.
The main challenge with the existing object map was how much functionality was hidden from the user.
As an example, the screens below show the relationship between PDVs, employees, and roles. In this case, a PDV is its own object with its own structure.
The contents of that structure is defined at the Role object. So a teacher may have one set of PDVs that influence their compensation (like "Over 5 years of service", or "Master's Degree") while an administrator would have another set of PDVs (like "Over 10 hours of Professional development").
Then each employee would have the status of their PDV updated at the individual employee level: Jim Halpert might be able to check off "Over 5 years of service", but Michael Scott cannot.
The relationship between these objects isn't apparent in the original dashboard as there isn't an easy way to see what role a given employee has when looking at an individual employee even though the list of available PDVs is derived from that relationship.
Because the relationships between objects weren't clearly defined or leveraged in the dashboard UI, this required users to move from one section to another with incredible inefficiency.
This inefficiency was most apparent when users needed to access reports, which could only be pulled for individual employees or roles but showed different information on each.
The in-depth audit of the existing platform and multiple conversations with the team's developer and business partners allowed us to clearly define where the opportunities for improvement were. It also raised some interesting questions about reporting and making changes over time, which resulted in an additional project.
The primary objects and screens we'll be focusing on are the Employee List view, Employee detail page, Roles List view, and Role detail page. Our goal is to show the user the relationship between these 2 objects so that they can navigate the system more easily.
Once we prioritized the most important elements that made up the "Employee" object, it was clear which fields needed to be exposed wherever an Employee was found in the system.
The remaining fields would either not be displayed to the user (Employee ID or User login information) or would be found in the detail page where the user could make changes to those elements more readily (Related PDVs).
The biggest improvement on the Employee object was including the Role and Team, while also hyperlinking that text to more easily drill down to a specific Role or Team.
At the Role level, we wanted to make it easier for a user to see and update Employees that were within a given Role. This same method would then be applied to the Team detail page.