Wie alles begann

FamCook steht für Family Cooking. Die Ausgangsfrage klingt banal: Was kochen wir heute?

In unserem Familienalltag mit vier Kindern zwischen neun und fünfzehn Jahren ist sie erstaunlich schwer zu beantworten. Eine Person mag keine Pilze, eine andere möchte scharf essen, ein Kind bevorzugt vertraute Gerichte, jemand verträgt bestimmte Zutaten nicht und an manchen Tagen fehlt schlicht die Zeit.

Meistens musste sich meine Frau mit dieser Frage beschäftigen. FamCook entstand deshalb zunächst als Geburtstagsgeschenk für sie.

Ich fragte ChatGPT eher scherzhaft, ob es mir helfen könnte, eine kleine App dafür zu programmieren. Da ich selbst nicht programmieren kann, erwartete ich keine besonders praktische Antwort. Stattdessen hieß es sinngemäß: Ja, das können wir versuchen. Also haben wir angefangen.

Der ursprüngliche Scope war klein. FamCook sollte zunächst nur dabei helfen, die tägliche Entscheidung etwas leichter zu machen.

Die meisten Rezeptplattformen beantworten: Was könnte ich kochen? FamCook sollte eine andere Frage beantworten: Was passt heute zu genau den Menschen, die miteinander essen – und zu ihrer aktuellen Situation?

Profile, die mit der Nutzung wachsen

Jedes Familienmitglied beginnt mit einem einfachen Profil. Dort werden bevorzugte und abgelehnte Zutaten, Schärfegrad, Ernährungsweise, Unverträglichkeiten und weitere relevante Hinweise erfasst.

Diese Angaben sind kein endgültiges Etikett. Profile können sich mit der Nutzung weiterentwickeln. Welche Rezepte werden angesehen, gespeichert, gekocht, verändert oder verworfen? Welche Zutaten funktionieren in bestimmten Kombinationen? Welche Vorlieben verändern sich mit der Zeit?

Dabei müssen Menschen FamCook nicht zwingend selbst bedienen. Kinder oder ältere Familienmitglieder können von anderen mitverwaltet werden und ihr Profil später übernehmen. Das System soll Lebensrealität abbilden, statt für jede Person ein eigenes aktives Nutzerkonto vorauszusetzen.

Dahinter steckt inzwischen ein Prinzip, das weit über FamCook hinaus meine Arbeit prägt: Nicht der Mensch sollte die Logik der Software lernen müssen. Die Software sollte sich so weit wie möglich an den Menschen anpassen.

Was das Produkt bereits weiß, sollte es nicht erneut erfragen. Informationen sollten dann erhoben werden, wenn sie für die nächste Entscheidung relevant sind.

Die richtige Überschneidung für diese Gruppe

Nicht immer isst die ganze Familie gemeinsam. Manchmal kocht ein Elternteil nur für die Kinder, manchmal essen zwei Personen zusammen, manchmal kommen Gäste hinzu.

Deshalb wird vor der Suche ausgewählt, für wen gekocht werden soll. FamCook vergleicht nicht pauschal alle Profile, sondern genau die Menschen der aktuellen Situation.

Das Ziel ist nicht, ein Gericht zu finden, das mathematisch allen gleich gut gefällt. Das Produkt soll den besten realistischen gemeinsamen Bereich erkennen und zugleich sichtbar machen, wo sich ein Gericht anpassen lässt.

Personalisierung wird damit zu einem Gruppenproblem: unterschiedliche Bedürfnisse werden nicht zu einem abstrakten Durchschnitt zusammengefasst, sondern im Kontext der tatsächlichen Situation miteinander in Beziehung gesetzt.

Von einer kleinen App zu einem Produktsystem

Der ursprüngliche Scope von FamCook war überschaubar. Dann kamen neue Ideen. Mit jeder Funktion wurde sichtbarer, welche anderen Teile dafür benötigt werden.

Rezepte konnten nicht nur gesucht, sondern auch importiert, gespeichert oder mit KI entwickelt werden. Daraus entstanden Wochenplanung, Einkaufslisten und Aufgaben.

Dann wurde deutlich, dass Rezepte allein nicht genügen. FamCook muss verstehen, was Zutaten sind, wie sie miteinander in Beziehung stehen, was beim Kochen mit ihnen geschieht und welche Geräte benötigt werden. Auch Situationen spielen eine Rolle: Campingurlaub, schnelles Essen nach dem Sport oder ein gemeinsames Wochenende stellen unterschiedliche Anforderungen.

Irgendwann bestand die eigentliche Herausforderung deshalb nicht mehr darin, neue sichtbare Funktionen hinzuzufügen. Die wichtigeren Fragen lagen unter der Oberfläche: Wie bleiben Daten konsistent? Welche Information gilt als fachliche Wahrheit? Was passiert, wenn dieselbe Information von mehreren Funktionen benötigt wird? Wie wirken Änderungen auf andere Bereiche des Produkts? Wie verhindern wir, dass neue Funktionen alte Logik unbemerkt beschädigen?

Aus dem organischen Weiterbauen wurde schrittweise ein systematischer Entwicklungsprozess. Projektplanung und regelmäßige Reviews kamen hinzu. Eine Single Source of Truth wurde notwendig. Datenmodelle und Beziehungen wurden wichtiger als einzelne Screens.

Komplexität gehört ins System

Diese Entwicklung hat auch meine Definition von Product Design verändert. Ich gestalte nicht nur Interfaces. Ich gestalte zunehmend das Verhalten eines Systems: Was weiß es? Wann fragt es? Welche Entscheidung muss der Mensch treffen? Welche kann das Produkt selbst übernehmen? Welche Konsequenzen müssen sichtbar bleiben? Welche Komplexität kann vollständig im Hintergrund verschwinden?

Viele digitale Produkte verlangen zunächst, dass Menschen lernen, wie das System denkt: welche Angaben es wann erwartet, wo Funktionen liegen und welche Reihenfolge vorgesehen ist.

FamCook führt mich immer stärker zur entgegengesetzten Frage: Wie viel dieser Arbeit kann das Produkt selbst übernehmen?

Wenn das System bereits weiß, wer gemeinsam isst, welche Präferenzen existieren und welche Entscheidungen zuvor getroffen wurden, sollte es diese Informationen nutzen. Wenn eine Änderung Auswirkungen an anderer Stelle hat, sollte das Produkt diese Beziehungen verstehen.

Das System darf intern komplexer werden, wenn dadurch der Nutzungsmoment einfacher wird.

Mit KI entwickeln, ohne Verantwortung abzugeben

Ich bin Product Designer, aber kein klassisch ausgebildeter Softwareentwickler. FamCook entwickle ich deshalb gemeinsam mit KI-Systemen.

Anfangs waren es ChatGPT und ich. Mit wachsendem Produkt kam eine zweite KI hinzu. Heute unterstützen mich zwei KI-Systeme bei unterschiedlichen Aufgaben – unter anderem bei Recherche, Produktarchitektur, technischer Analyse und Umsetzung.

Dadurch kann ich als einzelner Product Designer wesentlich weiter in tatsächliche Produktentwicklung hineinreichen, als das früher möglich gewesen wäre. Die Entwicklungskosten liegen derzeit bei ungefähr 100 Euro pro Monat. Die Arbeit findet überwiegend in meiner Freizeit statt.

Aber mehr technische Möglichkeiten bedeuten nicht weniger Verantwortung. Im Gegenteil. Je komplexer das Produkt wurde, desto wichtiger wurden Regeln, Reviews und überprüfbare Entscheidungen.

Ein Beispiel dafür ist Produktwissen. KI kann erkennen, dass zwei unterschiedlichsprachige Zutaten wahrscheinlich dasselbe Lebensmittel meinen oder dass ein unbekannter Begriff zu einer bestimmten Lebensmittelgruppe gehört. Aber eine plausible Interpretation ist noch kein Fakt.

Daraus entstand ein zentrales Prinzip: KI darf recherchieren und interpretieren. Überprüfbare Regeln bestimmen, was als Wissen übernommen wird. Bestätigte Erkenntnisse werden gespeichert, damit dieselbe Frage beim nächsten Auftreten nicht erneut erforscht werden muss.

Erst verstehen, dann umsetzen.

Mit wachsender Produktkomplexität hat sich für mich auch eine zentrale Frage im Design verändert. Ich frage nicht mehr zuerst, wie sich eine Funktion möglichst einfach bedienen lässt. Ich frage zunächst, warum der Mensch sie überhaupt bedienen muss.

Wenn FamCook bereits weiß, wer gemeinsam isst, welche Vorlieben und Unverträglichkeiten bestehen, was zuvor entschieden wurde und in welchem Kontext eine Aufgabe stattfindet, sollte dieses Wissen Arbeit abnehmen – statt neue Formulare, Einstellungen und Abfragen zu erzeugen.

Das bedeutet nicht, Entscheidungen vor dem Menschen zu verstecken. Wo Konsequenzen relevant oder mehrdeutig sind, muss das Produkt sie sichtbar machen und nachfragen. Was sich dagegen eindeutig aus vorhandenem Wissen und Kontext ergibt, kann das System übernehmen.

Für mich verschiebt sich Product Design damit vom Gestalten einzelner Interfaces zum Gestalten des Verhaltens eines Produkts: Was weiß es? Wann muss es fragen? Was kann es selbst übernehmen? Was muss sichtbar bleiben? Und welche Bedienung kann ganz verschwinden? Erst danach entscheide ich, welche Oberfläche es dafür überhaupt braucht.

Feedback braucht einen Ort und einen Kontext

FamCook wird aktuell von mir selbst genutzt. Der nächste Schritt ist ein kontrollierter Betatest mit etwa 25 bis 50 Personen aus unserem Freundes- und Bekanntenkreis.

Dabei soll nicht nur überprüft werden, ob einzelne Funktionen funktionieren. Getestet werden vollständige Abläufe: vom Profil über Rezeptsuche und Planung bis zu Einkauf und Kochen.

Feedback soll nicht über verstreute Nachrichten, E-Mails oder Erinnerungen gesammelt werden. Beobachtungen können direkt im Produkt zusammen mit Screenshot und Nutzungskontext gemeldet werden.

KI kann Rückmeldungen clustern, ähnliche Probleme zusammenführen und Muster oder Widersprüche sichtbar machen. Gleichzeitig zeigen tatsächliche Nutzungsschritte, wo Menschen Schwierigkeiten haben. Beides unterstützt Produktentscheidungen. Beides ersetzt sie nicht.

Schwimmen mit Musik – aber ohne Streaming

Ausgangspunkt war der Shokz OpenSwim. Der Kopfhörer überträgt Klang über Knochenleitung und kann beim Schwimmen getragen werden.

Da drahtlose Streamingverbindungen unter Wasser nicht zuverlässig funktionieren, werden Audiodateien lokal auf dem Gerät gespeichert. Das ist technisch sinnvoll und während des Schwimmens angenehm reduziert.

Die eigentliche Schwierigkeit beginnt vor dem Training: Welche Dateien liegen auf dem Gerät, in welcher Reihenfolge werden sie abgespielt und wie lässt sich der Inhalt an verschiedene Situationen anpassen?

Abspielen war einfach. Organisieren nicht.

Musik, Podcasts und Hörbücher liegen auf dem Computer in unterschiedlichen Ordnern und Formaten. Sie lassen sich zwar auf das Gerät kopieren, aber nur schwer als bewusst gestaltetes Hörerlebnis vorbereiten.

Bei einem Gerät ohne Display bekommt die Reihenfolge der Dateien eine besondere Bedeutung. Was auf einem Smartphone jederzeit sichtbar und auswählbar ist, muss hier bereits vor der Nutzung sinnvoll organisiert werden.

Das Problem war deshalb nicht der Audioplayer selbst, sondern die fehlende Verbindung zwischen lokaler Sammlung, gewünschter Situation und reduziertem Gerät.

Dieselben Inhalte, eine andere Reihenfolge

Eine Playlist für ruhiges Schwimmen braucht einen anderen Rhythmus als eine intensive Trainingseinheit. An manchen Tagen steht Musik im Vordergrund, an anderen ein Podcast oder ein Hörbuch.

Der MP3 Manager ermöglicht, dieselben lokalen Inhalte in unterschiedlichen Zusammenstellungen zu verwenden. Dateien müssen nicht immer wieder neu sortiert oder kopiert werden. Stattdessen entstehen situationsbezogene Playlists, die gezielt auf das Gerät übertragen werden.

So wird aus einer starren Dateisammlung ein flexibler persönlicher Audiobestand.

Bekannte Muster statt neuer Bedienlogik

Für die Gestaltung habe ich mich an vertrauten Prinzipien aus iPod Classic, Apple Music und Spotify orientiert.

Nicht, um diese Produkte zu kopieren, sondern weil Nutzer bereits mentale Modelle für Bibliotheken, Playlists, Reihenfolgen und Übertragung besitzen.

Das Werkzeug sollte nicht durch eine besonders originelle Bedienung auffallen. Es sollte verständlich sein, wenige klare Entscheidungen verlangen und die Vorbereitung auf das Schwimmen möglichst leicht machen.

Komplexität an den richtigen Ort verschieben

Der OpenSwim funktioniert gerade deshalb gut, weil er während der Nutzung sehr einfach bleibt. Ein Display, komplexe Navigation oder zusätzliche Menüs würden das Produkt im Wasser nicht automatisch verbessern.

Die sinnvollere Lösung ist ein ergänzendes Werkzeug. Planung, Organisation und Kontrolle finden auf dem Computer statt. Das Abspielgerät bleibt reduziert.

Diese Trennung wurde zur wichtigsten Erkenntnis des Projekts: Nicht jedes Produkt muss alle Aufgaben selbst übernehmen. Manchmal entsteht die bessere Erfahrung durch ein bewusst gestaltetes Zusammenspiel mehrerer einfacher Komponenten.

Ein Schlagwort braucht eine Richtung

Mit dem starken öffentlichen Interesse an generativer KI entstand auch in der Verwaltung schnell der Wunsch, „etwas mit KI“ zu machen.

Die Diskussion begann häufig bei Werkzeugen und Möglichkeiten. Weniger klar war, welche konkreten Aufgaben tatsächlich geeignet sind, welchen Nutzen eine Lösung stiften könnte und welche organisatorischen, rechtlichen oder technischen Voraussetzungen erfüllt sein müssen.

Der Ausgangspunkt musste deshalb nicht die Technologie sein, sondern die tägliche Arbeit in der Verwaltung.

Die richtigen Perspektiven zusammenbringen

Ich initiierte eine kleine interdisziplinäre Arbeitsgruppe mit Kompetenzen aus Prozessmanagement, Datenschutz, Projektmanagement und Technik.

Ich hatte keine formale Leitungsfunktion. Wichtig war deshalb, einen Rahmen zu schaffen, in dem Zusammenarbeit freiwillig, verbindlich und sichtbar werden konnte.

Wir trafen uns wöchentlich, dokumentierten Entscheidungen und offene Fragen und arbeiteten schrittweise an konkreten Ergebnissen. Dadurch wurde aus einem allgemeinen Interessenthema ein belastbarer Arbeitszusammenhang.

Praxis mit wissenschaftlicher Perspektive verbinden

Die Universität Rostock kam als wissenschaftlicher Partner hinzu. Im zweiwöchigen Rhythmus tauschten wir uns zu technischen Möglichkeiten, Forschungsständen und konkreten Anwendungsideen aus.

Diese Verbindung war wertvoll, weil sie zwei Blickrichtungen zusammenbrachte: die tatsächlichen Bedingungen in Verwaltung und Organisation sowie die technische und wissenschaftliche Einordnung neuer Entwicklungen.

Der Partner sollte nicht die Verantwortung für Produktentscheidungen übernehmen. Die Zusammenarbeit half uns, Annahmen zu prüfen und Themen fundierter zu bewerten.

Nicht jede Aufgabe braucht KI

Ein zentrales Problem war die Identifikation geeigneter Anwendungsfälle. Beschäftigte kennen ihre tägliche Arbeit am besten, verfügen aber nicht automatisch über ein klares Bild davon, welche Aufgaben sich für KI eignen.

Deshalb sah das Konzept eine kurze Sensibilisierung vor. Geeignet können beispielsweise wiederkehrende Aufgaben, klar beschreibbare Regeln, große Informationsmengen, Mustererkennung oder manuelle Übertragungs- und Prüfprozesse sein.

Ebenso wichtig ist die Gegenfrage: Wo wäre KI unnötig, unverhältnismäßig oder riskant?

KIBET: Ideen messbar und vergleichbar machen

KIBET steht für KI-Bewertungstool. Die Plattform sollte Mitarbeitende schrittweise durch die Beschreibung einer Aufgabe führen.

Erfasst werden unter anderem Prozess, Tätigkeit, Zeitaufwand, Häufigkeit und Anzahl der beteiligten Personen. Daraus kann eine erste Einschätzung zur möglichen zeitlichen und wirtschaftlichen Entlastung entstehen.

Weitere Faktoren ergänzen das Bild: Eignung für KI, Qualität und Verfügbarkeit von Daten, Risiken, Datenschutz, technische Machbarkeit, Integrationsaufwand, laufende Kosten und mögliche Auswirkungen auf die Organisation.

Ziel war keine scheinbar objektive Punktzahl. Ziel war ein gemeinsames, transparentes Bewertungsmodell.

Von einer Idee zu einer verantwortbaren Entscheidung

Die vorgeschlagenen Anwendungsfälle sollten nach nachvollziehbaren Kriterien sortiert werden. Fachliche und technische Prüfer könnten die stärksten Ideen vertiefen, Risiken ergänzen und realistische Aufwände einschätzen.

Das Management würde dadurch nicht nur eine Liste attraktiver KI-Ideen erhalten, sondern eine begründete Empfehlung: Welcher Nutzen ist zu erwarten? Welche Investition ist nötig? Wo liegt ein möglicher Break-even? Welche nicht-monetären Vorteile entstehen etwa durch demografischen Wandel oder fehlende Fachkräfte?

KIBET wurde als Click-Dummy und Präsentation ausgearbeitet, aber nicht implementiert. Das ist Teil der Geschichte. Gute Produktarbeit kann Entscheidungen vorbereiten und Voraussetzungen schaffen. Sie kann jedoch organisatorische Priorität, Budget und politische Unterstützung nicht ersetzen.

How it started

FamCook stands for Family Cooking. It began with a seemingly simple question: What should we cook today?

In our family with four children between nine and fifteen, that question is surprisingly difficult. One person dislikes mushrooms, another likes spicy food, one child prefers familiar dishes, someone cannot tolerate certain ingredients, and on some days there simply isn’t much time.

Most of the time, my wife had to deal with that question. FamCook therefore started as a birthday present for her.

I jokingly asked ChatGPT whether it could help me build a small app. Since I cannot code myself, I did not expect a particularly practical answer. Instead, the answer was essentially: Yes, we can try. So we started.

The original scope was small. FamCook was simply meant to make the daily decision a little easier.

Most recipe platforms answer: What could I cook? FamCook was meant to answer a different question: What works today for exactly the people eating together — and for their current situation?

Profiles that grow with use

Each family member starts with a simple profile. Preferred and disliked ingredients, spice tolerance, dietary preferences, intolerances and other relevant information can be recorded there.

These details are not permanent labels. Profiles can evolve through use. Which recipes are viewed, saved, cooked, modified or rejected? Which ingredients work in certain combinations? Which preferences change over time?

People do not necessarily need to use FamCook themselves. Children or older family members can initially be managed by someone else and take over their profile later. The system should reflect real family life rather than requiring every person to maintain an active user account.

Behind this is a principle that increasingly reaches beyond FamCook into my broader work: people should not have to learn the logic of software. Software should adapt to people as far as possible.

What the product already knows should not be asked again. Information should be requested when it becomes relevant to the next decision.

Finding the right overlap for this group

The whole family does not always eat together. Sometimes one parent cooks only for the children, sometimes two people eat together, and sometimes guests join.

That is why the people eating together are selected before the search begins. FamCook does not simply compare every profile in the family, but precisely the people involved in the current situation.

The goal is not to find a dish that everyone likes equally according to a mathematical score. The product should identify the best realistic common ground while also showing where a dish can be adapted.

Personalisation therefore becomes a group problem: different needs are not reduced to an abstract average, but related to one another in the context of the actual situation.

From a small app to a product system

FamCook’s original scope was modest. Then new ideas appeared. With every new capability, another dependency became visible.

Recipes could not only be discovered, but imported, stored or developed with AI. Weekly planning, shopping lists and tasks followed.

Then it became clear that recipes alone were not enough. FamCook also needs to understand ingredients, how they relate to one another, what happens to them during cooking and which equipment is required. Context matters as well: a camping holiday, a quick meal after sports or a weekend together all create different requirements.

At some point, the main challenge was no longer adding visible features. The more important questions moved beneath the interface: How do we keep data consistent? Which information is the domain truth? What happens when multiple features depend on the same information? How does a change affect other parts of the product? How do we prevent new capabilities from quietly breaking existing logic?

Organic development gradually became a systematic development process. Project planning and regular reviews were introduced. A Single Source of Truth became necessary. Data models and relationships became more important than individual screens.

Complexity belongs to the system

This evolution has also changed the way I define Product Design. I am not only designing interfaces. I increasingly design the behaviour of a system: What does it know? When does it ask? Which decisions does the person need to make? Which can the product make itself? Which consequences need to remain visible? Which complexity can disappear completely behind the interface?

Many digital products first require people to learn how the system thinks: what information it expects, where functions are located and which sequence has been designed for a task.

FamCook increasingly leads me to the opposite question: How much of that work can the product take on itself?

If the system already knows who is eating together, which preferences exist and which decisions have previously been made, it should use that knowledge. If one change affects another part of the product, the system should understand that relationship.

The system may become more complex internally if that makes the moment of use simpler.

Developing with AI without giving up responsibility

I am a Product Designer, but not a classically trained software developer. I therefore develop FamCook together with AI systems.

At the beginning, it was ChatGPT and me. As the product grew, a second AI system joined the process. Today, two AI systems support me with different tasks, including research, product architecture, technical analysis and implementation.

This allows me as a single Product Designer to reach much further into actual product development than would previously have been possible. Current operating costs are around €100 per month. Most of the work happens in my spare time.

But greater technical capability does not mean less responsibility. Quite the opposite. As the product became more complex, rules, reviews and verifiable decisions became increasingly important.

Product knowledge is one example. AI may recognise that two differently named ingredients in different languages probably refer to the same food, or infer that an unfamiliar term belongs to a particular category. But a plausible interpretation is not yet a fact.

This led to a central principle: AI may research and interpret. Verifiable rules determine what becomes accepted knowledge. Confirmed findings are stored so that the same question does not need to be researched again the next time it appears.

Understand first. Then design.

As the product grew more complex, a central design question shifted for me as well. I no longer start by asking how a feature can be made easier to operate. I start by asking why the person needs to operate it at all.

If FamCook already knows who is eating together, which preferences and intolerances exist, what was decided before and in which context a task takes place, that knowledge should take work away — instead of producing new forms, settings and questions.

This is not about hiding decisions from people. Where consequences matter or remain ambiguous, the product has to make them visible and ask. What follows unambiguously from existing knowledge and context is something the system can take on.

For me, Product Design therefore shifts from designing individual interfaces to designing how a product behaves: What does it know? When does it have to ask? What can it take on itself? What has to stay visible? And which interaction can disappear entirely? Only then do I decide what interface it actually needs.

Feedback needs a place and a context

I am currently using FamCook myself. The next step is a controlled beta test with around 25 to 50 people from our circle of friends and acquaintances.

The goal is not merely to test whether individual features work. The full flows will be tested: from profiles and recipe discovery through planning and shopping to cooking.

Feedback should not be scattered across messages, emails or things people try to remember later. Observations can be reported directly within the product together with a screenshot and usage context.

AI can cluster feedback, combine similar issues and highlight patterns or contradictions. Actual usage flows can simultaneously reveal where people struggle. Both can support product decisions. Neither replaces them.

Swimming with music – but without streaming

The starting point was the Shokz OpenSwim. The headset uses bone conduction and can be worn while swimming.

Because wireless streaming connections do not work reliably under water, audio files are stored locally on the device. That is technically sensible and pleasantly reduced during the swim itself.

The real difficulty begins before training: Which files are on the device, in what order will they play, and how can the content be adapted to different situations?

Playback was simple. Organisation was not.

Music, podcasts and audiobooks are stored on the computer in different folders and formats. They can be copied to the device, but it is difficult to prepare them as a consciously designed listening experience.

On a device without a display, the order of the files becomes particularly important. What is visible and selectable at any time on a smartphone has to be organised sensibly before use here.

The problem was therefore not the audio player itself, but the missing connection between the local collection, the intended situation and the reduced device.

The same content, a different sequence

A playlist for relaxed swimming needs a different rhythm from an intense training session. On some days, music is the focus; on others, it may be a podcast or an audiobook.

The MP3 Manager allows the same local content to be used in different combinations. Files do not have to be sorted and copied again and again. Instead, situational playlists can be created and transferred to the device.

A static file collection becomes a flexible personal audio library.

Familiar patterns instead of a new interaction language

For the design, I used familiar principles from the iPod Classic, Apple Music and Spotify as references.

The aim was not to copy these products, but to build on mental models that users already have for libraries, playlists, sequence and transfer.

The tool should not stand out through particularly original interaction. It should be easy to understand, require only a few clear decisions and make preparation for swimming as simple as possible.

Move complexity to the right place

The OpenSwim works well precisely because it remains very simple during use. A display, complex navigation or additional menus would not automatically improve the product in the water.

The more useful solution is a companion tool. Planning, organisation and control happen on the computer. The playback device remains reduced.

This separation became the most important insight of the project: Not every product has to perform every task itself. Sometimes the better experience emerges from a deliberately designed interaction between several simple components.

A buzzword needs direction

As public interest in generative AI increased, public administration also quickly developed a desire to “do something with AI”.

The discussion often began with tools and possibilities. Less clear was which specific tasks were genuinely suitable, what value a solution might create and which organisational, legal or technical conditions would have to be met.

The starting point therefore had to be everyday administrative work, not the technology.

Bring the right perspectives together

I initiated a small interdisciplinary working group with expertise from process management, data protection, project management and technology.

I did not have a formal leadership role. It was therefore important to create a framework in which collaboration could be voluntary, reliable and visible.

We met weekly, documented decisions and open questions, and worked step by step towards concrete outcomes. That turned a broad topic of interest into a dependable working context.

Connect practice with a scientific perspective

The University of Rostock joined as a scientific partner. Every two weeks, we discussed technical possibilities, current research and specific application ideas.

This connection was valuable because it brought together two perspectives: the real conditions within administration and organisations, and the technical and scientific assessment of new developments.

The partner was not meant to take responsibility for product decisions. The collaboration helped us test assumptions and assess topics more rigorously.

Not every task needs AI

A central problem was identifying suitable use cases. Employees know their daily work best, but they do not automatically have a clear picture of which tasks may be suitable for AI.

The concept therefore included a short introduction. Suitable areas might include recurring tasks, clearly describable rules, large information volumes, pattern recognition or manual transfer and checking processes.

The opposite question is equally important: Where would AI be unnecessary, disproportionate or risky?

KIBET: Make ideas measurable and comparable

KIBET stands for AI Assessment Tool. The platform was intended to guide employees step by step through the description of a task.

It would capture the process, activity, time required, frequency and number of people involved. From this, a first assessment of possible time savings and economic relief could be made.

Further factors would complete the picture: suitability for AI, quality and availability of data, risk, data protection, technical feasibility, integration effort, ongoing cost and possible organisational impact.

The aim was not to produce a supposedly objective score. The aim was a shared, transparent assessment model.

From an idea to a responsible decision

Suggested use cases were to be sorted according to transparent criteria. Subject-matter and technical reviewers could deepen the strongest ideas, add risks and estimate realistic effort.

Management would then receive not merely a list of attractive AI ideas, but a reasoned recommendation: What benefit can be expected? What investment is required? Where might break-even lie? Which non-financial benefits arise, for example, from demographic change or a shortage of skilled workers?

KIBET was developed as a clickable prototype and presentation, but it was not implemented. That is part of the story. Good product work can prepare decisions and create the necessary conditions. It cannot replace organisational priority, budget or political support.

Hvordan det begyndte

FamCook står for Family Cooking. Udgangspunktet var et tilsyneladende enkelt spørgsmål: Hvad skal vi spise i dag?

I vores familie med fire børn mellem ni og femten år er det overraskende svært at besvare. Én kan ikke lide svampe, en anden vil gerne have stærk mad, et barn foretrækker velkendte retter, nogen tåler ikke bestemte ingredienser, og nogle dage er der ganske enkelt ikke ret meget tid.

Det var oftest min kone, der skulle håndtere spørgsmålet. FamCook begyndte derfor som en fødselsdagsgave til hende.

Jeg spurgte ChatGPT lidt for sjov, om det kunne hjælpe mig med at bygge en lille app. Da jeg ikke selv kan programmere, forventede jeg ikke et særligt praktisk svar. I stedet var svaret grundlæggende: Ja, det kan vi prøve. Så vi gik i gang.

Det oprindelige scope var lille. FamCook skulle ganske enkelt gøre den daglige beslutning lidt lettere.

De fleste opskriftsplatforme besvarer: Hvad kunne jeg lave? FamCook skulle besvare et andet spørgsmål: Hvad passer i dag til præcis de mennesker, der skal spise sammen — og til deres aktuelle situation?

Profiler, der udvikler sig med brugen

Hvert familiemedlem begynder med en enkel profil. Her registreres foretrukne og fravalgte ingredienser, tolerance for stærk mad, kostvaner, intolerancer og andre relevante oplysninger.

Disse oplysninger er ikke permanente etiketter. Profilerne kan udvikle sig gennem brugen. Hvilke opskrifter bliver set, gemt, tilberedt, ændret eller fravalgt? Hvilke ingredienser fungerer i bestemte kombinationer? Hvilke præferencer ændrer sig over tid?

Det er heller ikke nødvendigt, at alle selv bruger FamCook. Børn eller ældre familiemedlemmer kan i første omgang administreres af andre og senere overtage deres egen profil. Systemet skal afspejle familielivet, som det faktisk fungerer, i stedet for at kræve en separat aktiv brugerkonto til hver person.

Bag dette ligger et princip, der i stigende grad rækker ud over FamCook og ind i mit øvrige arbejde: mennesker bør ikke skulle lære softwarens logik. Softwaren bør så vidt muligt tilpasse sig mennesket.

Det, produktet allerede ved, bør det ikke spørge om igen. Information bør efterspørges, når den bliver relevant for den næste beslutning.

Det rigtige overlap for denne gruppe

Det er ikke altid hele familien, der spiser sammen. Nogle gange laver en forælder kun mad til børnene, nogle gange spiser to personer sammen, og nogle gange kommer der gæster.

Derfor vælger man, hvem der skal spise sammen, før søgningen begynder. FamCook sammenligner ikke automatisk alle profiler, men præcis de mennesker, der indgår i den aktuelle situation.

Målet er ikke at finde en ret, som matematisk set passer lige godt til alle. Produktet skal finde det bedste realistiske fælles område og samtidig vise, hvor en ret kan tilpasses.

Personalisering bliver dermed et gruppeproblem: forskellige behov reduceres ikke til et abstrakt gennemsnit, men sættes i relation til hinanden i den faktiske situation.

Fra en lille app til et produktsystem

FamCooks oprindelige scope var beskedent. Så kom der nye idéer. Med hver ny funktion blev endnu en afhængighed synlig.

Opskrifter kunne ikke kun findes, men også importeres, gemmes eller udvikles med AI. Ugeplanlægning, indkøbslister og opgaver fulgte.

Derefter blev det tydeligt, at opskrifter alene ikke var nok. FamCook skal også forstå ingredienser, hvordan de hænger sammen, hvad der sker med dem under tilberedningen, og hvilket udstyr der er nødvendigt. Kontekst spiller også en rolle: en campingferie, et hurtigt måltid efter sport eller en weekend sammen stiller forskellige krav.

På et tidspunkt var den vigtigste udfordring derfor ikke længere at tilføje synlige funktioner. De vigtigere spørgsmål lå under brugerfladen: Hvordan holder vi data konsistente? Hvilken information er den faglige sandhed? Hvad sker der, når flere funktioner afhænger af den samme information? Hvordan påvirker en ændring andre dele af produktet? Hvordan undgår vi, at nye funktioner stille og roligt bryder eksisterende logik?

Organisk udvikling blev gradvist til en systematisk udviklingsproces. Projektplanlægning og regelmæssige reviews kom til. En Single Source of Truth blev nødvendig. Datamodeller og relationer blev vigtigere end enkelte skærmbilleder.

Kompleksitet hører hjemme i systemet

Denne udvikling har også ændret min måde at definere Product Design på. Jeg designer ikke kun brugerflader. Jeg designer i stigende grad et systems adfærd: Hvad ved det? Hvornår spørger det? Hvilke beslutninger skal mennesket træffe? Hvilke kan produktet selv tage? Hvilke konsekvenser skal forblive synlige? Hvilken kompleksitet kan forsvinde helt bag brugerfladen?

Mange digitale produkter kræver først, at mennesker lærer, hvordan systemet tænker: hvilke oplysninger det forventer, hvor funktionerne findes, og hvilken rækkefølge en opgave er designet til.

FamCook fører mig i stigende grad til det modsatte spørgsmål: Hvor meget af dette arbejde kan produktet selv overtage?

Hvis systemet allerede ved, hvem der spiser sammen, hvilke præferencer der findes, og hvilke beslutninger der tidligere er truffet, bør det bruge denne viden. Hvis en ændring påvirker en anden del af produktet, bør systemet forstå relationen.

Systemet må gerne blive mere komplekst internt, hvis det gør selve brugssituationen enklere.

At udvikle med AI uden at give ansvaret fra sig

Jeg er Product Designer, men ikke klassisk uddannet softwareudvikler. Derfor udvikler jeg FamCook sammen med AI-systemer.

I begyndelsen var det ChatGPT og mig. Efterhånden som produktet voksede, kom et andet AI-system til. I dag understøtter to AI-systemer mig med forskellige opgaver, blandt andet research, produktarkitektur, teknisk analyse og implementering.

Det betyder, at jeg som én Product Designer kan nå langt længere ind i reel produktudvikling, end det tidligere ville have været muligt. De aktuelle driftsomkostninger ligger på omkring 100 euro om måneden. Det meste af arbejdet foregår i min fritid.

Men større tekniske muligheder betyder ikke mindre ansvar. Tværtimod. Efterhånden som produktet blev mere komplekst, blev regler, reviews og verificerbare beslutninger stadig vigtigere.

Produktviden er et eksempel. AI kan genkende, at to ingredienser med forskellige navne på forskellige sprog sandsynligvis er den samme fødevare, eller vurdere, at et ukendt begreb tilhører en bestemt kategori. Men en plausibel fortolkning er endnu ikke et faktum.

Det førte til et centralt princip: AI må researche og fortolke. Verificerbare regler afgør, hvad der accepteres som viden. Bekræftede resultater gemmes, så det samme spørgsmål ikke behøver at blive undersøgt igen næste gang.

Forstå først. Design derefter.

Efterhånden som produktet blev mere komplekst, ændrede et centralt designspørgsmål sig også for mig. Jeg begynder ikke længere med at spørge, hvordan en funktion bliver lettere at betjene. Jeg begynder med at spørge, hvorfor mennesket overhovedet skal betjene den.

Når FamCook allerede ved, hvem der spiser sammen, hvilke præferencer og intolerancer der findes, hvad der tidligere er besluttet, og i hvilken sammenhæng en opgave foregår, bør den viden tage arbejde fra brugeren — ikke skabe nye formularer, indstillinger og spørgsmål.

Det handler ikke om at skjule beslutninger for mennesker. Hvor konsekvenserne er væsentlige eller flertydige, skal produktet gøre dem synlige og spørge. Det, der utvetydigt følger af eksisterende viden og kontekst, kan systemet selv tage sig af.

For mig flytter Product Design sig dermed fra at forme enkelte brugerflader til at forme et produkts adfærd: Hvad ved det? Hvornår skal det spørge? Hvad kan det selv overtage? Hvad skal forblive synligt? Og hvilken betjening kan forsvinde helt? Først derefter beslutter jeg, hvilken brugerflade der overhovedet er brug for.

Feedback har brug for et sted og en kontekst

Jeg bruger i øjeblikket selv FamCook. Næste skridt er en kontrolleret betatest med omkring 25 til 50 personer fra vores venne- og bekendtskabskreds.

Målet er ikke kun at teste, om enkelte funktioner virker. Hele forløb skal testes: fra profiler og opskriftssøgning over planlægning og indkøb til selve madlavningen.

Feedback skal ikke samles i spredte beskeder, e-mails eller ting, man forsøger at huske bagefter. Observationer kan rapporteres direkte i produktet sammen med et screenshot og brugskontekst.

AI kan gruppere feedback, samle lignende problemer og gøre mønstre eller modstridende observationer synlige. De faktiske brugerforløb kan samtidig vise, hvor mennesker har problemer. Begge dele kan understøtte produktbeslutninger. Ingen af delene erstatter dem.

Svømning med musik – men uden streaming

Udgangspunktet var Shokz OpenSwim. Headsettet bruger bone conduction og kan bæres under svømning.

Da trådløse streamingforbindelser ikke fungerer pålideligt under vand, lagres lydfiler lokalt på enheden. Det er teknisk fornuftigt og behageligt enkelt under selve svømningen.

Den egentlige udfordring begynder før træningen: Hvilke filer ligger på enheden, i hvilken rækkefølge bliver de afspillet, og hvordan kan indholdet tilpasses forskellige situationer?

Afspilning var enkel. Organisering var ikke.

Musik, podcasts og lydbøger ligger på computeren i forskellige mapper og formater. De kan kopieres til enheden, men det er svært at forberede dem som en bevidst designet lytteoplevelse.

På en enhed uden skærm får filernes rækkefølge en særlig betydning. Det, der på en smartphone til enhver tid er synligt og kan vælges, skal her organiseres på forhånd.

Problemet var derfor ikke selve lydafspilleren, men den manglende forbindelse mellem den lokale samling, den ønskede situation og den reducerede enhed.

Det samme indhold, en anden rækkefølge

En playliste til rolig svømning har brug for en anden rytme end en intensiv træningssession. Nogle dage er musikken i centrum, andre dage en podcast eller en lydbog.

MP3 Manager gør det muligt at bruge det samme lokale indhold i forskellige kombinationer. Filerne behøver ikke sorteres og kopieres igen og igen. I stedet oprettes situationsbestemte playlister, som overføres målrettet til enheden.

En statisk filsamling bliver til et fleksibelt personligt lydbibliotek.

Velkendte mønstre frem for et nyt interaktionssprog

I designet brugte jeg velkendte principper fra iPod Classic, Apple Music og Spotify som reference.

Målet var ikke at kopiere produkterne, men at bygge videre på mentale modeller, som brugerne allerede har for biblioteker, playlister, rækkefølge og overførsel.

Værktøjet skulle ikke skille sig ud gennem en særlig original betjening. Det skulle være let at forstå, kræve få tydelige beslutninger og gøre forberedelsen til svømningen så enkel som muligt.

Flyt kompleksiteten til det rigtige sted

OpenSwim fungerer netop godt, fordi enheden forbliver meget enkel under brug. En skærm, kompleks navigation eller flere menuer ville ikke automatisk forbedre produktet i vandet.

Den mere nyttige løsning er et ledsagende værktøj. Planlægning, organisering og kontrol sker på computeren. Afspilleren forbliver reduceret.

Denne opdeling blev projektets vigtigste indsigt: Ikke ethvert produkt behøver selv at udføre alle opgaver. Nogle gange opstår den bedre oplevelse gennem et bevidst designet samspil mellem flere enkle komponenter.

Et buzzword har brug for retning

Da den offentlige interesse for generativ AI voksede, opstod der også hurtigt et ønske i den offentlige administration om at “gøre noget med AI”.

Diskussionen begyndte ofte med værktøjer og muligheder. Mindre tydeligt var det, hvilke konkrete opgaver der faktisk var egnede, hvilken værdi en løsning kunne skabe, og hvilke organisatoriske, juridiske eller tekniske betingelser der skulle være opfyldt.

Udgangspunktet måtte derfor være det daglige administrative arbejde, ikke teknologien.

Saml de rigtige perspektiver

Jeg tog initiativ til en mindre tværfaglig arbejdsgruppe med kompetencer inden for procesledelse, databeskyttelse, projektledelse og teknologi.

Jeg havde ingen formel lederrolle. Derfor var det vigtigt at skabe en ramme, hvor samarbejdet kunne være frivilligt, forpligtende og synligt.

Vi mødtes hver uge, dokumenterede beslutninger og åbne spørgsmål og arbejdede trin for trin mod konkrete resultater. Dermed blev et bredt interesseområde til en stabil arbejdssammenhæng.

Forbind praksis med et videnskabeligt perspektiv

Universitetet i Rostock kom med som videnskabelig partner. Hver anden uge drøftede vi tekniske muligheder, den aktuelle forskning og konkrete anvendelsesidéer.

Forbindelsen var værdifuld, fordi den samlede to perspektiver: de faktiske vilkår i administration og organisationer samt den tekniske og videnskabelige vurdering af nye udviklinger.

Partneren skulle ikke overtage ansvaret for produktbeslutninger. Samarbejdet hjalp os med at afprøve antagelser og vurdere emner mere grundigt.

Ikke alle opgaver har brug for AI

Et centralt problem var at identificere egnede anvendelsesområder. Medarbejderne kender deres daglige arbejde bedst, men har ikke automatisk et klart billede af, hvilke opgaver der kan egne sig til AI.

Konceptet omfattede derfor en kort introduktion. Egnede områder kan eksempelvis være tilbagevendende opgaver, klart beskrevne regler, store informationsmængder, mønstergenkendelse eller manuelle overførsels- og kontrolprocesser.

Det modsatte spørgsmål er lige så vigtigt: Hvor ville AI være unødvendig, uforholdsmæssig eller risikabel?

KIBET: Gør idéer målbare og sammenlignelige

KIBET står for AI-vurderingsværktøj. Platformen skulle føre medarbejdere trin for trin gennem beskrivelsen af en opgave.

Den skulle registrere proces, aktivitet, tidsforbrug, hyppighed og antal involverede personer. Ud fra det kunne der laves en første vurdering af mulige tidsbesparelser og økonomisk aflastning.

Flere faktorer skulle fuldende billedet: egnethed til AI, kvalitet og tilgængelighed af data, risici, databeskyttelse, teknisk gennemførlighed, integrationsindsats, løbende omkostninger og mulig organisatorisk effekt.

Målet var ikke en tilsyneladende objektiv score. Målet var en fælles og gennemsigtig vurderingsmodel.

Fra idé til ansvarlig beslutning

Foreslåede anvendelsesområder skulle sorteres efter gennemskuelige kriterier. Faglige og tekniske vurderere kunne uddybe de stærkeste idéer, tilføje risici og anslå realistiske indsatser.

Ledelsen ville dermed ikke blot få en liste over attraktive AI-idéer, men en begrundet anbefaling: Hvilken nytte kan forventes? Hvilken investering er nødvendig? Hvor kan break-even ligge? Hvilke ikke-økonomiske fordele kan opstå, for eksempel i forbindelse med demografiske forandringer eller mangel på arbejdskraft?

KIBET blev udviklet som klikbar prototype og præsentation, men ikke implementeret. Det er en del af historien. Godt produktarbejde kan forberede beslutninger og skabe forudsætninger. Det kan ikke erstatte organisatorisk prioritet, budget eller politisk opbakning.