Building a Data Visualization Tool for Kohl’s
UX Research
Product Design
UI Design
The Problem
After COVID-19 and resulting issues with the *global supply chain, Kohl’s decided there was a need for higher visibility of product tracking. In 2022 I worked within their technology department to help create a user interface that would visualize this data in a user-friendly way.
*According to the White House’s Council of Economic Advisors, retailers were the 3rd most impacted by the Covid-19 pandemic
The Task
Lead a cross-functional team to research and design the user interface for a product tracking data visualization tool.
My Role
In this role, I worked as a product designer on a cross-functional team working to build an internal data visualization tool for Kohl’s logistics department. This was an agile project and team that included engineering, data science, product management, and design. In addition to creating concept sketches and building preliminary wireframes, I conducted a significant amount of UX Research to identify relevant stakeholders and validate early concepts.
This was my first experience working with such a technical team, so one of my most important takeaways from this project was learning how to communicate with different disciplines and streamline the design-to-development process.
data synthesis in Miro
Unique Challenges
The supply chain is every step of a product’s life cycle, from when it is manufactured to how it arrives in stores. Because of its global network of systems, people, and technology, it is a vast and complicated space.
My biggest hurdle working with Kohl’s logistics department was understanding the context of my users, such as their technical vocabulary and the data they used to move Kohl’s inventory.
The Existing System
After gaining a basic understanding of the project space, I led two cursory user interviews with members of the logistics department in which I aimed to understand how supply chain issues were impacting them. Through these discussions, I discovered that creating accurate product shipment forecasts involved manually and painstakingly, updating product data in Excel (see below)
In one interview, the head of Logistics even walked me through this process, showing me the real Excel file he used, noting the gaps in data he would later have to tack down. Through this discussion, it became strikingly obvious, that this data not only needed to be more reliable but also easy to interpret.
“If you guys could do that, it would save me about 4 hours a day.”
Early Wireframing & Continual Discovery
After solidifying a scope, I conducted two additional interviews with Supply Chain Executives James Biles and Paul Pantich to identify the most important pieces of data I needed to display in my user interface.
They stated they needed the ability to 1) view the volume of products coming into domestic ports 2) be able to view product volume by individual ports 3) determine which ports were at risk of being “over or under capacity”.
To quickly gather feedback, I sketched a series of rough concept sketches to validate if my understanding was in line with their needs. This low-fidelity approach allowed me to quickly test multiple concepts and hone in on a clearer direction for my wireframes
Wireframe Iteration
I conducted two rounds of concept testing during the development of my wireframes. During these tests, most of the feedback I got was on how to display the data control panel. Although multiple design options were considered, my users preferred a simple, radio-button style for controls, citing that it was the “simplest and most efficient” way for them to view the data.
Risk indication was a particularly important feature, but one that required more discussion with developers, data scientists, and stakeholders. I presented two different legends to these groups and based on user preference and ease of implementation decided on the simpler classification of 1)moderate and 2) severe.
Building a Minimum Viable Product
With a solid design of my tool’s user interface, the team and I began building a minimum viable version of our product (MVP) in the hopes of getting the earliest feedback on functionality. As a result, my workflow focused less on ideation and more on technical syncs with front and back-end developers. Because my initial design was static, these meetings included mapping out different use cases, of data edge cases, and how we wanted our tool to respond in these situations.
Below is the MVP that my team delivered and was able to demo for our stakeholders.
