„Feiertagsarbeit“
Der 1. Mai. ist ein Feiertag, zumindest auf dem Papier.
Mein Vermieter verbrachte ihn damit, seine Nebenkostenabrechnungen zu erstellen. Den ganzen Tag mit seiner Excel-Vorlage, die er vor etwa 20 Jahren selbst gebaut hatte und seitdem jedes Jahr fortschreibt. Vielleicht war er an diesem Abend nicht der einzige — Kleinvermieter und Feiertage, eine stille Tradition? Dieses Jahr aber arbeitete er zum ersten Mal auch mit KI, als Kontrollinstanz. Er kopierte Seiten seiner Excel-Datei einzeln in einen KI-Chat, ließ die Werte prüfen, verglich die Ergebnisse. Manuell. Schritt für Schritt.
Am Abend schrieb er mir, dass er den ersten Teil meiner Abrechnung fertig habe. Wie hoch sie am Ende sein würde, wusste ich noch nicht.
Was folgte, war ein längerer Austausch. Ich erfuhr wie sein Prozess aussah, wo er hakte, was er entdeckt hatte. Er war nicht frustriert, er war stolz. Stolz darauf, dass seine eigene Berechnungslogik mit der KI übereinstimmte. Dass seine Vorlage von vor 20 Jahren noch korrekt rechnete.
„Ganzen Tag schon verwendet für KI und Excel.“
Ich hörte ihm zu. Und gleichzeitig sah ich sofort: hier liegt enorm viel ungenutztes Potenzial. Nicht weil er etwas falsch machte, sondern weil der Weg unnötig lang war. Die Versorgerrechnungen lagen als PDFs vor. Die Stammdaten existierten. Die Berechnungslogik funktionierte. Was fehlte, war ein Workflow der das alles zusammenführt, ohne stundenlangen Feiertag-Einsatz.
Noch am selben Abend fing ich an, genau das zu bauen.
Ist das überhaupt UX Research?
Ich habe an diesem Abend zugehört, gefragt, gebaut und viel gelernt. Habe ich dabei auch geforscht?
Was ich hatte, war ein echtes Gespräch während einer echten Situation. Keine Laborsession, kein Leitfaden, kein Aufnahmegerät. WhatsApp-Nachrichten von jemandem, der gerade mittendrin war. Das ist nah an dem, was man In-context Interview nennt: ein Gespräch im echten Arbeitskontext, ungeplant, aber nicht zufällig.
Was ich nicht weiß:
- Ob dieser eine Vermieter repräsentativ ist.
- Ob seine drei größten Schmerzpunkte dieselben sind wie die seiner Nachbarn, die dasselbe tun.
- Ob der Review-Step wirklich das ist, was Vertrauen schafft, oder ob er nur für jemanden funktioniert, der ohnehin schon gewohnt ist, jeden Schritt selbst zu kontrollieren.
Wenn ich dieses Projekt weiterentwickeln würde, würde ich drei Dinge zuerst untersuchen:
- Wie oft passieren Fehler beim manuellen Übertragen von Zahlen aus Excel, und wann fallen sie auf?
- Wie viel Vertrauen braucht jemand, bevor er eine KI-extrahierte Zahl in einem Rechtsdokument stehen lässt?
- Welche Kostenpositionen sind die, bei denen jemand ohne Buchhaltungshintergrund wirklich ins Stocken gerät?
Ich habe Entscheidungen getroffen, die sich für diesen Nutzer richtig anfühlten. Ob sie das für andere auch tun, weiß ich nicht.
Den Nutzer verstehen, bevor man die erste Komponente designt
Mein Vermieter ist kein Buchhalter. Er ist jemand, der handwerkliche Arbeiten an seinen Immobilien selbst ausführt, Aufträge vergibt wo nötig, und in diesem Bereich auf jahrzehntelange Erfahrung zurückgreift, teils auf Wissen, das er von seinen Eltern übernommen hat, gemeinsam mit den Wohnungen selbst. Er denkt in Projekten, nicht in Tabellen. Sein Handwerk ist das Objekt, die Verwaltung dahinter ist Infrastruktur. Notwendig, aber nicht sein Kernbereich.
Diese Persona hat drei direkte Design-Entscheidungen bestimmt.
Ein langes Formular mit 30+ Feldern hätte diesen Nutzer sofort verloren. Der Multi-Step-Ansatz bricht die kognitive Last in überschaubare Einheiten auf: ein Schritt, eine klare Aufgabe. Das entspricht der Art, wie jemand denkt, der gewohnt ist, ein Handwerksprojekt in Phasen abzuarbeiten, nicht in Tabellenzeilen.
Versorgerabrechnungen kommen als Scan, Foto, Papierbeleg. KI-Extraktion auf nicht vollständig digitalen Dokumenten ist fehleranfällig. Ein falscher Betrag in einer Nebenkostenabrechnung ist rechtlich anfechtbar nach § 556 BGB. Der Review-Step gibt dem Vermieter die Kontrolle zurück.
Die KI sieht das Dokument, aber nicht den Mietvertrag, nicht ob jede Wohnung einen eigenen Wasserzähler hat. Er lebt in einer kleinen Gemeinde, die Objekte im selben Dorf. Man kennt sich. Eine falsche Abrechnung beschädigt einen Ruf, der über Generationen aufgebaut wurde.
Warum kein Figma
Der Ausgangspunkt war kein Design-Brief. Es war ein WhatsApp-Gespräch an einem Feiertagsabend mit einem Vermieter, der stolz war, seine 20 Jahre alte Excel-Datei mit KI überprüft zu haben, per Copy & Paste im Browser, ohne optimierten Workflow dahinter.
Ich wollte ihm noch am selben Abend zeigen, was 2026 möglich ist. Nicht erklären. Zeigen.
Ein Figma-Prototyp wäre dafür das falsche Werkzeug gewesen. Mein Vermieter kennt die Berufsbezeichnungen UX Designer und Frontend Developer vermutlich nicht, geschweige denn wie diese üblicherweise zusammenarbeiten. Ein klickbarer Dummy hätte ihn nicht überzeugt, weil er keinen für ihn direkt verwertbaren Output liefert. Kein Ergebnis, keine Zahl, keine Abrechnung. Nur Klicks ohne Konsequenz.
Was ich stattdessen gebaut habe, war ein funktionierender KI-Workflow in Claude: Versorgerrechnungen hochladen, Daten extrahieren lassen, Abrechnung als PDF generieren. Den Link dazu habe ich ihm noch am selben Abend per WhatsApp geschickt, eine direkt nutzbare Claude-Session, kein Mockup. Diese Dokumentation entstand danach als strukturierte Aufarbeitung des Prozesses.
Was dieser PoC bewusst nicht leistet
Der Prototyp verzichtet auf AI Agents, die autonom Entscheidungen treffen. Das war keine technische Einschränkung, es war eine methodische Entscheidung. Der Workflow wurde bewusst am mentalen Modell des Nutzers ausgerichtet: Er kennt den Excel-Prozess. Die App optimiert genau diesen Teil, ohne seinen Referenzrahmen zu ersetzen.
- Nicht mit dem Vermieter als aktivem Tester validiert. Er war an demselben Abend mit seinem eigenen Workflow beschäftigt.
- Eine Persona, ein Gespräch. Ob die Entscheidungen für andere Kleinvermieter genauso tragen, ist offen.
- Der Umlageschlüssel bleibt eine manuelle Entscheidung, weil die KI den Mietvertrag nicht kennt. Das ist eine bewusste Grenze, keine technische Schwäche.
Die technischen Grenzen des PoC sind im Workflow dokumentiert. Diese hier sind methodischer Natur und bleiben auch in einer Folgeversion relevant.
Parallel arbeiten, nicht beobachten
Ich hätte den Vermieter an seinem Arbeiten bremsen und ihn durch einen strukturierten Usability-Test führen können. Ich habe es bewusst nicht getan.
Stattdessen lief beides parallel: Er arbeitete an seinen Abrechnungen mit seinem eigenen Workflow. Ich arbeitete daneben an einer Alternative. Wir tauschten uns über WhatsApp aus: er erklärte, ich stellte Fragen, ich zeigte erste Ergebnisse, er reagierte. Das war kein Labor, das war sein natürlicher Kontext.
Diese Arbeitsweise hatte einen Nebeneffekt: Der Vermieter war ohnehin bereits dabei, KI in seinen Prozess zu integrieren, auf seine eigene Art. Wir arbeiteten parallel, tauschten uns aus, verglichen Ansätze. Er validierte seinen Workflow, ich baute einen neuen. Das war kein geplantes Outcome, es war ein Synergie-Effekt zweier Menschen die gleichzeitig dasselbe Problem angingen.
Der PoC soll ihn inspirieren. Im besten Fall bleibt er als Wendepunkt in Erinnerung: der Abend, an dem er zum ersten Mal gesehen hat, wie sein Prozess 2026 aussehen könnte.
Der Workflow dahinter
Wie dieser Workflow technisch funktioniert, was er leistet und wo die Grenzen liegen.
KI Workflow ansehen →