Versionshinweise in hilfreiche In-App-Ankündigungen umwandeln.
Eine In-App-Ankündigung sollte die Änderung dort erklären, wo sie zählt. Übertrage Release-Begriffe auf die Nutzeraufgabe, ohne Vorteile zu erfinden.
Passe den Ablauf an deine Aufgabe an.
Bestimme die betroffene Aufgabe und erkläre die Änderung an der passenden Stelle. Nenne die echte nächste Aktion und lass interne Implementierungsbegriffe weg, außer sie helfen bei der Entscheidung.
- Was du bereitstellst
- Versionshinweise und betroffene Nutzergruppen.
- Was du erhältst
- Kontextbezogene Produktankündigung und Upgrade-Anleitung.
Sieh dir Eingabe und Ergebnis an.
Beispielhafte Ein- und Ausgabe · ein Lehrbeispiel, kein tatsächlicher WebAct-Durchlauf
Beispiel Eingabe
Release adds a duplicate-SKU warning in the import preview. The warning opens the affected rows. Write a short in-app announcement with the actual action.
Vollständiges Beispiel
Review duplicate SKUs before importing The import preview now flags repeated SKU values. Open the warning to inspect the affected rows and resolve ambiguous matches before continuing. Action: Review duplicate rows
Lade diese Eingabe in den Prompt und kopiere ihn zum Ausprobieren nach WebAct. Dein Ergebnis kann vom Beispiel abweichen.
Entscheidungen und Fehlerbehebung.
Sollte jedes Changelog-Detail eine In-App-Ankündigung werden?
Wähle Änderungen, die in diesem Kontext Kenntnis oder Handeln verlangen. Kleine interne Änderungen rechtfertigen möglicherweise keine Unterbrechung.
Warum klingt die Ankündigung hilfreich, lässt aber den Handlungsort offen?
Nenne den betroffenen Bildschirm oder die Aktion und gleiche dies mit dem veröffentlichten Verhalten ab. Kündige keine Fähigkeit an, bevor ihr Zugangsweg verfügbar ist.
Probiere es mit deiner eigenen Quelle.
Ersetze das Beispiel im Aufgaben-Prompt durch dein Material. Behalte nötige Anforderungen bei und kopiere die Aufgabe nach WebAct.
Aufgabe anpassen und kopieren ↑