The Open Data Product Specification version 2.0 will be released on April 1, 2023. The focus of the development has been on defining the elements of a data product, with an emphasis on providing a foundation and technical examples. However, the developers recognize the importance of expanding their view to Data Product CX. A tool called ODPS Visualizer is needed to make ODPS more easily understandable to non-technical people. This tool would render the specification and show what choices made in the spec would mean for the product display. The tool would also be beneficial in specification development by showing the gaps and difficulties in applying it in practice. The long-term goal is to have an open-source React component that could be used in data marketplace implementations. The initial step towards this goal is to create clickable shared designs of the data product views using Figma. These designs would help communicate ODPS to the public and non-technical stakeholders in the data economy. The designs could use ready-made components created by the community and then share the Data Product views as designs and components back to the community. (ChatGPT generated summary)

Open Data Product Specification version 2.0 is coming out on 1st April 2023. The development has been very much on the basis of defining elements of a Data product. The focus of the spec development has been so far on providing the foundation and technical examples. Now we need to expand our views to Data Product CX. 

Why CX matters? 

According to Forbes: 

• companies with a customer experience mindset drive revenue 4-8% higher than the rest of their industries. 
• Companies that lead in customer experience outperform laggards by nearly 80%. 
• Customer-centric companies are 60% more profitable than companies that don’t focus on customers.
• 81% of companies view customer experience as a competitive differentiator.
• Companies that excel at customer experience have 1.5 times more engaged employees than less customer-focused companies.

Current status of Open Data Product Specification

So far we have created a human-readable documentation of the spec, which has helped us to understand it more quickly than just looking at the documentation and “dry” text. The documentation has had JSON examples from day one. The examples have been used to see how the specification could be implemented on the machine layer. 

The examples alongside the specification details have brought some “flesh” around the spec. Yet, the fact is that the ODPS is still hard to grasp even for technical people let alone others. 

Towards a great Data Product CX

The next step is to make ODPS more easily understandable by a plethora of non-technical people. What we need is ODPS Visualizer. Here are the main reasons why. 

1. The tool would render the spec given to it as an example of what the choices you make in spec would mean for the product display. In a way, the visualizer would provide a mockup tool to see what it would look like for the data consumers aka customers. 
2. The same tool would also be beneficial in specification development by showing the gaps and difficulties to apply it in practice. 
3. Provide shared design examples of how to build great CX around the data product. The design of the data product should be UX-wise developed by engaging data consumers in order to catch the CX requirements as well. 

Long run goal - reusable code component 

ODPS has been open source from the beginning. The reason for this was to remove some barriers to contributing and adopting it in practice. In the long run, this tool could be for example an open-source React component that could be used in data marketplace implementations. To make this real we need at least two things.

1. UX designer to design the views for data products that offer a great CX.
2. Then we need the developers to build the tool. This code-driven approach would take a significant amount of effort, time, and coordination.

ODPS is after all a free-time project with very limited resources (money or people involved). A quick win is needed. 

Quick win - clickable shared designs

The initial step could be as simple as making Figma designs of the data product views which would use the elements and options from ODPS. These designs could be clickable and mimic the UX behavior of a real marketplace interface. 

These mockups would have manually maintained content, but surely the screenshots taken from the design and clickable examples would help to communicate ODPS to the public and non-technical stakeholders in the data economy. 

This approach of starting from the “end” would take the ODPS development towards customer-oriented thinking. It would help the ODPS developers to see the gaps as well and see what is hard to use in the spec. 

The Figma design and its components in it would be part of the Figma base and community. The design could use the ready-made components created by the community and then share the Data Product views as designs and components back to the community. This would also widen the reach among the designers thinking about how to build a great CX experience for the data consumers on the product level. 

After the mockups have been further tested and iterated with data consumers and found to be good enough, then it might be a good spot to implement the visualizer as a tool with code. That would remove the manual updates of the views and would enable faster testing of options used in the data product. Eventually, as it was stated above, the code-driven implementation could (should) become a reusable component. 

Help us to drive better data product CX

There are multiple ways to help us in this effort.

• You can promote the idea on social media and with your associates. Share the blog post now!
• You can donate the sum you see fit for the Open Data Product Initiative under which ODPS is developed. The budget and spendings are open for anyone to see.
• Contact us to become a tester of the designs or even part of the design team (Jarkko Moilanen, Nazia Hasan)
• Define a technical plan to implement the code version (contact above)