
AUTOMATIONS CHANGE HISTORY LOG
Automations have quickly become an increasingly complex system of tools for the administrator persona on the Degreed platform. As the system and functionality of automations grows more complex, it became crucial to introduce a change history log early in the development process to ensure users could easily find and track updates, additions, and changes made to their automations over time to support troubleshooting and identifying potential problem areas across all of their automations.
Company: Degreed
Role: Product Designer
Contributions: Analysis of needs, ideation, designs, iterations, and implementation
Tools Used: Confluence, Jira, Figma
Research & Analysis
Initial research for this project consisted of reviewing user feedback and detailed product requirements. I worked closely with the product manager and engineering manager on this project to ensure a full understanding of the intricacies of the automation platform and current limitations and problem areas for users where a change history log could help solve.
​
The requirements for this project had a lot of complexities since there are multiple different aspects of an automation that can be changed, added, or removed (name, description, trigger, condition, and action), and each change may or may not have additional metadata along with the change (i.e. Trigger changed from "User completes pathway Y" to "User completes pathway X"). Before diving into the designs, I laid out each possible change scenario in a spreadsheet to ensure all were accounted for visually and change log rows could be aligned despite all having varying levels of complexity to display.
Ideation & Design
Design explorations were highly collaborative across product, design, and engineering partners. I helped the team identify key problem areas, brainstorm solutions, and strategize a path forward for an MVP and beyond in a short turn-around time. Designs went through many iterations based on peer review feedback, design critique, and technical needs.
​
Design iterations went through various phases starting with designing the table element, how change data should display in each change row within the table, and overall page placement. I ultimately landed on displaying some static elements on the top of the page and making the table full page width for more breathing room.

Table and page layout design explorations
I detailed each possible change scenario with data placeholders and examples to help frontend and database developers understand the possibilities of visualizing change data from our automations backend database. This exercise also helped me visualize the best way to display the complexities of change history data across multiple variables for each change type (update, add, or remove triggers, conditions, actions, name, and description).

Change row formatting and examples for each change type
Iteration & Outcome
Throughout the development process, I worked closely with the development team to align on designs, accessibility needs, and development limitations to deploy the best final product possible. Final designs ended up pushing the envelope for what had previously been possible with our current frontend architecture which proved a unique but rewarding challenge to push forward with in new and creative ways. The final iteration of the of this project was deployed to production in July 2024.
​
Further user testing will take place during the end of 2024 to ensure usability and test new ideas to solve even more user problems with future iterations to come.
