What can happen when the data team doesn’t talk to the business? Misalignment in what the data team thinks the business needs. Then the business gets the data product, looks at it once and never uses it again.
Instead data teams need to become embedded into the business. Understand their short and long term goals and needs. How they spend there day to day, what are the struggles in identify the right information. Determine what metrics each teams cares about and how that ties the c-suite view. Breakdown silos in operations to get everyone speaking the same language, using the same definition for metrics, and aligning on the information strategy.
Wrapping up this series of posts, I will discuss the design process keeping in mind the mid-century modern principals discussed earlier. If you haven’t already check out the four prior posts
Your Dashboard Needs an Eames Chair → how mid-century modern design principles can transform your data visualizations from cluttered to clear
From Form Studies to Data Charts: The Shared DNA of Making Things → how Pratt's industrial design curriculum created the perfect training for the information age
Not Everything Needs to Be a Product or Chart → how focusing on communication and capability building creates more value than another visualization
Seamless Boundaries: When Data Lives Where Decisions Happen → what the Eames House teaches us about dissolving the walls between data and business
First lets define a data product. Looking at DJ Patil, former US chief data scientist, defined in Data Jujitsu: The Art of Turning Data into Product book as “a product that facilitates an end goal through the use of data." The data asset could be a table, notebook, query, file, or dashboard designed for a target audience.
Data teams can then track success of a data product based on usage metric(s), meaning 1) a data product is accessed and there is an increase in use over time, and 2) used by a substantial percentage of the target audience.
Now there will be times when a quick win is needed or an urgent ask comes up. To build trust with the business and depending on the complexity, they should be prioritized and built quickly. But the rest of the time, use the design process to ensure what is being built will actually be useful for the target audience.
At a high level the mid-century inspired design process steps are as follows
Discovery: observe the current state then define the problem to address
Metrics: determine the essential metrics to address the problem, including plain language definitions
Prototyping: build the interface and test with users to determine gaps, keep iterating and remember not everything needs to be a dashboard
Data: identifying if the data exists or if a process needs to be implemented to capture the data
Development: build the data and interface layers, automate as much as possible
Validation: test internally to ensure data is complete and accurate + test with end users to confirm it successfully addresses
Productionalize: move to a production environment, host kick of event, provide initial support to users
Considered this a general guideline, non-linear process. It is best to always start with the problem but there may be times when you start on step 3 or 4 the circle back to step 2.
Looking at a use case for a new startup looking to understand if their marketing efforts are having an impact on sales.
There would be discussions with the founders and sales teams to understand what the current issue in seeing the data is.
Identify the key metrics that will address the problem statement.
Prototype the end view, in this case it is a dashboard that highlights the key metrics, sales channels, geographic penetration and lead to sale velocity.
Track down if the data exists, determine what processes need to be adjusted or created. Then how sophisticated the data environment setup will be depends on funding and scale needed. This might be a case of automating data into cloud based sheets.
Next automate as many steps as possible via scripts to build the data pipeline. Then create the interface layer, using a cloud based dashboard platform.
Conduct internal testing within development team to confirm data is complete and accurate. Show to business to see if they also believe the information is complete.
Then move to a technical production environment but also have a kick off event with founders and sales team showing how to use the new dashboard, where the data is coming from, what problem this solves, and answer any questions.
Keep an open mind throughout the process. Consider time, determine quick wins, then always iterate and build. There is no perfect data product to meet everyone needs, but there is a path using the design process to start to fill those gaps to make the operational business successful. And remember this is a guideline, not a hard linear path. Take what you need on one project and leave what you don’t on another.
Written by me with AI ideating post structure
I am off to Disney World, no substack next week but there may be some Disney inspired LinkedIn posts
Subscribe to learn more about the craft and philosophy behind information design to not only understand how to make an effective chart or graphic but what makes them worthy of the important information they carry.