Mars Inc.
Problem
The total business is evaluated based on business function, brand, or retailers. This report needs to give a consistent level of metrics viewed across executive summary scorecards that are evolving over time.
Outcome
Created a dashboard and spec document for developer handoff. The application was built and is currently used by Mars executives.
What I did
Deliveries
The enterprise includes Amazon, Chewy, Mars Wrigley, and the top four Omni retailers (Target/ PetSmart/Kroger/Petco). Four pillars span across the entire enterprise: Develop, Supply, Market, and Sell. These pillars will include a perspective on portfolio innovation, supply chain, content service, media, traffic, eventing, and retailer strategic partnerships.
This scorecard will be reviewed at least once a period by senior stakeholders but could also be refreshed daily/weekly based on the availability of data.
Why are we doing this?
1.
Data collection
Data is spread across multiple systems and can be inconsistent between them. This serves as a barrier to the primary role of executive members: providing direction to the support teams.
2.
Clear analysis
Team members need to be able to interpret what is causing X change, why, and weather that change is beneficial or not.
3.
Source of truth
With information being relayed in multiple formats (and from multiple teams), it is key we are able to display data from all available resources to serve as a source of truth for the enterprise.
What are the key UX challenges?
1.
Data translation
Data spread across each tool/system often uses its own metrics and definitions. We need to aggregate that data and display it in terms our team understands.
2.
Data display
The shear amount of data to collect and display is overwhelming. Showing that data in a way that benefits the decision making process of executives is our top priority.
The dashboard needs to compare trends across retailers to better help diagnose when Mars has an internal opportunity versus a specific retailer issue that needs to be solved. We also need to ensure that the new layout, design, and colors do not hinder the performance of decision-making or KPI analysis.
Each pillar had its own set of specifications and obstacles that needed to be overcome; however, my project lead and I had frequent meetings with each other and employees from the respective departments of the enterprise. Eventually, all necessary and supplementary elements were built out and added to the page layouts. Finally, we marked all the specifications of each element in order to be sent over to the software/engineering team.
User personas were made to dictate what features and KPI were most important for each pillar. We had a kick-off meeting with employees from each department, and our contact with them was ongoing throughout development of the new interface to ensure accuracy.
Few companies have the ability to supply the end-users for an intended software. Having real-time feedback to changes we made proved to be cruicial in our design process. With precise accuracy, we were able to design a framework that narrowed down on the necessary KPI analytics and decision-making metrics.
Spec documentation (shown below) is extremely helpful for the engineering team because it shows them the exact design dimensions for all components and how the interactions need to be implemented.
View full Spec docMy team lead had a lasting relationship with the developers of this product. Their past experience working together proved to be vital for a quick turnaround time and a smooth development process. I learned so much in terms of design and developer handoff from my mentor, but (for me) the primary takeaway from this project is the ability to foster a lasting relationship with the stakeholders and the people you work with.