Building a custom table component for an ERP while defining the core user experience
About casestudy:
Building a table for an ERP that could work across multiple use cases, simplify drilldowns, and always keep context visible. And yeah, before figuring out every page, we had to figure out the table.
CEO: “Alright team, it’s time we start creating our own product—enough of just building for others.”
Context
We started with a big idea: an ERP centered on supply chain, covering OMS, compliance, and TMS. The original vision didn’t fully come to life, but it evolved into something more focused. This was our second attempt at building our own product.
My Role
I was the sole designer on the project. The ask was simple on paper: make a “really good looking product.” In practice, my responsibility was to shape the UX from the ground up.
The product owner reached out and suggested we start building. The project was still in the planning phase, so we were shaping the plan while starting research. He walked me through what to expect, the kind of application we were creating, and why we were starting with Compliance and OMS.
So I started going through Odoo, which was the main inspiration for the tool. Pretty quickly, I realized the table wasn’t just one component — it was the core experience.
Problem
Since the applications were expected to communicate with each other and share a database, users needed an easy way to move between related information. For example, when an order is placed, it exists in the OMS, but it also connects to the WMS where pick-to-pack is managed. Users should be able to access both without feeling like they’re jumping between disconnected systems.
Goal
Simplify the table experience and reduce the number of clicks it takes for users to reach what they’re looking for.
Challenges
The developer wanted to use MUI, a Google Material React library that isn’t very friendly when you need deep customization. The team was mostly backend-focused and still learning React, so using something like Shadcn wasn’t really on the table at the time.
I got the table right. And with that, I could start deciding the basic structure for the user experience.
The application will be
A landing page experience, similar to a mobile OS, containing all the applications. Each application would typically have a manage page with a list/table. Clicking a row opens the details, where users can drill down further.
The table will be designed
Make drilldowns simple. Create groups and save filters as tabs. Let associated items expand from the row itself. Give easy access to details for the selected item.
Building upon the table further
The table was expanded further
The table experience quickly caught on and proved its worth in all kinds of situations.
Results
We did end up building the individual applications. The decisions around the table worked well for most of them, and the custom table helped keep the experience familiar.
With custom table
Drilldowns became simpler for applications with a lot going on. Navigation became simpler. The pattern scaled across multiple use cases, keeping the application familiar and easy to use.
Before: Without custom table
Navigates
After: With custom table
Navigates (new)
Navigates
Same info available