Understanding the System
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.
Background of Object-Oriented UX
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.
The Existing Object Map
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.
- Yellow cards (content) - Each employee had a name
- Red cards (metadata) - Employees had a Salary which could then be used for sorting or filtering information
- Green cards (calls to action) - In this case, there isn't anything a user would directly "do" to an employee besides Edit, Add, and Delete
- Blue cards (relationships between objects) - An employee has a related PDV status on specific PDVS assigned via their Role, as well as a Related Role and User 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.
The Limitations
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.
