TL;DR -- leverage a tool like Avo (www.avo.app), Iteratively (acquired by Amplitude), or TrackingPlan (www.trackingplan.com).Every aspect of the modern data stack (data collection, visualization, storage, etc.) has solutions and alternatives that support companies as they scale. The only piece of the puzzle that didn't have an at-scale alternative, was the analytics planning and governance space. Until recently, teams were forced to use spreadsheets and docs to manage their analytics tracking which made it hard for less technical folks to contribute to, and impacted the overall quality of their data. As teams grew, they had no Enterpise-ready alternative to grow into. So, they had to continue maintaining these spreadsheets and docs; often times creating a new one for each siloed team. Next thing you know, there's no source of truth, no enforced naming conventions, and a poor data user experience overall.With the tools mentioned above, teams can now have a "heartbeat" on their analytics implementation -- knowing which events they can trust, and which ones conflict with the design of their tracking plan. By fixing the existing implementation and preventing poor tracking moving forward, these teams can significantly improve their overall data user experience across product, engineering, analytics, marketing, and more.
Adopt the Product Management / UX patterns from our software brethren.Create personas so you know who your data users are, and how they would expect to interact with the data.Try wireframing the final visualisations, before you build the dashboard etc. Try creating a Dashboard first with mocked up data and then doing some UX testing with your expected users, before you build it in anger.Try mocking up the data in excel using a pivot table and get the users to see if there is any data missing.Create design systems that give you reusable patterns that you can leverage each time.The key is get feedback early in your process, don't wait until you have built everything and then wait for the feedback, its to late.
When thinking of building a data product, there are two thought disciplines coming together. 1. Product Management - As the name suggests, Data Product, are supposed to be products with the product thinking underlying its build. What that essentially means is that there is a deep customer empathy, value for customers and great Product-Market fit (although at a much different scale and audience).2. Software Engineering - Now the hidden truth of data products, they are essentially software constructs which needs to have great value without having a UI/UX to "wow" the customers with. Most of the times, the users of the data products are going to developers and/or product managers. This means that you need to build a product which developers spectacular value with great NFR (Non-Functional Requirements) in Software Engineering parlance. For example, very easy integration capability, easy to test etc.To sum up, having an understanding of the end users and their use cases along with high degree of customisability and list of the NFRs ticked off so that it gives the developers/product managers peace of mind.