How to Design a Data Product? Interview with Service Designer Mitja Behnke

How to Design a Data Product? Interview with Service Designer Mitja Behnke

Have you ever thought about how data becomes something people interact with? Transforming raw information into valuable, user-friendly products requires both technical expertise and creative design thinking. But what exactly makes data become a product, and how does the design process differ from traditional product development? 

To uncover the topic of data products, I, Antonia Mittmann from the diconium data team, sat down with Mitja Behnke, Service Designer at diconium data and part of the enabler team for the Data Product Factory, the company’s corporate incubator for developing data products. From identifying user problems to navigating the unique challenges of working with data as a core material, Mitja shares his experience at the intersection of design and data science. 

Let’s start from scratch: what is a data product?  

On one hand, we have data, which is in our case raw material, our input. It can be anything from sales numbers to inventories. On the other hand, we have products, which can be systems, software, assets, or even services that solve a specific problem or need for a user and create business value through a repeatable and scalable process. So, all in all, a data product is a reusable system that combines data and tools to transform raw data into valuable outputs to solve specific problems.

It sounds quite abstract – can you give me a real-world example?  

Sure! In the Data Product Factory, we work on various topics that can range from reporting sustainability data to forecasting toolkits. Recently, we worked on the time series forecasting toolkit, which is a data product in terms of using a company’s revenue or inventory data to do forecasting of future revenues or inventory stocks, for example. During our research, we realized that many companies don’t have the specialized resources to make advanced forecasts, and existing tools are either advanced, code-intensive ones or no-code solutions that remain pretty shallow in the features they offer.

So, what we ended up doing is using AI and machine learning to create a no-code solution that enables intuitive yet advanced forecasting, which is also usable for non-data experts.”  

Working in the Data Product Factory: Service Designer Mitja Behnke (on the right). Photo credit: Daniel Chernets

Let’s say someone has a promising idea for a data product buzzing around…What’s the first thing you do? And where do you come in?

The first thing we should do when an idea emerges is to find out if it actually solves a real problem. Even if we solve the wrong problem really well, we still solve the wrong problem.

That is usually where we, as enabler team of the Data Product Factory, come in to help validate first assumptions and talk to potential users to find out more about their needs and challenges. In parallel, we also lead market research and do some competitor analysis to assess the potential.”  

Who’s usually involved in a data product team,
and whose expertise is needed in the process? 

That can vary depending on the domain. At diconium, we launched the Data Product Factory, an incubator program to develop data products. In our case, we have an idea owner who brings the idea to us. They are usually experts in the domain of their data product.

Then, we have the enabler team, composed of service designers and data scientists. And finally, we build a support system of various subject-matter experts who can help us understand the market, navigate legal constraints, or assess technical feasibility. If the idea turns out to be a promising opportunity, we will then involve a development team in further phases.”   

Since you’re a designer, I’m curious about the creative side as well.  
Is every development process different for each product,  
or do you follow a kind of blueprint or method?

The Data Product Factory is structured in four major phases: Explore, Design, Build, and Ship. Even though creative processes are less structured and repeatable, we do follow the design methodology, which covers user and market research, ideation and prototyping, user testing, and business models. It’s a general process that nevertheless allows iterations and high flexibility. In short, we have a broad portfolio of methods and frameworks, which we then adapt to each idea & project, depending on the domain, the project, and the idea’s maturity level.”  

How do you involve potential users in the
process of designing the product? 

In a design process, it is very important to involve users as early as possible and talk to potential users as one of the first steps when a project joins the Factory. It can sometimes be a bit of a chicken-and-egg situation, because we don’t necessarily have a clear and defined image of who the user is.

So, what we do is to build an assumption-based persona to later target and recruit participants, the potential end-users, for interviews. These interviews help us understand the needs and challenges that we can address. Once we’ve started crafting a solution, we involve users in later stages as well for co-creation, early design testing, and validation.”   

Is designing a data product different from
creating a typical non-data product?  

My background is in Industrial and Service Design, and while I can apply a lot of principles and methods in a similar way, there are also core differences with designing a data product.   

Take a simple example: a chair. The main difference is that data products use data as their core material. The value primarily comes from the insights we derive from that data, whether it’s predictions, automation, or personalization. In contrast, non-data products derive value from functionality, usability, efficiency, or even emotional connections. 

When designing a data product, we first need good data and good insights, and then the UX design can help to make it more usable. On the flip side, for designing a chair, the material can be wood or plastic – the material won’t change the core function of the chair, which is still meant to be sat on it. What it does influence, though, is the aesthetics and the look and feel of the product. It can also influence the consumer’s choice or even create an emotional connection between the user and the product. Still, the usability mainly comes from the function.  

With data products, this shifts a bit. For instance, a forecasting tool needs to deliver accurate predictions first. If those predictions aren’t solid, even the most visually appealing dashboard won’t win users over. The core value really lies in the effectiveness of the predictions first, with usability being important but secondary.  So even though data products are quite different from non-data products, designing them still follows the same core principles and methodologies.

Design is still design, and it always starts with the users.” 

Building a data product roadmap in the Service Design team. Photo credit: Daniel Chernets

Have you ever had the following situation:  
you built something exciting that just didn’t work out as expected? 

Possible outcomes of the Factory don’t necessarily need to be a new product launch. In some cases, the outcome can be to decide not to pursue a certain project further, so we can reallocate resources early. For example, we did extensive market research on a domain to realize that the market was extremely crowded and volatile, literally changing by the day. Therefore, we decided to recommend the discontinuation of the product as it would mean too much effort to enter the market as a new player.”   

Which impact should a data product have, in your own opinion?  
What does a successful data product look like?

“To me, a good data product should enable users to make informed, data-driven decisions, and ideally without them being data experts. It should solve a real problem or need, be intuitive, and help turn complexity into meaningful simplicity.”     

Back to top