A new dynamic data table. All primary actions are placed on the right side, while global filters sit on the left and remain visible across the entire tool.
Data table that drives real usage - 4000+ table exports.
Priceindx
B2B / SaaS / Web App
Impact
Adoption after launch was fast. Internal metrics showed strong usage early on, which was also reflected in customer feedback. Beyond the feature itself, its release improved overall satisfaction with the product.
4000+
Data exports generated
120+
Custom workflow views
"Very positive."
Customer quote
"Really good."
Customer quote
One customer invested in an ultra-wide monitor to see the entire table at once.
Customer feedback
Customers: 80+. Metrics have been anonymised, rounded and presented without a time frame to protect company confidentiality.
Export - a widely used feature. Exports can take time to process. To help, we allow customers to run multiple exports at once and easily track their progress.
Table filters and global filters. Global filters operate at product level. Selections made in one tool persist across the product, ensuring a continuous workflow.
Designed for daily product management workflows. Customers can configure a table view once and save it for quick, repeated access.
Sort. Customers can sort by any quantitative value in the table, add multiple sorting criteria, and define their priority.
Customers can fully customize column visibility and order. However, core attributes remain fixed to ensure the table always remains usable.
Context
Gathering and processing large amounts of data is at the core of the service Priceindx provides for retailers and brands.
When I joined, the company's data tools were outdated and rigid. We started by completely rebuilding the data table—a highly requested update to improve both information density and usability.
Problem
The existing tool was just a simple list of products and price changes. Its structure didn’t allow us to include all the data we had, let alone new functionality. Customers needed something that brought all product information together and actually fit into their everyday workflows.
The legacy product list. While this simple table served customers for years, it had reached its limits and needed an overhaul.
Solution
We built a dynamic table that includes all product information and can handle growing data. Customers can now sort, filter, save views, and export data, making it a truly useful tool in their daily workflows.
A new dynamic data table. All primary actions are placed on the right side, while global filters sit on the left and remain visible across the entire tool.
First challenge - what is the table?
When we knew that we were going to build a table, I faced my first challenge: my knowledge about tables was not enough to design it. My closest reference was Excel - and that’s not quite the same thing. So I had to really understand what it was I was about to build.
I learned everything I could about data tables: structure, behaviour, filtering, sorting, and edge cases. It was important to understand the table on a conceptual level, because people expect the same thing to work the same way everywhere.
Then I designed the table from scratch, column by column. Literally. Because a lot of the data was custom and required non-standard display patterns. For example, some cells needed to present three data points at once, with different states and behaviours depending on the scenario.
Knowing the data tables inside out created a strong foundation - every future decision was made in knowing its impact on every part of the feature and therefore how it may affect the customer.
Biggest constraint - infrastructure, of course.
The constraint with the biggest impact was the underlying system infrastructure, which directly affected table performance. And in data-heavy environments, performance is everything - every millisecond is a win.
Because of that, we chose batch filtering instead of per-filter fetching. This, in turn, affected how filters were positioned: instead of inline (per column), we went with a separate filter dialog. One customer did ask for inline filtering during testing, though.
Another decision driven by this constraint was choosing customer-initiated incremental loading instead of infinite scroll. Requesting all the data from the backend at once would have meant much longer loading times.
All of these choices helped ensure the table performs well, no matter how large the dataset gets.
Approach- design it for the biggest customer.
Building something big is already a challenge. Building something big and dynamic makes it twice as hard. Depending on the customer, the amount of data varied a lot, so we decided to design the feature around our largest customer’s database. If it worked for them, it worked for (almost) everyone.
This approach helped surface pain points early on.
For example, the number of product attributes was very high, which meant the table ended up with more than 60 columns. That would have been overwhelming and hard to navigate, so I divided the data into sections and allowed customers to choose which sections and columns they wanted to see at any given moment.
The second challenge was scrolling. An average laptop screen fits about 10 columns, while even the smallest customers had far more than that. On top of that, each table row included an inline table. So I mapped out the scrolling behavior - which parts scroll, which parts stay sticky, and how everything works together.
Team and my role
Product strategy officer, product owner, engineers and designer.
As the sole designer, I was responsible for the whole process, from concept to polished UI. I was working closely with the product and engineering teams to shape the solution within real technical and business constraints.
Next project:
Data visualization tool - 60% trial start rate