Ein Befragungskanal, den Research selbst betreiben kann.
Für ein Redesign sollte die wahrgenommene Qualität vor und nach der Veränderung untersucht werden. Ich entwickelte dafür einen wiederverwendbaren Befragungskanal direkt im Produkt und brachte ihn mit Engineering kontrolliert in Betrieb. Die Ansprache ist so angelegt, dass laufende Spielrunden ungestört bleiben.
Große deutsche Freizeitplattform · Spielebereich · 2026
Meine Rolle
Konzeption, Spezifikation, Kampagnen, Fragebögen und kontrollierter Livegang
Stand
Wiederverwendbarer Befragungskanal in Betrieb. Studienergebnisse sind nicht Teil dieser Arbeitsprobe.
Mein Beitrag
Ich konzipierte das Intercept und spezifizierte beide Seiten: Ereignispunkte und Datenübergabe für die Anwendung sowie Kampagnendefinitionen für die Plattform. Kampagnen und Fragebögen baute, versionierte und spielte ich selbst ein. Das Entwicklungsteam implementierte den Aufruf in der Anwendung und schaltete die Ereignispunkte frei.
USER FLOW
Wann darf die Einladung erscheinen?
Moment ASpielansicht verlassen
Mindestens eine Runde abgeschlossen.
Moment BLänger verweilen
Kein aktiver Einsatz.
↓Der erste gültige Moment zählt
Plattform prüft die Freigabe
Alter · Sprache · Sitzung · maximal einmal in 30 Tagen
↓
FreigegebenEinladung zur Befragung
Nur bei erfüllten Bedingungen.
GesperrtKeine Einblendung
Während einer laufenden Runde oder bei nicht erfüllten Bedingungen.
Schematische Auslöselogik aus der Spezifikation. Eine laufende Spielrunde bleibt geschützt.
01
Die richtige Welle an der Produktversion erkennen
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.
BEFRAGUNGSPFADE
Die Produktversion bestimmt die Welle
Alte Produktversion
↓Eigener Ereignispunkt
Vorher-Befragung
Neue Produktversion
↓Eigener Ereignispunkt
Nachher-Befragung
Beide Versionen können während des gestaffelten Rollouts gleichzeitig im Einsatz sein. Die Zuordnung erfolgt deshalb über die Version statt über ein Umschaltdatum.
02
Den Nutzungsmoment schützen
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.
03
Ein Wert hinein, drei Werte hinaus
1 Wert
aus der Anwendung
3 Werte
im Fragebogen
0
übermittelte Mitgliedskennungen
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.
04
Forschung kann den Kanal selbst steuern
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.
05
Kontrolliert live gehen
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.
Für eine Praxis zählt, welche Angaben vor dem Gespräch tatsächlich vorliegen. Ich entwickelte einen Consultation Brief, der Entwurf, bestätigte Fassung und fehlende Dateien unterscheidbar macht. Im Prototyp lässt sich prüfen, was beide Rollen sehen und was bei einer fehlgeschlagenen Übergabe erhalten bleibt.
Konzept des Consultation Brief und bereitgestellter klickbarer Prototyp
Stand
Demo und nachträgliche Spezifikation; keine Nutzerforschung, kein Produktivbetrieb und keine gemessene Geschäftswirkung.
Mein Beitrag
Mein Beitrag sind das Konzept des Consultation Brief und der bereitgestellte klickbare Prototyp. Die Portfoliofassung ergänzt nachträglich Anforderungen, Priorisierung und Validierungsplan mit KI-Unterstützung. Sie ist keine ursprüngliche Build-Spezifikation.
01 · Entwurf prüfen
ENTWURF IST SICHTBAR
Vor dem Teilen Klarheit schaffen.
Die Versionsnummer und „Not shared yet“ machen den Stand des Briefs sichtbar.
„Unknown“ und „Not provided“ unterscheiden fehlendes Wissen von einer fehlenden Angabe.
Original-Screenshot aus dem bereitgestellten Lovable-Prototyp. Fiktive Konsultation.
Bereitgestellter Original-Screenshot des PetDoc-Prototyps. Die Darstellung zeigt fiktive Demo-Daten.
01
Die zentrale Produktentscheidung
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.
02 · Vollständigkeit & FreigabeNur empfangene Dateien werden geteilt. Die fehlende Datei bleibt ausdrücklich als „Not received“ sichtbar.
USER FLOW
Eine Änderung ist noch keine Übergabe
Tierhalter:inAngaben und Dateien prüfen
Nur eingegangene Dateien können geteilt werden.
↓Confirm & share
ErfolgFassung v1 geteilt
Tierärzt:in sieht die bestätigten Angaben und erhaltenen Dateien.
↓Angaben bearbeiten und speichern
Noch nicht geteiltEntwurf v2
Tierärzt:in sieht weiterhin v1.
↓Share updates erfolgreich
Fassung v2 geteilt
Erst jetzt ist die neue Fassung verfügbar.
FehlerÜbergabe fehlgeschlagen
Entwurf bleibt erhalten. Die bisher geteilte Fassung bleibt unverändert.
↓Try again
Übergabe erneut versuchen
Bei Erfolg wird der bestätigte Entwurf zur neuen geteilten Fassung.
Im Prototyp nachvollzogen: Rollenwechsel, v1/v2, simulierter Übergabefehler und erfolgreicher erneuter Versuch. Demo-Review vom 28.10.2026.
02
Prioritäten ohne erfundene Scores
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.
03
Beobachtet und noch offen
In der Demo beobachtet
Fehlende Dateien in beiden Rollen, Trennung von Entwurf und geteilter Fassung sowie ein simulierter Übergabefehler. Auch der erfolgreiche erneute Versuch und die anschließend geteilte Version 2 wurden nachvollzogen.
Noch nicht belegt
Alle Kombinationen der Statusbegriffe, die vorgeschlagene Pflichtfeldprüfung und produktiver Zugriffsschutz.
Dokumentiertes Demo-Review vom 26.10.2026, ergänzt um den Browser-Durchlauf vom 28.10.2026. Beobachtetes Demo-Verhalten ersetzt keine Produktionsabnahme.
04
Der nächste Discovery-Schritt
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.
Grundlage: Nora_Wiemann_Product_Discovery_PetDoc_DE_EN.pdf · 26.10.2026; bereitgestellte Screenshots und ergänzender Demo-Durchlauf vom 28.10.2026
Mit Nutzertests die nächste Designiteration begründen.
Neue Mitglieder sollten einen passenden Chatraum finden können. Ich entwarf drei direkt zugängliche Einstiege und prüfte sie mit zwölf Personen. Aus den gewählten Wegen und Rückmeldungen leitete ich ab, welche Ansätze weiterverfolgt werden sollten und wo eine zusätzliche Prüfung nötig ist.
Kontext
Chat-Community · Product Discovery
Meine Rolle
Konzept, Informationsarchitektur, klickbarer Testprototyp und Usability-Test
Stand
Entwurf und Test dokumentiert; Umsetzung und Produktwirkung nicht belegt.
Mein Beitrag
Ich entwickelte das Konzept und die Informationsarchitektur, erstellte den klickbaren Testprototyp und prüfte ihn mit zwölf Personen in einem unmoderierten Remote-Test mit Lyssna.
AusgangslageTestentwurf
Schematische, anonymisierte Rekonstruktionen aus der vorhandenen Portfolio-Datei. Die Empfehlungssignale im Prototyp waren fingiert.
01
Den Einstieg sichtbar machen
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.
02
Was der Test beantworten konnte
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.
KLICKPFADE & TESTSIGNALE
Drei Einstiege in dieselbe Suchaufgabe
Startseite
Aufgabe im Test: einen passenden Channel finden.
↓Zugänge gleichzeitig verfügbar
SucheSuchfeld
Gezielt einen Begriff eingeben.
↓
8 / 12
Bevorzugten die Suche.
KategorienThemenkategorie
Über ein Thema einsteigen.
↓
6 / 12
Nutzten Kategorien und beschrieben sie als hilfreich.
EigenschaftenFilter-Chip
Nach Eigenschaften eingrenzen.
↓
0 / 12
Nutzten die Chips. Der Grund bleibt offen.
Präferenz und Nutzung sind unterschiedliche Signale. Mehrfachnutzung war möglich. Die Zahlen sind keine Erfolgsquoten und lassen sich nicht addieren.
03
Drei unterschiedliche Signale
8 / 12
bevorzugten die Suche
6 / 12
nutzten Kategorien und beschrieben sie als hilfreich
0 / 12
nutzten die Filter-Chips
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.
04
Die Empfehlung für die nächste Iteration
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.
Grundlage: Nora_Wiemann_Channel_Discovery.html und Nora_Wiemann_Channel_Discovery_DE.pdf · Portfolio-Aufbereitung Oktober 2026
Eine Produktentscheidung bei Retention-Risiken ändern.
Ein Experiment begrenzte neue Kontaktaufnahmen. Ich verband Rückmeldungen, Interviews, Systemaggregate und technische Dokumentation, um Nutzen und Risiken zu beurteilen. Die Analyse begründete meine Empfehlung zum Stopp, die anschließend umgesetzt wurde.
Kontext
Knuddels · Research und Entscheidungsvorbereitung · Juli 2026
Meine Rolle
Synthese von Rückmeldungen, Interviews, Systemaggregaten und Dokumentation
Stand
Das Experiment wurde auf meine Empfehlung hin gestoppt. Die Retention der Kontrollgruppe blieb weitgehend stabil; der negative Retention-Effekt in den betroffenen Gruppen schwächte sich nach dem Stopp weiter ab.
Mein Beitrag
Ich führte Befragungsrückmeldungen, qualitative Interviews, Systemaggregate und Systemdokumentation in einer Entscheidungsvorlage zusammen. Dabei trennte ich Hinweise auf Nutzungserleben von Hypothesen über die Wirkmechanik.
NUTZUNGSPFAD & SYSTEMZUSTAND
Gesendet heißt noch nicht zugestellt
Nachricht senden
Die Person löst eine Kontaktaufnahme aus.
↓
Wurde die Nachricht zugestellt?
Der Zustellstatus ist aus Nutzersicht nicht zuverlässig erkennbar.
↓
Möglicher Pfad AZugestellt
Eine Antwort kann aus unterschiedlichen Gründen ausbleiben.
Möglicher Pfad BNicht zugestellt
Die empfangende Person konnte auf diese Nachricht nicht reagieren.
↓Beide Pfade können gleich aussehen
Keine Antwort sichtbar
Daraus lässt sich fehlendes Interesse nicht eindeutig ableiten.
Die Visualisierung zeigt die Interpretationslücke. Die konkrete Verteilung der Zustellpfade war nicht geklärt.
01
Der Wendepunkt: Verhalten braucht Systemkontext
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.
02
Systemkontext und Retention gemeinsam bewerten
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.
03
Drei Optionen abwägen
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.
04
Empfehlung und Ergebnis
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.
Grundlage: 04_Nora_Wiemann_Arbeitsprobe_WissensDB_und_FCB_DE.pdf · September 2026, Seite 2. Ergänzende Praxiserfahrung von Nora Wiemann vom 27. Oktober 2026: Retention der Kontrollgruppe und Verlauf nach dem Experimentstopp.
Konkrete Aufgaben führen zu den passenden Schadenfällen.
Die bisherige Fallübersicht zeigte Fortschritt, ließ aber offen, welche Arbeit als Nächstes anstand. Durch Research zum Schadenprozess entwickelte das Team einen Einstieg über konkrete Aufgaben. Mein Beitrag zu Research und UX-Konzeption half, den Arbeitsablauf in eine bedienbare Orientierung zu übersetzen.
Kontext
kaayo · B2B-SaaS · 2024
Meine Rolle
UX Designerin · Research und UX-Konzeption im Team
Stand
Gemeinsam entwickelte Lösung; keine rekonstruierbare quantitative Wirkungsmessung.
Mein Beitrag
Ich arbeitete an Research und UX-Konzeption. Die Case Study zeigt meinen Beitrag im Team sowie die gemeinsam entwickelte Lösung.
Vorher · FallübersichtFortschritt wird angezeigt, die nächste Handlung bleibt unklar.Nachher · AufgabenübersichtAufgaben und Fallzahlen werden zu direkten Einstiegen.
Original-Oberflächen aus Arbeitsproben_NoraWiemann.pdf, Seite 8. Die historischen Ansichten zeigen unterschiedliche Demo-Rollen; die Fallzahlen sind kein Vorher-nachher-Vergleich.
01
Das Problem lag im Prozessverständnis
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?
02
Vom Arbeitsalltag zum gemeinsamen Modell
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.
RESEARCH-ARTEFAKT · PROZESSMAPPINGDas gemeinsam erarbeitete Mapping machte Interaktionen und Übergaben zwischen den Beteiligten sichtbar. Original aus der Arbeitsprobe, Seite 9; historischer Export in vorhandener Auflösung.
03
Die Entscheidung: Aufgaben statt abstraktem Fortschritt
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.
KLICKPFAD MIT ORIGINAL-SCREENS
Die Aufgabe bleibt über den Seitenwechsel erhalten
01 · StartseiteAufgabe auswählen
Beispiel: „Fall abschließen“. Die Kachel zeigt die zugehörige Fallzahl.
Original-Oberfläche · Aufgabenübersicht
↓Klick auf die passende Aufgabenkachel
02 · FalllistePassende Fälle sehen
Die Liste ist auf die gewählte Aufgabe gefiltert. Der Filter hält den Einstiegskontext sichtbar.
Original-Filter der Fallliste. Personenbezogene Fallangaben sind nicht im Ausschnitt enthalten.
↓Einen relevanten Fall öffnen
03 · FallbearbeitungFallbezogen weiterarbeiten
Vom gewählten Arbeitsschritt zum passenden Fall.
Rekonstruktion des dokumentierten Einstiegspfads mit Original-Oberflächen. Die Kacheln sind alternative Einstiege, keine zwingende Reihenfolge im Schadenprozess. Die Bilder zeigen historische Beispielzustände.
04
Ergebnis und heutige Reflexion
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.
Weniger Abbrüche im kritischen Schritt der Schadenmeldung.
In Schritt 2 von 9 brach laut damaliger Arbeitsprobe rund ein Drittel der Nutzer:innen ab. Meine Usability-Analyse identifizierte ein unklar kommuniziertes Adressformat, fehlende Korrekturhilfe und ein blockierendes Pflichtfeld. Aus der Analyse entstanden ein kurzfristiger Eingriff und die anschließende Weiterentwicklung mit Adressvorschlägen.
Kontext
kaayo · Schadenmeldung · 2024
Meine Rolle
UX Designerin · Usability-Analyse, Eingabehilfen und Lösungskonzeption im Team
Stand
Quickfix und weiterführende Lösung; Kennzahlen sind historische Projektangaben.
Mein Beitrag
Ich analysierte die Eingabehürden, überarbeitete die Hilfestellung und gestaltete die weiterführende Lösung mit dem Team.
01 · Quickfix im EingabeschrittDie Eingabemaske des zweiten Schritts. Eingabehilfen und die aufgehobene Pflichtfeld-Beschränkung entlasteten den Ablauf.02 · Combobox mit AdressvorschlägenDie anschließende Weiterentwicklung ergänzt Vorschläge beim Tippen. Eine passende Adresse kann aus der Liste gewählt werden.
Original-Screenshots aus Arbeitsproben_NoraWiemann.pdf, Seiten 4 und 6. Eingabeschritt und spätere Combobox sind getrennt dargestellt.
01
Sofort entlasten
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.
USER FLOW
Die Blockade im zweiten Schritt auflösen
VorherAdresse manuell eingeben
Das erforderliche Format ist unklar.
↓Format nicht akzeptiert
Generische Fehlermeldung
Keine konkrete Korrekturhilfe.
↓
Fortsetzen blockiert
Das Pflichtfeld lässt keinen Ausweg.
QuickfixEingabe mit Hilfestellung
Vorbelegung und Tooltip erklären das Format.
↓
Adresse eingeben oder auslassen
Die Pflichtfeld-Beschränkung ist aufgehoben.
↓
Schadenmeldung fortsetzen
Eine nicht gelungene Adresseingabe hält den Ablauf nicht mehr auf.
Zuerst wurde die Blockade beseitigt. Adressvorschläge kamen in der anschließenden Weiterentwicklung hinzu.
02
Die Eingabe strukturell verbessern
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.
03
Die Wirkung gehört zum Maßnahmenpaket
25 %
relativ weniger Abbrüche in Schritt 2 von 9
15 Sek.
durchschnittlich im Eingabeschritt gespart
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.
04
Was ich heute mitprüfen würde
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.
Eine Interaktionsidee als bedienbare Demo erfahrbar machen.
Wie lässt sich ein Mood-Check-in über Farbe und konkrete Gefühlsbegriffe gestalten? Ich setzte die Idee selbst mit Lovable als bedienbare Demo um. Dadurch werden Navigation, Auswahl und Beschreibungen direkt erfahrbar und können zum Ausgangspunkt einer späteren Prüfung werden.
Öffentlich aufrufbare Demo. Ein Auswahlpfad wurde für diese Portfoliofassung nachvollzogen; keine dokumentierte Nutzerstudie oder Wirkungsmessung.
Mein Beitrag
Ich habe den interaktiven Prototyp selbst mit Lovable gebaut und als Live-Demo bereitgestellt. Die Arbeitsprobe zeigt KI-gestütztes Prototyping an einer direkt ausprobierbaren Interaktion.
Hohe EnergieUnangenehm
Hohe EnergieAngenehm
Niedrige EnergieUnangenehm
Niedrige EnergieAngenehm
Farbregion wählen → Gefühlsbegriffe erkunden → Eigene Stimmung einordnen
Schematische Übersicht der in der Live-Demo sichtbaren Interaktion. Die Gefühle werden durch Selbstauskunft ausgewählt.
01
Vom Farbkreis zur konkreten Auswahl
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.
02
Gefühlsbegriffe mit kurzen Beschreibungen verbinden
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.
USER FLOW
Von einer Stimmung zu einem passenden Begriff
Farbkreis
Energie und angenehmes oder unangenehmes Erleben einordnen.
↓Beobachteter Beispielpfad
Hohe Energie · angenehm
Der Bereich bietet mehrere konkrete Gefühlsbegriffe.
↓
Alternativeexcited
Alternativeinspired
Geöffneter Pfadcurious
Begriff wählen und kurze Beschreibung lesen.
Ein nachvollzogener Auswahlpfad der Live-Demo. Die Einordnung erfolgt durch die Person selbst; sie wird nicht automatisch erkannt.
03
Was sich direkt ausprobieren lässt
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.
04
Was ich als Nächstes prüfen würde
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?
Grundlage: Eigene LinkedIn-Projektbeschreibung „KI-Prototyping | Live-Demo“ und VibePop-Live-Demo, eingesehen am 27.10.2026
Arbeitsfähigkeit und klare Übergaben im Onboarding priorisieren.
Unzufriedene Kund:innen und viele Kennzahlen ließen noch nicht erkennen, welche Eingriffe das Onboarding verbessern würden. Ich strukturierte mögliche Ursachen und priorisierte zwei Maßnahmen: Arbeitsfähigkeit vor dem nächsten Schritt und bestätigte Übergaben zwischen Teams. Ein Pilotplan legt fest, wie ihre Wirkung geprüft werden soll.
Kontext
Anonymisierter Anbieter von Pflegesoftware
Meine Rolle
Problemstrukturierung, Ursachenhypothesen, Priorisierung und Pilotplanung
Stand
Konzeptioneller Lösungsvorschlag; keine implementierten Maßnahmen oder gemessenen Resultate.
Mein Beitrag
Ich strukturierte das Problem, stellte konkurrierende Ursachenhypothesen gegenüber und priorisierte zwei Prozessmaßnahmen. Dazu entwickelte ich einen Pilot- und Messplan mit Entscheidungspunkten.
01Vorbereiten
Daten, Zugang und Rollen klären
02Einrichten
Arbeitsfähigkeit herstellen
Support begleitet alle Phasen. Jede Übergabe braucht eine bestätigte Übernahme.
03Anwenden
Kernaktivität selbst ausführen
04Stabilisieren
Blockaden und Aufwand verfolgen
Service-Blueprint der Konzeptarbeit, verdichtet auf vier Phasen. Support begleitet die gesamte Journey.
01
Symptome sind noch keine Ursachen
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.
02
Zwei priorisierte Eingriffe
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.
03
Ersten Wert an realer Arbeit erkennen
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.
04
Ein Messplan, der stockende Fälle sichtbar lässt
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.
05
Erst prüfen, dann skalieren
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.
Kundenfeedback in abgestimmte Verbesserungen übersetzen.
Kundenfeedback sollte bei sevdesk gemeinsame Produktentscheidungen ermöglichen. Ich baute das VoC- und NPS-Programm auf, verband Rückmeldungen mit Nutzungsdaten und übersetzte die wichtigsten Treiber in einen abgestimmten Maßnahmenplan. Dessen Umsetzung begleitete ich mit Product, Marketing, Support und CX.
Kontext
sevdesk · B2B SaaS · 2025/2026
Meine Rolle
Programmmanagerin Voice of Customer · Programmaufbau, Analyse, Reporting und Maßnahmenabstimmung
Stand
VoC- und NPS-Programm aufgebaut; dokumentierter Beitrag zu Verbesserungen von NPS und Mobile-App-Conversion.
Mein Beitrag
Ich verantwortete das NPS-Programm von Konzeption und Sampling bis Segmentierung, Analyse und Reporting. Ich etablierte ein monatliches VoC-Reporting, baute eine Feedbacktaxonomie mit Governance auf und übersetzte zentrale Treiber in einen abgestimmten Maßnahmenplan. Die Umsetzung begleitete ich gemeinsam mit Product, Marketing, Support und CX.
01Signale verbinden
Befragungen · Support · App-Reviews · Churn · Nutzung
Monatliches VoC-Reporting für Product, Growth und Leadership.
02Erkenntnisse strukturieren
Taxonomie · Segmentierung · qualitative und quantitative Analyse
Arbeitslogik des VoC-Programms aus dem vorhandenen Praxisprofil und Lebenslauf, schematisch zusammengefasst.
01
Signale aus mehreren Perspektiven verbinden
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.
02
Eine gemeinsame Struktur für Erkenntnisse schaffen
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.
03
Aus Erkenntnissen abgestimmte Maßnahmen ableiten
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.
04
Dokumentierte Beiträge zur Wirkung
+9,0
NPS-Punkte: von 29,4 auf 38,4, September bis November 2025
+38 %
30-Tage-Conversion der Mobile App im Q3 gegenüber dem Vorjahr
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.
05
Was die Arbeit zusammenbringt
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.
Grundlage: Nora_Wiemann_Praxisprofil_Voice_of_Customer.pdf · 25.10.2026; Nora_Wiemann_CV_LinkedIn_optimiert.pdf · Version 1, 27.10.2026
Vorhandenes Research schneller für neue Produktfragen nutzen.
Research-Erkenntnisse sollten auch für neue Produktfragen nutzbar sein. Ich verantwortete die fachliche Struktur, Evidenzregeln und Freigabe eines Research-Repositorys. Engineering setzte die technische Grundlage um. Ein Research-Assistent kann dadurch auf freigegebenes Wissen mit nachvollziehbarer Herkunft zugreifen.
Kontext
Knuddels · Forschungs- und Wissensumgebung · Stand September 2026
Meine Rolle
Struktur, Formate, Evidenzregeln, Research-Prozesse, Codebücher und fachliche Freigabe
Stand
Repository und Research-Assistent im Einsatz: erste Opportunity-Hypothesen für eine konkrete Anfrage innerhalb von Stunden. Weitergehende Automatisierung im Ausbau.
Mein Beitrag
Ich verantwortete die fachliche Struktur, Formate und Evidenzregeln sowie Research-Prozesse, Codebücher und die Freigabe von Forschungsartefakten. Die technische Umsetzung einschließlich Zugriffsmechanik lag bei Engineering. Zielbild und Ressourcen wurden mit dem CTO abgestimmt; den Anschluss an den Produktprozess gestaltete ich mit Produkt und Engineering.
01Quelle & Kontext
Herkunft, Geltung und Belege festhalten
Bei fehlender Evidenz ist „nicht beantwortbar“ eine zulässige Antwort.
02Fachliche Freigabe
Aussagen und Codes prüfen
03Nutzbare Antwort
Evidenz und Grenzen zusammen nennen
Fachliches Modell aus der Arbeitsprobe. Der Research-Assistent arbeitet auf freigegebenen Ergebnissen, nicht auf Rohinterviews.
01
Eine Aussage braucht Herkunft und Geltung
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.
02
KI braucht fachliche Regeln und menschliche Freigabe
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.
03
Vorhandener Stand und nächster Ausbau
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.
04
Konkreter Nutzen im Produktalltag
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.
Grundlage: 04_Nora_Wiemann_Arbeitsprobe_WissensDB_und_FCB_DE.pdf · September 2026, Seite 1 · Ergänzende Praxiserfahrung von Nora Wiemann: 27. Oktober 2026