Hast du dich schon einmal gefragt, wie aus Daten etwas wird, womit Menschen tatsächlich interagieren? Rohinformationen in wertvolle, nutzerfreundliche Produkte zu verwandeln, erfordert sowohl technisches Know-how als auch kreatives Design-Thinking. Aber was macht Daten überhaupt zu einem Produkt – und wie unterscheidet sich der Designprozess von der traditionellen Produktentwicklung?
Um das Thema Datenprodukte zu beleuchten, habe ich, Antonia Mittmann aus dem diconium data Team, mit Mitja Behnke gesprochen. Er ist Service Designer bei diconium data und Teil des Enabler-Teams der Data Product Factory, dem unternehmensinternen Inkubator für die Entwicklung von Datenprodukten. Mitja teilt seine Erfahrungen an der Schnittstelle von Design und Data Science – vom Aufspüren echter Nutzerprobleme bis zum Umgang mit all den speziellen Herausforderungen, die Daten als „Rohstoff“ so mit sich bringen.
Fangen wir ganz von vorne an: Was ist überhaupt ein Datenprodukt?
„Auf der einen Seite haben wir Daten – das ist bei uns das Rohmaterial, unser Input. Das können ganz verschiedene Dinge sein, von Verkaufszahlen bis hin zu Inventarbeständen. Auf der anderen Seite haben wir Produkte – das sind Systeme, Software, Assets oder sogar Dienstleistungen, die ein konkretes Problem oder Bedürfnis für Nutzer lösen und durch einen wiederholbaren und skalierbaren Prozess auch wirtschaftlichen Wert schaffen. Ein Datenprodukt ist also ein wiederverwendbares System, das Daten und Werkzeuge kombiniert, um aus Rohdaten wertvolle Ergebnisse zu schaffen, und damit gezielt Probleme löst.“
Das klingt ziemlich abstrakt – hast du ein Praxisbeispiel?
„Klar! In der Data Product Factory arbeiten wir an vielen Themen; sie reichen von Nachhaltigkeitsberichten bis zu Prognose-Toolkits. Kürzlich haben wir ein Zeitreihen-Prognose-Toolkit (Time Series Forecasting Toolkit) entwickelt, das als Datenprodukt die Umsätze oder Inventardaten eines Unternehmens nutzt, um z. B. zukünftige Umsätze oder Lagerbestände vorherzusagen. Während unserer Recherche haben wir gemerkt, dass viele Unternehmen keine spezialisierten Ressourcen für fortgeschrittene Prognosen haben, und die existierenden Tools sind entweder sehr technisch und verlangen Coding-Skills oder sie bleiben als No-Code-Lösungen ziemlich oberflächlich in ihren Funktionen.
Für unser Endprodukt haben wir KI und Machine Learning genutzt, um eine intuitive, aber zugleich fortschrittliche No-Code-Lösung zu schaffen. Mit dieser können auch Diejenigen anspruchsvolle Prognosen erstellen, die noch nicht besonders datenversiert sind.“
Angenommen, jemand hat eine Idee für ein Datenprodukt…
Was ist der erste Schritt? Wo kommt ihr ins Spiel?
„Als Allererstes finden wir heraus, ob die Idee wirklich ein echtes Problem löst. Wenn man ein falsches Problem brillant löst, bleibt es ein falsches Problem.
Genau da kommt unser Enabler-Team der Data Product Factory ins Spiel: Wir helfen, Annahmen zu validieren und sprechen mit potenziellen Nutzern, um ihre Bedürfnisse und Herausforderungen besser zu verstehen. Parallel dazu führen wir Marktrecherchen durch und analysieren Wettbewerber, um das Potenzial der Idee einzuschätzen.“
Wer ist typischerweise Teil eines Datenprodukt-Teams,
und welche Expertise wird benötigt?
„Das hängt vom jeweiligen Bereich ab. Bei diconium haben wir die Data Product Factory als Inkubatorprogramm ins Leben gerufen. Bei uns bringt der sogenannte Idea Owner die Idee ein – meist ist das jemand mit Fachwissen im jeweiligen Themengebiet. Dann gibt es das Enabler-Team mit Service Designern und Data Scientists. Ergänzend holen wir verschiedene Fachexperten dazu, die uns im Marktverständnis, bei rechtlichen Fragen oder technischer Umsetzbarkeit unterstützen. Wird aus der Idee eine vielversprechende Chance, stoßen Entwickler zu den weiteren Phasen dazu.“
Du bist Designer – wie sieht für dich der kreative Part aus?
Ist jeder Entwicklungsprozess anders oder
folgt ihr einer Art Blueprint oder Methode?
„Die Data Product Factory ist in vier Phasen strukturiert: Explore, Design, Build und Ship. Auch wenn kreative Prozesse weniger strikt sind, folgen wir klar einer Designmethodik: Dazu zählen Nutzer- und Marktrecherche, Ideation & Prototyping, Nutzer-Testing und Geschäftsmodell-Entwicklung. Der Prozess ist allgemein gehalten, lässt aber viel Raum für Iteration und Flexibilität. Kurz gesagt: Wir haben einen großen Werkzeugkasten an Methoden und Frameworks, den wir je nach Projekt anpassen – abhängig vom Thema und auch vom Reifegrad der Idee.“
Wie bezieht ihr potenzielle Nutzer während des Produktdesigns ein?
„Im Designprozess ist es essenziell, die Nutzer so früh wie möglich mit einzubeziehen – Nutzerinterviews sind eines der ersten Dinge, die wir in der Factory machen. Häufig ist aber noch gar nicht genau klar, wer die Nutzer überhaupt sind. Daher bauen wir zunächst eine Persona basierend auf Annahmen und rekrutieren daraufhin die Interviewpartner, also potenzielle Endnutzer. Durch diese Gespräche erkennen wir Bedarf und Herausforderungen. Sobald wir die ersten Lösungen entwickeln, holen wir Nutzer zur Co-Creation, zum frühen Design-Testing und bei der Validierung wieder ins Boot.“
Ist das Designen eines Datenprodukts eigentlich so anders als
das Entwickeln eines klassischen gegenständlichen Produkts?
„Mein Hintergrund ist Industrial and Service Design. Viele Prinzipien und Methoden sind ähnlich anwendbar – es gibt aber zentrale Unterschiede.
Ein einfaches Beispiel: Ein Stuhl. Datenprodukte bestehen im Kern aus Daten. Die Wertschöpfung kommt vor allem aus den Erkenntnissen, die wir daraus gewinnen, wie Vorhersagen, Automatisierung oder Personalisierung. Bei nicht-datenbasierten Produkten kommt der Wert eher aus Funktionalität, Nutzbarkeit, Effizienz oder emotionalen Bindungen. Beim Datenprodukt braucht es zuerst gute Daten und Einblicke – erst dann kann der UX-Design-Prozess das Produkt benutzbar machen. Ein Stuhl wiederum, egal ob aus Holz oder Plastik, dient immer noch dem Sitzen. Das Material kann zwar das Aussehen oder die emotionale Bindung beeinflussen, nicht aber die Grundfunktion.
Bei Datenprodukten verschiebt sich das etwas: Ein Prognose-Tool muss erst liefern, was es verspricht, zum Beispiel möglichst präzise Vorhersagen. Wenn diese Prognosen nicht brauchbar sind, kann auch das schönste Dashboard keine User langfristig überzeugen. Der Erfolg steht und fällt mit der Wirksamkeit der Daten – die gute Bedienbarkeit ist wichtig, aber zweitranging. Auch wenn Datenprodukte also recht anders konzipiert sind, folgen wir im Designprozess den gleichen Methoden und Kernprinzipien.
Design ist schließlich Design, und es fängt immer beim Nutzer an.“
Hattest du jemals den Fall, dass ihr etwas richtig Cooles gebaut habt, das dann aber nicht wie erhofft funktioniert hat?
„Der “Output” der Factory muss nicht zwangsläufig ein neues Produkt sein. Manchmal führt eine intensive Recherche dazu, dass Projekte bewusst gestoppt werden. So können Ressourcen frühzeitig umverteilt werden. Ein Beispiel: Einmal stellte sich nach ausgiebiger Marktrecherche heraus, dass das Feld extrem umkämpft und volatil war, der Markt änderte sich quasi täglich. Wir haben dann entschieden, die Produktentwicklung nicht fortzusetzen, weil der Invest als neuer Anbieter nicht lohnenswert gewesen wäre.“
Welchen Impact sollte ein Datenprodukt deiner Meinung nach haben,
was macht es erfolgreich?
„Für mich muss ein gutes Datenprodukt Nutzern ermöglichen, fundierte, datengetriebene Entscheidungen zu treffen, ohne dass sie Datenexperten sein müssen. Es sollte ein echtes Problem lösen, intuitiv bedienbar sein und Komplexität sinnvoll reduzieren.“