Der lange Weg zum Nutzomaten (15) – Finale: So wird´s was. Oder anders. Hauptsache er wird.

{Dies ist der 15. und letzte Teil der Miniserie zum Bau der Nutzomat-App. Ich empfehle am Anfang zu beginnen und sich dann Post für Post nach vorne zu hangeln. Hier geht´s zum Nr. (1)- Post }

Produktartefakt · Nutzomat Decision Engine

Ein Bauplan für eine App, die individuelle Nutzenkalküle sichtbar macht

Dieses Artefakt fasst die Arbeitsschritte zur Entwicklung der Nutzomat-App zusammen: vom Nutzenmodell über UX, Produktlogik, technische Architektur und Roadmap bis zur Validierung.

1. Zielbild

Die Nutzomat-App soll Entscheidungen nicht automatisieren, sondern sichtbar machen, warum eine Option für eine konkrete Person in einer konkreten Situation wertvoller wirkt als eine andere.

Ziel MVP Output
Entscheidungen klären 2–4 Alternativen vergleichen Ranking, Treiber, Confidence, Sensitivität

2. Nutzenmodell

Das Modell beruht auf einem subjektiven Transaktionswert. Bewertet wird nicht der objektive Wert einer Alternative, sondern ihr Wert für eine bestimmte Person in einer bestimmten Situation.

Transaktionswert(A) = Gesamtnutzen(A) − Gesamtkosten(A)

Gesamtnutzen = Ergebnisnutzen + Prozessnutzen + Persönlichkeitsnutzen + Prosumtionsnutzen

Gesamtkosten = Inputkosten + Transaktionskosten

Wichtig: TV = f(Person, Situation, Alternative)

Dimension Leitfrage Bedeutung
Ergebnisnutzen Was bringt mir das direkt? Zielerreichung, Problemlösung, unmittelbarer Gewinn.
Prozessnutzen Wie ist der Weg dorthin? Angenehmheit, Einfachheit, Erlebnisqualität, Reibungslosigkeit.
Persönlichkeitsnutzen Passt diese Option zu mir? Selbstbild, Identität, Stimmigkeit, Anerkennung, Integrität.
Prosumtionsnutzen / Zukunftswert Was baut das für später auf? Fähigkeiten, Kontakte, Reputation, Erfahrung, künftige Chancen.
Inputkosten Was muss ich direkt investieren? Geld, Zeit, Energie, Aufmerksamkeit, Verzicht.
Transaktionskosten Wie viel Reibung entsteht? Unsicherheit, Risiko, Suchaufwand, Koordination, mentale Last.

3. App-Konzept

Die App ist ein Entscheidungsassistent. Sie strukturiert Alternativen, persönliche Prioritäten und situative Faktoren, berechnet daraus ein Entscheidungsbild und erklärt die wichtigsten Treiber.

Was die App tut

  • Entscheidung und Alternativen erfassen
  • Situation und persönliche Prioritäten modellieren
  • Alternativen entlang von sechs Dimensionen bewerten
  • Transaktionswerte berechnen
  • Ergebnis erklären und später nachverfolgen

Was im MVP bewusst nicht enthalten ist

  • keine KI-Beratung
  • keine Teamentscheidungen
  • keine komplexen Dashboards
  • keine Blackbox-Empfehlung

4. Nutzerflow

Der Flow muss linear, ruhig und testbar sein. Ziel: Ergebnis in etwa 8–12 Minuten.

1. Entscheidung

2. Alternativen

3. Situation

4. Prioritäten

5. Bewertung

6. Ergebnis

7. Follow-up

5. UX und Screens

Die Oberfläche sollte sich wie ein ruhiger Denkraum anfühlen: klar, reduziert, mit sichtbarem Fortschritt und ohne visuelle Überladung.

Dashboard

[Logo]                         [Profil]

Treffe klarere Entscheidungen

Vergleiche Optionen entlang von Ergebnis,
Weg, Identität und Zukunft.

[ Neue Entscheidung starten ]

Letzte Entscheidungen
[ Jobwechsel 2026 · 3 Alternativen · Ergebnis vorhanden ]

Bewertung

Alternative B · Schritt 1 von 6

Was bringt dir diese Option direkt?

Wie stark bringt dich diese Option deinem Ziel näher?
[------●----] 8

Wie nützlich ist das Ergebnis?
[--------●--] 9

Wie wahrscheinlich ist es?
[-----●-----] 7

[ Zurück ]                      [ Weiter ]

Ergebnis

Dein Entscheidungsbild

Aktuell vorne: Alternative B
Begründung: starker Zukunftswert + hoher Identitätsfit

Ranking
1. B · 72 Punkte
2. A · 61 Punkte
3. C · 55 Punkte

Was treibt das Ergebnis?
• Zukunftswert ist entscheidend
• Identitätsfit macht den Unterschied
• Kosten sind nicht der Hauptfaktor

6. Technische Architektur

Bereich Empfehlung
Frontend Next.js
Sprache TypeScript
Datenbank PostgreSQL
Auth Supabase Auth oder Auth0
Analytics PostHog

Zentrale Datenobjekte

  • users
  • decisions
  • situations
  • user_priority_profiles
  • alternatives
  • ratings
  • computed_results
  • decision_outcomes
  • follow_ups

7. 6-Wochen-Roadmap

Woche Fokus Ergebnis
1 Modell & Scope Fragenkatalog, Scope, Demo-Cases
2 Figma & Tests Klickbarer Prototyp, erste Erkenntnisse
3 Backend DB, API, Seed-Daten
4 Frontend End-to-End-Eingabeflow
5 Compute & Ergebnis Ranking, Confidence, Treiber
6 Pilot Follow-up, QA, Deployment

8. Team

Rolle Verantwortung
Product & Model Lead Modelltreue, Scope, Fragenqualität, Testcases
Product Designer Flow, UI, Copy, Ergebnisdarstellung
Full-Stack Engineer DB, API, Frontend, Compute Engine, Deployment
UX Research optional Tests, Interviews, Auswertung

9. Nutzertests

Die ersten Tests sollen prüfen, ob Nutzer die Fragen verstehen, ob das Ergebnis plausibel wirkt und ob der Flow nicht zu lang ist.

  • 5–10 Personen mit echten Entscheidungen testen
  • laut denken lassen
  • nicht erklären, sondern beobachten
  • Ergebnis auf Plausibilität prüfen
  • Completion Rate und Zeit bis Ergebnis messen

Kernfragen im Test

  • Welche Frage war unklar?
  • Wo hast du geraten?
  • Wo wurdest du müde?
  • Was hat dich überrascht?
  • Fühlt sich das Ergebnis logisch an?
  • Würdest du das erneut nutzen?

10. Go-to-Market

Ziel der ersten Phase ist Validierung, nicht Wachstum. Gesucht werden Menschen mit echten Entscheidungen und Bereitschaft zur Reflexion.

Kanal Ansatz
Direktansprache Menschen mit aktueller Entscheidung gezielt ansprechen
LinkedIn Problem posten, Testpersonen suchen
Communities Karriere, Produktivität, Entscheidungsfindung
Netzwerk „Ich helfe dir bei einer Entscheidung“ statt „Test meine App“

Positionierung: Kein weiteres Produktivitätstool. Ein Tool, das zeigt, warum sich eine Entscheidung richtig oder falsch anfühlt.

11. Umsetzungsliste

  1. MVP-Use-Case festlegen
  2. Fragenkatalog finalisieren
  3. Drei Demo-Cases ausarbeiten
  4. Figma-Low-Fidelity-Flow bauen
  5. Fünf Nutzertests durchführen
  6. UX-Probleme priorisieren
  7. Datenmodell und API-Schnittstellen finalisieren
  8. Web-MVP mit Kernflow bauen
  9. Compute Engine integrieren
  10. Pilotgruppe starten

12. Copy-Block: wichtigste Entscheidungen als Markdown

Diesen Block kannst du separat kopieren und z. B. in Notion, GitHub, ein PRD oder ein Briefing übernehmen.

# Nutzomat App – wichtigste Entscheidungen

## Produktidee
Die Nutzomat-App macht individuelle Nutzenkalküle sichtbar. Sie ersetzt keine Entscheidung, sondern hilft Nutzern, die subjektiven Treiber ihrer Entscheidung zu verstehen.

## Kernmodell
Transaktionswert = Gesamtnutzen − Gesamtkosten

Gesamtnutzen:
- Ergebnisnutzen: Was bringt es direkt?
- Prozessnutzen: Wie ist der Weg?
- Persönlichkeitsnutzen: Passt es zu mir?
- Prosumtionsnutzen / Zukunftswert: Was baut es für später auf?

Gesamtkosten:
- Inputkosten: Geld, Zeit, Energie, Verzicht
- Transaktionskosten: Unsicherheit, Komplexität, mentale Last, Reibung

## Wichtigste Produktregel
Die App bewertet nicht objektive Qualität, sondern:
Wert der Alternative für diese Person in dieser Situation.

## MVP-Scope
- Web-App
- Einzelnutzer
- 2–4 Alternativen
- Situation und persönliche Prioritäten
- 6 Bewertungsdimensionen
- Ranking, Treiberanalyse, Confidence, Sensitivität
- Entscheidung speichern
- Follow-up erfassen

## Nutzerflow
1. Entscheidung anlegen
2. Alternativen erfassen
3. Situation erfassen
4. Persönliche Prioritäten festlegen
5. Alternativen bewerten
6. Ergebnis berechnen
7. Entscheidung speichern
8. Follow-up durchführen

## UX-Prinzipien
- Alltagssprache statt Fachsprache
- Schritt-für-Schritt statt Dashboard-Überladung
- Ergebnis immer erklären
- wenige Fragen pro Screen
- Nutzen und Kosten klar unterscheidbar

## Technische Entscheidung
Empfohlener Stack:
- Next.js
- TypeScript
- PostgreSQL
- separate Compute Engine
- Supabase/Auth0 für Auth
- PostHog für Analytics

## Team
- Product & Model Lead: Modelltreue, Scope, Fragenqualität
- Product Designer: Flow, UI, Ergebnisdarstellung
- Full-Stack Engineer: Architektur, DB, API, Frontend, Compute
- UX Research optional

## 6-Wochen-Plan
1. Modell und Scope finalisieren
2. Figma-Prototyp und erste Tests
3. Backend und Persistenz
4. Frontend-Kernflow
5. Compute Engine und Ergebnisansicht
6. Follow-up, QA und Pilot

## Go-to-Market
Ziel der ersten Phase ist Validierung, nicht Wachstum.
Kanäle:
- Direktansprache
- LinkedIn
- Communities
- eigenes Netzwerk

## Positionierung
Nicht: weiteres Produktivitätstool.
Sondern: Ein Tool, das zeigt, warum sich eine Entscheidung richtig oder falsch anfühlt.

## Nächster Schritt
Ein klickbarer Figma-Prototyp mit 5–10 echten Nutzertests, bevor der Web-MVP gebaut wird.

„““

path = Path(„/mnt/data/nutzomat_wordpress_kompatibel_ohne_js.html“)
path.write_text(html, encoding=“utf-8″)
path.as_posix()