{Dies ist der 9. Teil einer Miniserie. Ich empfehle am Anfang zu beginnen und sich dann Post für Post nach vorne zu hangeln. Hier geht´s zum Nr. (1)- Post }
Wenn wir tatsächlich einen Nutzomaten bauen wollten, dann könnte er so oder so oder so aussehen (sagt die KI):
Variante A: Entscheidungsassistent
Nutzer vergleicht konkrete Alternativen.
Beispiel:
- Soll ich Produkt A oder B kaufen?
- Soll ich kündigen oder bleiben?
- Soll ich dieses Feature nutzen?
Die App zeigt:
- Gesamtvergleich
- Treiber der Entscheidung
- dominante Nutzenarten
- versteckte Kosten
- Zukunftseffekte
Variante B: persönliches Nutzenprofil
Die App lernt über Zeit, wie der Nutzer typischerweise entscheidet. Dann wird aus der App kein Taschenrechner, sondern ein Nutzenprofil-System:
- Welche Nutzenarten dominieren bei dir?
- Wo überschätzt du Ergebnisnutzen?
- Wo unterschätzt du Transaktionskosten?
- Wo priorisierst du Identität vor Effizienz?
Variante C: B2B/Marktmodell
Unternehmen nutzen die App, um Zielgruppen-Nutzenkalküle zu modellieren. Dann musst du nicht nur Individuen, sondern Cluster modellieren:
- Nutzersegmente
- Situationscluster
- alternative Nutzenarchitekturen
****
Wir wollen sofort und schnell loslegen:
Also erstmal ein MVP als persönliches Nutzenprofil, ok?
****
Schritt 1: Schreibe ein Nutzomat-Datenmodell
Enthalten sein müssen:
- Definition jeder Nutzenart
- Definition jeder Kostenart
- Unterschied zwischen Person, Situation, Alternative
- Regeln der Aggregation
- Regeln der Gewichtung
- Regeln für Unsicherheit
Schritt 2: Erstelle einen Fragenkatalog.
Pro Dimension 5–10 gute Items.
Also etwa:
- Ergebnisnutzen: 8 Fragen
- Prozessnutzen: 8 Fragen
- Persönlichkeitsnutzen: 8 Fragen
- Prosumtionsnutzen: 8 Fragen
- Inputkosten: 5 Fragen
- Transaktionskosten: 8 Fragen
Nicht sofort 200 Fragen. Sonst flieht dir jeder Nutzer schneller als ein Praktikant vor dem Wort „Validierungsworkshop“.
Schritt 3: Definiere ein Scoring-Modell.
- Likert-Skalen
- einfache Gewichtungen
- situative Multiplikatoren
- Vergleichsvisualisierung
Schritt 4: Baue einen Low-Fidelity-Prototyp. Kein Code am Anfang
- Figma
- Notion
- Airtable
- Spreadsheet-Prototyp
Ziel: Teste, ob Menschen ihre Nutzenkalküle überhaupt verständlich eingeben können.
Schritt 5: Mache 20–30 echte Entscheidungstests.
Lass Nutzer:
- reale Entscheidungen eingeben
- Prognose der App sehen
- tatsächliche Entscheidung dokumentieren
- später Zufriedenheit rückmelden
Dann lernst du:
- welche Items taugen
- welche Gewichte schlecht sind
- welche Dimensionen fehlen
Schritt 6: Definiere die Architektur
> Frontend
- Web-App zuerst
- mobile responsive
- Fokus auf Entscheidungsflows, nicht auf Dashboard-Spielerei
> Backend
- Nutzerprofil
- Situationsmodell
- Alternativenmodell
- Rechenengine
- Lernmodul
> Datenbank
> Tabellen oder Collections für:
- users
- situations
- alternatives
- ratings
- weights
- decisions
- outcomes
- learned_adjustments
> Rechenengine
Separat halten.
Nicht die Logik ins Frontend quetschen.
Die Engine sollte:
- Scores berechnen
- Gewichtungen anwenden
- Unsicherheit modellieren
- Erklärungen ausgeben (Sie muss sagen B ist vorne wegen hohem Prosumtionsnutzen, A verliert wegen hoher Transaktionskosten oder C passt besser zu deinem Identitätsprofil, aber schlechter zu deiner aktuellen Ressourcensituation
Schritt 6: So sollte das UX-seitig aussehen
Bildschirm 1
Welche Entscheidung willst du treffen?
Bildschirm 2
Welche Alternativen vergleichst du?
Bildschirm 3
In welcher Situation befindest du dich?
Bildschirm 4
Kurze Nutzen- und Kostenbewertung pro Alternative
Bildschirm 5
Gewichtungsabgleich:
- Was ist dir gerade besonders wichtig?
- Wovor willst du dich eher schützen?
- Geht es eher um kurzfristigen Erfolg oder langfristigen Aufbau?
Bildschirm 6
Ergebnis:
- Transaktionswert pro Alternative
- Treiberanalyse
- Sensitivitätsanalyse
- Erklärung in Alltagssprache
=============
ABER ACHTUNG: Alles wissenschaftlich und praktisch halten
Wenn du willst, dass das mehr als ein schönes Denkspiel wird, brauchst du drei Validierungsebenen:
Konstruktvalidität: Messen deine Fragen wirklich Ergebnis-, Prozess-, Persönlichkeits- und Prosumtionsnutzen?
Prognosevalidität: Sagt dein Modell Entscheidungen besser voraus als Bauchgefühl oder einfache Kosten-Nutzen-Listen?
Zufriedenheitsvalidität: Führt die vom Modell empfohlene Alternative später häufiger zu höherer Zufriedenheit?
=============
Und nochmal ACHTUNG!
Größte Produktgefahren:
Erste Gefahr: Übervereinfachung.
Zweite Gefahr: Überkomplexität.
Dritte Gefahr: Menschen denken nicht in theoretischen
Vierte Gefahr: Keine Lernebene.
=============
Also (sagt die KI): Husch, husch. Leg los!
In dieser praktischen Reihenfolge:
- Das theoretische Modell in ein sauberes Produktmodell übersetzen.
Nicht philosophisch, sondern als Daten- und Entscheidungslogik. - Jede Nutzenart operationalisieren. Also in beobachtbare, beantwortbare Items verwandeln.
- Person-, Situations- und Alternativenebene getrennt modellieren.
- Ein erstes Gewichtungs- und Aggregationsmodell definieren.
- Mit realen Testentscheidungen pilotieren.
- Aus Nutzerdaten lernen, statt alles a priori festzuschreiben.
- Erklärbare Outputs bauen, nicht nur Scores.
Und dann sagte sie noch: Baue nicht sofort die große KI-App, die „alle menschlichen Entscheidungen versteht“. Das endet oft in digitalem Größenwahn mit hübschem UI.
Also bauen wir zuerst einen sehr fokussierten MVP, z.B. für:
- Kaufentscheidungen für höherpreisige Produkte
- Karriereentscheidungen
- Marken-/Angebotsvergleich
- Entscheidungsunterstützung im Coaching
Wer ist dabei?