Inventory Management Application
Summary: Oracle inventory information was scattered across systems and manual spreadsheets, leading to duplicate orders, missing items, and billions of dollars lost. I designed an application that gives users a clear, at-a-glance view of their inventory across locations, with detailed information available when needed. Users responded well to the MVP as it showed information they desperately needed, such as total number of orders with errors and physical location of items. We kept expanding it with their feedback over the following months.
Company: Oracle
Industry: Enterprise supply chain/inventory management
Role: Lead designer
Team: 1 PM, development lead
Timeline (design to development):
MVP: ~3 months
Each post-MVP update: ~2-3 weeks
Tools: Figma, FigJam
Note: Some details, visuals, and application content have been intentionally generalized, reduced in quality, or obscured to protect confidential business information.
Overview
Although inventory management may seem straightforward, it rarely is for large companies working with thousands of products across multiple locations. Even basic questions become tough to answer: Where is this item located? How many exist? Have they already been used or reserved for another project? Is there a spare somewhere?
The ability to quickly and accurately answer questions like these has direct consequences on timelines, operational efficiency, and the company’s bottom line.
For Oracle, inventory information was scattered across systems and applications, including manual spreadsheets on individual computers. With no unified view, inventory management was difficult to say the least. Billions of dollars were lost because teams couldn't easily see whether an item was available, where it was located, or whether it was already being used. This resulted in duplicate orders, lost items, and being unable to reliably predict item availability.
With several major projects on the horizon, Oracle could no longer afford to operate this way. I was brought in to design an application that would give users a clear, at-a-glance understanding of their inventory, along with detailed information if needed.
User Research
The first thing the PM and I did was go directly to the people who would be using this application. Before designing anything, we had to understand how users were managing inventory today, where that process was breaking down, what workarounds they used to compensate, and what information was needed to do their jobs effectively.
Given how busy these users were, we kept sessions at 30 minutes max, with one to two users at a time. These early conversations quickly revealed that several distinct user groups were involved in inventory management, each with their own perspectives and needs.
Contextual Research and Discovery
Virtual interviews gave us a strong foundation, but to deepen our understanding, the PM, development lead, and I traveled to conduct in-person contextual interviews where we could observe users in their actual work environment rather than hearing about it secondhand.
This trip was invaluable. Seeing users perform their jobs in context surfaced things we wouldn’t have discovered otherwise. For example, we learned that barcode scanners were a core part of their workflow. We also saw that users were hauling large laptops around a sprawling warehouse floor, which was cumbersome and slowed them down. These weren't abstract usability concerns; they were real physical constraints that had to inform our design decisions.
Beyond the individual interviews, we also used this time together to conduct workflow mapping sessions. These helped clarify the current state, resolve ambiguities, and ensure we had a shared understanding going forward.
Following this trip, we synthesized what we learned into requirements and user goals. These goals became our north star for the entire project. Every design decision was measured against them to ensure we were always focused on solving the right problems.
Inventory Control Specialist user goals
Design and Iteration
Before jumping into design, I researched how internal and external applications handled similar inventory-related workflows. This helped us identify common UI patterns, understand what did and didn’t work well, and explore data visualizations that could make complex inventory information clearer.
Only at this point did I begin designing the first version of the application. For example, I used a table on the Shipping Metrics page so it was easy to quickly understand and compare this information. I also included tabs, such as Overview and Daily View, to clearly organize this information and reduce cognitive load.
Over the following weeks, the PM, development lead, and I iterated on the designs together, constantly comparing them against known requirements and technical feasibility.
Initial wireframe design for Reports page
I also made sure that the application was accessible for everyone. For example, I used:
A clear heading hierarchy (both visually and semantically) so that everyone could understand the content structure.
Permanent text labels for form fields so that they were always visible even after clicking into a field.
Semantic HTML so that elements like tables could always be easily navigated and understood.
Once we were in alignment on the design, I scheduled 30-minute usability testing sessions with users to determine:
Was the application easy to understand?
Did it have all the information needed to do their jobs?
Was anything wrong, missing, or confusing?
The feedback from these sessions helped us better understand how users thought about and categorized inventory, including terminology they used that was either absent from or wrong in the current design.
Users also mentioned that the Shipping Metrics page name was too narrow, since it only covered 1 part of the process. I renamed it “Ordering Metrics” to reflect all steps involved. Users also wanted visualizations to clarify and support the metrics table. I added charts, such as Order Activity Over Time, which showed trends like how order activity changed over different time periods, giving users a clear way to spot patterns and anything needing attention.
Initial wireframe design for Shipping Metrics page
Development Collaboration
As development got underway, my involvement didn't stop at design handoff. I met with the development team weekly, making adjustments and pivoting as constraints came up. For example, late, unavoidable timeline changes meant the development team had to build the MVP on an older reporting application instead of Oracle’s Redwood components. This limited the MVP to a smaller set of visualizations and reports than originally planned. I worked with the team to make sure what was shipped was still easy to use and understand, including right-aligning numbers, keeping the same terminology users were used to, and preserving the same drilldowns to additional details as originally designed.
Results and Impact
The MVP was well received by users because it provided visibility into information like where inventory was physically located, whether orders with errors were trending down over time, and where a product was in the inventory management process (for example, Ordered, In Transit, or Received at Warehouse).
Over the following months, I updated the application to use Oracle’s Redwood components and continued collaborating with users to expand it. This included adding additional visualizations, refining existing features, and incorporating new functionality. For example, I learned it was important for users to know which products had an Oracle part number assigned, since that number was used to correctly identify and receive parts at the warehouse. I added a simple OPN column and filter to the tables so users could quickly see which parts still needed a number assigned.
Later version of Ordering Metrics page (recreated for portfolio purposes, not the actual shipped interface)
Later version of Reports page (recreated for portfolio purposes, not the actual shipped interface)
“Meghan is highly responsive and proactive in her engagement with customers, ensuring that requirements are understood, communicated effectively, and translated into meaningful solutions.”
Lessons Learned
Design doesn’t end at development handoff: One of the clearest takeaways from this project was that simply handing over designs to the development team without continued UX involvement was not an option for this complex application. Technical constraints happen, and staying engaged with development is part of the process, and the quality of the final product reflects this.
Feedback is a gift: It can be uncomfortable to receive critical feedback on work you've invested a lot of time and effort into. However, every piece of feedback contains something useful. For example, when we initially showed our design to users, they mentioned that some products could have multiple Oracle part numbers, which required us to completely rethink how to display this information in small table cells.
Different perspectives often lead to design directions and solutions that you wouldn't have considered otherwise. Treating feedback as an asset makes the process more collaborative, sustainable, and successful for everyone involved.