Analytics tool for product trends

Access to data doesn't equal insight. Even with Grips offering the most granular SKU-level sales data on the market, users needed a way to cut through it - to know quickly what was selling, and at what price, so they could change product pricing, adjust positioning, or even update their offering before a trend fully played out.

The data itself came from many different sources, each structured a little differently; so the same kind of information didn't always live in the same place. A question like 'what pattern is trending across my competitors' could be answered by the data, but the answer might sit in a 'Pattern' column for one product, be folded into 'Color' for another, or only show up buried in a product title for a third. The data team was working on unifying these sources long-term, but that wasn't something users could wait on. The immediate challenge was making sense of that inconsistency as it existed and helping users find the signal without needing to know where, in this particular case, it happened to be hiding.

In initial discussions, the team agreed the core of the V1 feature would be a table of products matching the user's criteria, with visualizations planned for later iterations. Much of my early thinking focused on minimizing the perceived complexity of both the filtering and the table itself.

Since filtering would carry the most weight in building a report, I put significant research into advanced filtering patterns from direct competitors, so the solution would still feel familiar to users coming from those tools.

I mapped out the flow to establish how the new module would fit within the platform, alongside Grips' existing features.

I made sure we spent real time discussing the mid-fi solution with developers, confirming the flow we envisioned for users was technically viable and would return the results they expected.

To mitigate the risk of low discoverability, we added pointers and links in the existing module flows where users could benefit from deeper-analysis in the new module.

While the extra step is a real cost, it is also a meaningful input to the report. The step does double duty: it protects performance and gets users to relevant answers faster.

This one was a close-call. Intuitively the in-page filters that come with more directness and conflict visibility, but it would've been a short-lived win. The data constraints needed a more sophisticated and flexible solution, that doesn't stall the users.

Once launched, the Product Research module consistently came up in customer feedback as one of the most valuable additions to Grips platform. Even without sophisticated data visualizations (out of scope for V1) the flexibility of the solution let users pull fresh insight to inform their strategy at any moment.

Despite the flexible interface, data variability and non-standard mapping made building a report a somewhat laborious process. Larger customers, with dedicated resources, built their own reports, but smaller customers, where one person often wore many hats, couldn't afford the time to learn the data specificities. They relied on Grips account managers to build reports on their behalf, which consumed time and resources.

• To improve the filtering experience, the plan for future iterations was to simplify it toward patterns more familiar from B2C shopping platforms
• Immediate efforts focused on giving users more context on individual product performance; the Product Research module was soon enriched with historical revenue and sales data.