Das Redesign wurde gestaffelt ausgerollt. Ich definierte zwei getrennte Ereignispunkte: einen in der alten und einen in der neuen Version des Spielebereichs. So erhält jede Person die passende Vorher- oder Nachher-Befragung. Einen einzelnen Ereignispunkt mit Datumsumschaltung verwarf ich, weil er während des Rollouts beide Produktversionen in dieselbe Welle gemischt hätte.

In einem Echtzeitspiel mit Einsatz kann eine Unterbrechung zur falschen Zeit Geld kosten. Die Befragung darf deshalb nie während einer laufenden Runde erscheinen. Ich spezifizierte zwei unkritische Momente; der erste eintretende löst aus, höchstens einmal pro Sitzung und einmal in 30 Tagen.

Spielansicht verlassen

Nach mindestens einer abgeschlossenen Runde. Dieser Moment allein würde Vielspieler verpassen, die die Anwendung direkt aus dem Spiel heraus schließen.

Länger verweilen, ohne aktiven Einsatz

Ergänzt den ersten Auslöser und erreicht auch Personen, die zuschauen. Beide Bedingungen lassen laufende Runden unberührt.

Die Anwendung übergibt nur, ob fortgeschrittene Funktionen freigeschaltet sind. Den Gerätetyp kennt die Plattform bereits. Im Fragebogen kommen genau drei Werte an: Welle, Gerätetyp und Freischaltstatus. Die verfügbare Mitgliedskennung habe ich bewusst nicht weitergegeben.

Diese Entscheidung hat eine methodische Konsequenz: keine Wiederbefragung derselben Personen und keine Verknüpfung mit Verhaltensdaten. Die Auswertung arbeitet mit unabhängigen Stichproben und muss deren Vergleichbarkeit prüfen.

Texte, Auslösebedingungen, Frequenzgrenzen, Fragebogen und An/Aus-Schalter liegen in einer versionierten Kampagnendefinition. Ich kann sie selbst einspielen, ohne für jede Anpassung Entwicklungskapazität zu binden. Der kleine Vertrag mit der Anwendung macht den Kanal für weitere Fragestellungen wiederverwendbar.

Der Spielebereich fehlte in der Testumgebung; der vollständige Pfad war dort nicht prüfbar. Deshalb entwarf ich einen kontrollierten Livestart am frühen Morgen bei geringem Verkehr, mit einer Person aus der Entwicklung im Spiel und einem Rückweg in unter einer Minute. Das Intercept ging in Betrieb.

Das Ergebnis ist ein live gebrachter Research-Kanal, den die Forschung selbst weiterbetreiben kann.

Eine gemessene Verbesserung der Produktqualität oder der Teilnahmequote wird in dieser Arbeitsprobe nicht behauptet. Offen bleibt, wie gut die kontextnahe Ansprache Vielspieler erreicht und wie sich Antwortende von nicht erreichten Personen unterscheiden.

Eine Bearbeitung erzeugt einen neuen Entwurf. Die zuletzt geteilte Fassung bleibt unverändert, bis Änderungen bewusst bestätigt werden. Das erfordert eine zusätzliche Handlung, verhindert aber stillschweigende Veränderungen einer bereits geteilten Information.

Unvollständig bleibt erkennbar

Nur eingegangene Dateien werden geteilt. Fehlende Dateien bleiben sichtbar, ohne die Übergabe aller vorhandenen Angaben zu blockieren.

Verfügbar bedeutet nicht geprüft

Verfügbarkeit, Öffnen und fachliche Prüfung sind getrennte Zustände. Auch unbekannt, nicht angegeben und ausdrücklich verneint bleiben unterscheidbar.

Fehler dürfen keinen Erfolg vortäuschen

Entwurf und letzte geteilte Fassung erhalten, den Fehler zeigen und einen erneuten Versuch ermöglichen.

Zuerst gehören eine verlässliche Fassung und Fehlerbehandlung in den kleinsten sinnvollen Umfang. Erinnerungen würde ich erst prüfen, wenn Vergessen als Ursache belegt ist. Eine KI-Zusammenfassung liegt außerhalb dieses Umfangs: Sie löst unklare Zustände nicht und braucht eine eigene fachliche Evaluation. Ein B2B-Abonnementmodell ist nur eine zusätzliche Übungsannahme; Bindungs- oder Umsatzeffekte sind nicht nachgewiesen.

In der Demo beobachtet

Fehlende Dateien in beiden Rollen, Trennung von Entwurf und geteilter Fassung sowie ein simulierter Fehler mit Retry-Anzeige.

Noch nicht belegt

Erfolgreicher Retry, alle Kombinationen der Statusbegriffe, die vorgeschlagene Pflichtfeldprüfung und produktiver Zugriffsschutz.

Stand des dokumentierten Demo-Reviews: 26.10.2026. Beobachtetes Browser-Verhalten ersetzt keine Produktionsabnahme.

Mit mehreren Praxen würde ich konkrete Übergaben und Gegenbeispiele vergleichen. Tierhalter:innen und Tierärzt:innen sollten ohne Hilfestellung die geteilte Fassung, fehlende Dateien und Statusbegriffe erkennen. Vor einem Pilot wären Baseline und Entscheidungsschwellen festzulegen, etwa für Rückfragen, unvollständige Übergaben, erfolgreiche Wiederherstellung und korrektes Statusverständnis.

Im Bestand war die Suche erst im Channel-Bereich erreichbar; Kategorien lagen hinter dem dritten Tab. Mein Entwurf brachte drei Zugänge auf die Startseite: ein sichtbares Suchfeld, Themenkategorien und Filter-Chips wie „Newbie freundlich“ oder „Mit Events“. Kategorien blieben das Gerüst, Eigenschaften sollten die Auswahl verfeinern.

Die Aufgabe war sinngemäß, einen Channel zu finden, in dem man sich als neues Mitglied wohlfühlen würde. Alle drei Zugänge standen gleichzeitig im selben Entwurf zur Wahl. Erfasst wurden gewählte Wege und Kommentare. Es war ein explorativer Test, kein kontrollierter Vergleich mit dem Bestand.

Präferenz, Nutzung und Rückmeldung sind unterschiedliche Signale. Mehrfachnutzung war möglich; die Zahlen sind keine vergleichbaren Erfolgsquoten und ergeben keine Rangliste.

Warum die Chips ungenutzt blieben, ist offen: übersehen, missverstanden oder bewusst nicht gewählt? Zusammensetzung und Vorerfahrung der Stichprobe sind nicht dokumentiert. Passung des gewählten Channels, Aktivierung und Wiederkehr wurden damit nicht gemessen.

Den zusätzlichen Filter-Einstieg würde ich in dieser Form nicht weiterführen. Die grundsätzliche Filteridee ist durch die Nichtnutzung noch nicht abschließend bewertet.

Suche verlässlich machen

Fehlertoleranz, Vorschläge beim Tippen und hilfreiche Wege bei null Treffern prüfen.

Kategorien prominent halten

Prüfen, ob Personen einen passenden Channel finden und ihre Auswahl begründen können.

Filter am konkreten Bedarf testen

Eigenschaften in Suchergebnissen und Kategorie-Listen erproben. In moderierten Sessions Sichtbarkeit, Verständnis und bewusste Nichtwahl auseinanderhalten.

Eine gesendete Nachricht konnte ohne sichtbare Rückmeldung unzugestellt bleiben. Eine ausbleibende Antwort ließ sich deshalb nicht ohne Weiteres als fehlendes Interesse lesen. Die nötige Zustellkontrolle war offen; eine mögliche Wechselwirkung zwischen Experimentarmen musste technisch geprüft werden.

Bevor wir Absichten aus Verhalten ableiten, müssen wir prüfen, ob die Situation diese Schlussfolgerung trägt.

Die Systemaggregate allein erklärten das Kontaktverhalten nicht ausreichend. Eine Veränderung des Auswahlverhaltens war noch kein Nachweis besserer Kontaktqualität; Zustellbedingungen und mögliche Wechselwirkungen zwischen Experimentarmen mussten technisch geprüft werden. Gleichzeitig zeigte der Retention-Vergleich ein relevantes Risikosignal: Die nicht vom Kontaktbudget betroffene Kontrollgruppe blieb weitgehend stabil, während sich bei den betroffenen Gruppen ein negativer Retention-Effekt zeigte.

Unverändert ausweiten

Hätte die Interpretationsprobleme und die Verbindung von Limit und Bezahlmodell übernommen.

Transparenz plus bezahlter Ausweg

Mehr Klarheit löst den Zielkonflikt nicht, wenn eine Schutzgrenze gegen Bezahlung durchlässig wird.

Vor einer Fortführung überarbeiten

Schutz und bezahlten Komfort trennen, Zustellbedingungen und offene Wirkungsfragen klären. Auch die wirtschaftliche Wirkung dieser Alternative blieb unbewiesen.

Ich empfahl keinen breiteren Rollout des statischen Limits und keinen bezahlten Bypass. Eine Fortführung sollte erst auf einer geklärten System- und Evidenzbasis erfolgen. Die anschließende Entscheidung war, das Experiment zu stoppen. Danach schwächte sich der negative Retention-Effekt weiter ab.

Die weitgehend stabile Kontrollgruppe und der abnehmende negative Retention-Effekt nach dem Stopp stützen die Bewertung, dass das Kontaktbudget zur Verschlechterung der Retention beigetragen hatte. Der Beitrag umfasst damit eine geänderte Produktentscheidung und einen beobachteten Verlauf nach dem Eingriff.

Im Schadenprozess arbeiten mehrere Parteien mit unterschiedlichen Aufgaben zusammen. Ein allgemeiner Fortschrittsbalken verdichtete diesen Ablauf, seine Logik blieb für Nutzer:innen jedoch unklar. Die entscheidende Frage war: Welche Fälle brauchen jetzt welchen nächsten Schritt?

Beobachten

Teilnehmende Beobachtungen an verschiedenen Standorten machten tatsächliche Arbeitsabläufe sichtbar.

Einordnen

Interviews mit Anwender:innen aus verschiedenen Bereichen ergänzten diese Sicht. Branchenexpert:innen halfen, Zusammenhänge fachlich abzugleichen.

Modellieren

Ein Prozessmapping verband Schritte und Interaktionen über mehrere Beteiligte. Konkrete Meilensteine wie eine digitale Unterschrift oder das Erstellen einer Forderung wurden als Status nutzbar.

Die neue Startseite benennt Aufgaben und zeigt, wie viele Fälle dazu gehören. Ein Klick öffnet die entsprechend gefilterte Fallliste. Das Prozessmodell wird damit zur bedienbaren Orientierung: Aufgabe wählen, relevante Fälle sehen, weiterarbeiten.

Ein Status hilft, wenn er an ein konkretes Ereignis und eine benennbare Aufgabe anknüpft.

Dokumentiert ist die Veränderung von einer allgemeinen Fallübersicht zu aufgabenbezogenen Einstiegen. Eine quantitative Verkürzung der Bearbeitungszeit lässt sich aus dem vorhandenen Material nicht rekonstruieren. Bei einer Weiterentwicklung würde ich besonders parallele Aufgaben, blockierte Fälle und Zuständigkeiten prüfen.

Innerhalb eines Tages gaben Vorbelegung und Tooltip Orientierung zum erwarteten Format. Das Team hob außerdem die Pflichtfeld-Beschränkung auf. Damit blockierte eine nicht erfolgreich eingegebene Adresse das Fortsetzen nicht mehr.

Der bisherige Kartenprovider unterstützte keine Autosuggestions. Nach einer Tool-Evaluation wechselten wir zu Mapbox und ergänzten eine Combobox mit Vorschlägen während der Eingabe. Kartendetails und Darstellung passten wir an den Anwendungsfall und die Unternehmensgestaltung an.

Diese Werte sind in der damaligen Arbeitsprobe und der rückblickenden Präzisierung berichtet. Sie beziehen sich auf das gesamte Paket aus Eingabehilfen, Pflichtfeldlogik und Adressvorschlägen.

Historische Projektangaben: Rohdaten, Messzeitraum und Stichprobe liegen für die Aufbereitung nicht vor. Die Einzeleffekte der Maßnahmen lassen sich nicht trennen; die Werte sind kein isolierter Wirksamkeitsnachweis für Mapbox.

Weniger Abbrüche sollten nicht durch mehr Nacharbeit erkauft werden. Deshalb würde ich die Vollständigkeit der Unfallorte, manuelle Alternativen und den Umgang mit erfolgloser Suche prüfen. Ein optionaler Schritt löst die Blockade, aber noch nicht jede nachgelagerte Datenfrage.

Der Einstieg fragt „What color’s your mood?“. Ein Farbkreis ordnet vier Bereiche entlang von hoher oder niedriger Energie und angenehmem oder unangenehmem Erleben. Ein gewählter Bereich führt zu passenden Gefühlsbegriffen. So wird die Auswahl schrittweise konkreter.

Im Bereich hoher Energie und angenehmen Erlebens zeigt die Demo unter anderem „excited“, „inspired“ und „curious“. Kurze Beschreibungen ergänzen die Begriffe. Die Umsetzung verbindet farbige, plastische Formen mit einer schmalen, vertikalen Oberfläche und direkt bedienbaren Auswahlmöglichkeiten.

Für diese Portfoliofassung wurde am 27.10.2026 ein Beispielpfad geöffnet: vom Farbkreis in den Bereich hoher Energie und angenehmen Erlebens bis zum Begriff „curious“. Die Live-Demo macht Navigation, visuelle Hierarchie und die Darstellung der Auswahl erfahrbar.

Der dokumentierte Stand ist ein Prototyp für die eigene Einordnung von Stimmung. Eine automatische Erkennung innerer Emotionen ist in der beobachteten Demo nicht Bestandteil des Ablaufs.

Diese Fragen sind nächste Prüfschritte für eine Weiterentwicklung. Sie sind keine nachträglich behaupteten Testergebnisse.

Verständlichkeit

Verstehen Personen die beiden Dimensionen und finden sie Begriffe, die zu ihrer eigenen Beschreibung passen?

Orientierung

Hilft der Farbkreis beim Einstieg, und bleibt der gewählte Bereich während der weiteren Auswahl verständlich?

Bedienbarkeit

Sind Texte, Kontraste, Tastaturbedienung und Auswahlzustände auch ohne Farberkennung gut nutzbar?

Mehrfaches Nachfragen kann an Kapazität oder an unbestätigten Übergaben liegen. Ein stockendes Onboarding kann fehlende Daten und Zugänge oder einen Produktfehler als Ursache haben. Diese Erklärungen müssen anhand konkreter Fälle auseinandergehalten werden, bevor zusätzliche Prozesse entstehen.

Priorisiert wird nach blockiertem Kernablauf, Häufigkeit, Beeinflussbarkeit und Aufwand. Zusätzliche Triage würde ich zurückstellen, wenn sie vor allem weitere Übergaben erzeugt.

Arbeitsfähigkeit vor dem nächsten Schritt

Daten, Zugänge und Rollen müssen verfügbar sein. Kund:innen demonstrieren eine tatsächliche Kernaktivität, statt nur ein Schulungsmodul abzuschließen.

Übergaben erst bei bestätigter Übernahme abschließen

Kontext, nächster Schritt und Rückmeldetermin gehören zusammen. Bis zur bestätigten Übernahme bleibt das sendende Team verantwortlich.

Ein mögliches Erfolgskriterium der Aufgabe: Kund:innen planen selbstständig Touren für einen tatsächlichen Arbeitstag. Danach soll der Kernablauf über zwei aufeinanderfolgende Wochen ohne Blockade funktionieren. Das sind vorgeschlagene Kriterien für einen Pilot, keine bereits erreichten Ergebnisse.

Time to First Value

Kalendertage vom Vertrag bis zum bestätigten ersten Nutzen, als Median und ergänzt um Anzahl und Alter noch ungelöster Fälle.

Abschluss und Aufwand

Abschlussquote nur für Fälle mit verstrichener Frist; junge Kohorten getrennt. Betreuungsaufwand pro Fall als Gegenprüfung.

Erleben und Verlässlichkeit

Customer Effort Score mit Ursache und Rücklaufquote, auch bei blockierten Fällen. Inhaltliche Rückmeldungen zum zugesagten Termin statt bloßer Empfangsbestätigungen.

Der Vorschlag umfasst zwei Wochen Analyse, eine Woche Vorbereitung, vier Wochen Pilot und anschließende Beobachtung. Entscheidungen fallen nach der Analyse, nach dem Pilot und bei ausreichendem Beobachtungszeitraum. Unterschiede im Fallmix begrenzen den Vergleich. Automatisierung folgt erst nach geklärtem Prozess; eine KI-Zusammenfassung müsste sich gegen eine einfache Vorlage bei Vollständigkeit, Korrekturaufwand und Zeitbedarf bewähren.

NPS, Interviews und Befragungen wurden mit Supportsignalen, App-Bewertungen, Churn-Informationen und Nutzungsdaten zusammengeführt. Sampling und Segmentierung gehörten dazu, um Unterschiede zwischen Kundengruppen sichtbar zu machen. Damit wurden quantitative Muster und qualitative Erklärungen gemeinsam für Produktfragen nutzbar.

Ich baute eine Feedbacktaxonomie mit Governance auf. Die gemeinsame Struktur machte Kundensignale über Kanäle hinweg einordnungsfähig. KI-gestützte Textanalyse unterstützte die Erschließung qualitativen Feedbacks; Produktdaten in Mixpanel und KPI-Reporting in Looker ergänzten die Analyse.

Das monatliche VoC-Reporting richtete sich an Product, Growth und Leadership. Zentrale Treiber und Reibungspunkte entlang der Customer Journey wurden in priorisierte Maßnahmen übersetzt. Ich stimmte die Umsetzung mit den beteiligten Teams ab und führte Rückmeldungen in den Arbeitsprozess zurück. Der Beitrag des Programms lag damit auch darin, Kundensignale in gemeinsame Prioritäten und konkrete Verbesserungen zu überführen.

Ich übersetzte die zentralen VoC-Treiber in einen abgestimmten Maßnahmenplan und begleitete dessen Umsetzung. Mein aktueller Lebenslauf dokumentiert einen Beitrag zur NPS-Steigerung und zur Verbesserung der Mobile-App-Conversion durch priorisierte Journey-Maßnahmen.

Die Zahlen beziehen sich auf den gemeinsamen Maßnahmenkontext. Sie beschreiben meinen Beitrag zur Entwicklung der Kennzahlen, keinen isolierten Kausaleffekt des VoC-Programms. Quelle: aktueller Lebenslauf, Fassung vom 27.10.2026.

Der Case verbindet Programmaufbau, Mixed Methods und Customer Journey Management: unterschiedliche Signale erschließen, Unterschiede zwischen Kundengruppen verstehen und Erkenntnisse in koordinierte Verbesserungen überführen. Taxonomie, Governance und regelmäßiges Reporting schaffen dafür eine wiederverwendbare Arbeitsgrundlage.

Das Zielbild umfasst Kundenfeedback, qualitative Nutzerforschung und Experiment- beziehungsweise Testwissen. Markdown-Dateien sind die maßgebliche Quelle; Datenbanken sollen erneuerbare Indizes sein. Entwurf, freigegebener und ersetzter Stand werden ebenso unterschieden wie Nutzerforschung, interne Stakeholder-Aussagen und Referenzwissen. Eine interne Annahme über Nutzer wird dadurch nicht zur Nutzerevidenz.

Aussagen zurückverfolgen

Textstellen-IDs, Quellenanker und studienübergreifende Codebücher verbinden die Auswertung mit ihrem Material.

Codes begründet erweitern

Neue Codes brauchen Abgrenzung, Beleg und Gegenbeleg. Über ihre Aufnahme entschied ich fachlich.

Antwortgrenzen sichtbar machen

Der Assistent nutzt freigegebene Ergebnisse, soll Belastbarkeit und Grenzen nennen und bei fehlender Evidenz auch „nicht beantwortbar“ ausgeben.

In der Arbeitsprobe dokumentiert

Eine dateibasierte Research-Ablage mit elf Studien und 13 Codebüchern, ein skriptgestützter Whitelist-Export, Metadatenprüfungen und ein Research-Assistent auf dem freigegebenen Bestand.

Noch im Aufbau

Der Export wurde manuell gestartet. Typisierte Wissensobjekte, weitergehende Automatisierung und ein von einer Einzelperson unabhängiger Betrieb waren noch nicht abgeschlossen.

Die Angaben beschreiben den Stand der Arbeitsprobe vom September 2026.

Für eine Anfrage, deren Bearbeitung sonst Tage gedauert hätte, konnte das Repository innerhalb von Stunden als Grundlage für erste Hypothesen zu Produkt-Opportunities genutzt werden. Vorhandenes Research-Wissen wurde damit schneller für eine neue Fragestellung nutzbar. Im gemeinsam gestalteten PR/FAQ-Piloten werden Annahmen mit Belegen und den Folgen eines Irrtums verbunden. Fehlende Evidenz soll dort zusätzliche Prüfung auslösen, wo ein Irrtum schwerwiegend wäre. Nach zwei Vorhaben sollte überprüft werden, ob diese Transparenz verändert hat, was gebaut wurde. Der organisationsweite Nutzen war damit eine zu prüfende Frage, kein bereits gemessener Erfolg.

Nicht möglichst viel Wissen speichern, sondern klären, wann eine Aussage für eine konkrete Entscheidung tragfähig ist.