The legacy sales reports in WooCommerce were a well known pain point for merchants. Support frequently flagged the feature as difficult or frustrating to understand. Quantitative data showed merchants were not spending significant time engaging with the feature. In 2018, as part of a broader effort to modernize the core of WooCommerce, I lead a project to overhaul the legacy sales reports, and bring them up to modern, best-in-class standards.

WooCommerce reports before re-design 🙅‍♀️

WooCommerce analytics after re-design 🚀


To begin the process of overhauling analytics, I led an initial round of research and discovery.  The early research consisted of logging relevant interactions from support archives, and moderated merchant interviews. In addition to interviewing WooCommerce merchants, I also wanted to get a feel for how merchants using competitive platforms such as Shopify, BigCommerce, Etsy used their store’s analytics as well. During the interview process, the merchants shared their screens and walked through their day to day usage of their store admins. I paid special attention to how they used their analytics; I was curious about their likes, dislikes, must-haves, and biggest sources of frustration. Once merchants got on the topic of their analytics, lines of questioning centered around topics such as:

  • How often were they looking at their data?
  • What data points did they care about most?
  • What methods did they use to gather and analyze their data? 
  • How were they filtering data (previous day month year, compared to previous period, by product, category, or various product attributes etc.)
  • What if any third party tools were they using?
  • Why were they checking data? (Was it habit, email / push notification alerts, etc)
  • Did they generate any kind of automated reports?
  • If they could change anything about their current analytics, what would it be?

After wrapping up the merchant interviews, I conducted extensive competitor analysis. I created detailed documentation of features, strengths, and weaknesses of the most popular ecommerce tools and platforms. Combining the feedback from the merchant interviews provided an extra layer of context while evaluating the various platforms. The competitor analysis was prepared as a series of reports, and shared with stakeholders across the product organization for visibility and feedback. 

Excerpt from a competitor analysis report:

Metorik is the only experience that allows users to manually select the aggregation of data for a date range. (Graph by: day, week, or month) Most of our competitors automatically changed the aggregation depending on the selected date range. Giving our users control will benefit both big and small shops. Big shops will appreciate the ability to see peaks in daily sales over a long time period, where smaller stores will benefit from the ability to smooth out their low volume of data by looking at weeks or months. (we got this feedback from one of our recent interviews) Google analytics provides this option, as do most other BI tools like Domo and Tableau.

In the end, patterns of the most important features, flows, and pain points emerged. I collected and consolidated all of the data on a digital whiteboard. In conjunction with product and engineering teams, we identified the highest priority items that we’d include in our MVP. 

Yellow cards indicated a specific task to be done, while blue cards indicated specific features. A number 1 adjacent to a card indicated the highest priority, while a 4 indicated the lowest.


Prior to embarking on new designs, I established a number of guiding principles for the project. Because WooCommerce is open source, it was imperative that we focused on creating a consistent, flexible, and extensible library of components to power the experience. (ie: date range picker, filters, summary numbers, charts, tabular data, etc). Initially these components needed to support the features and flows uncovered in discovery. However; long term, we knew we’d get the most value out of the components if they could be re-used for other features, or by third party developers integrating their own features using the new analytics components. Consistency was also imperative from a user’s perspective as well. Given the wide variety of reports we’d be creating, I wanted to ensure that if a user was able to manipulate and interact with data in one report, they’d be able to use the same patterns in all of the other reports too. 

With that in mind, I set out to craft each component of the system, working through various iterations as a whole, as well as isolated, individual components. I spent significant time researching data visualization best practices, including usage of color, selecting the right type of chart for the job, and more. 

Early lofi wireframe of the orders report

Date range picker component

Advanced filters component

Summary number component – Report summary numbers also function as an interface for updating the data displayed in a chart

Chart component

Chart interaction details

Table component

Tying it all together in a hifi composition of the orders report

Validating the new designs + launch.

We tested high fidelity prototypes  with a number of the original interview subjects, and a new pool of merchants too. The testers were able to easily demonstrate an ability to complete the various tasks and flows that we had identified as part of the discovery process. Given the success, we felt confident in moving forward with development. 

Post release, we saw a significant decrease in the number of support tickets related to store analytics. At the same time, overall engagement with the new suite of reports increased. The report components are now used in multiple product features across WooCommerce, including, payments, multi-channel sales and marketing tools, our own marketplace vendor reports, and numerous third party developers’ analytics. 

The product report

Detailed view of a single product

Comparing categories