Dinamico Systems: Dashboard Redesign with Object-Oriented UX (OOUX)

Dinamico Systems: Dashboard Redesign with Object-Oriented UX (OOUX)

Project Overview

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.

Project Details

My Role:
Lead UX Designer and Information Architect

The Team:
Internal Developer and Database Engineer, Business partners

The Timeline:
1 month

Primary Tools & Resources:
Object-Oriented UX (OOUX), Notion, Figma, FigJam

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.

Opportunities for Improvement

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.

Immediate Opportunities

  • Expose the relationship between "Role" and "Employee" in both sections of the application for easier navigation and editing.
  • In our research, we found that the managers making these updates have a specific team under them that they would be updating PDVs for. These teams could have a mix of roles within them and is ultimately a grouping of the "Employee" object to make updates more efficient. Therefore, the addition of a "Team" object was prioritized for this project.
  • I also explored ways of displaying information in real-time in context to where a user was within the system, rather than having reporting only existing under the "Roles" section of the application.

Future Opportunities

  • Incorporating time in the way PDVs are tracked and used would allow for more accurate reporting as well as account for role and PDV changes over time.

Exposing the Object Relationships

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.

Employee Object - Improved List and Detail Page View

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.

Role Detail Page - Showing the Employees

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.

Improved User Flow

Next Steps & Lessons Learned

Next Steps

  • Hand-off designs with annotations to the team's developer so that they can incorporate the changes in the database AND front-end
  • Continue exploring the reporting and dashboard functionality when incorporating "time"
  • We already know that they'll be complexity with locking PDV values for a given time period so that the model doesn't change too much

Lessons Learned

  • OOUX is a great way to bridge communication with cross-functional partners when applying it to an existing system. This allowed the whole team to communicate more seamlessly around prioritization and new functionality, while feeling confident about knowing how big of an impact a change would make
  • While Figma is a great tool for collaboration with other designers, it was challenging when partnering with the team's developer as they hadn't used Figma before. Allowing extra time for training and ensuring the developer had a good grasp of the hand-off was important for ultimately getting the functionality built.

More UX Work