Zum Inhalt springen
← Impulse

So entscheiden Sie, welche Aktionen Nutzer in einer Anwendung rückgängig machen können

Ein praxisnaher Rahmen hilft zu entscheiden, wann Nutzer Aktionen rückgängig machen, wiederherstellen oder korrigieren können – abhängig von Auswirkungen, Wiederherstellungskosten und verbundenen Systemen.

Oberfläche eines digitalen Produkts mit Optionen zum Rückgängigmachen, Wiederherstellen oder Korrigieren einer Aktion

Eine Funktion zum Rückgängigmachen scheint einfach, bis eine Aktion bereits eine Benachrichtigung versendet, eine Zahlung ausgelöst oder ein anderes System aktualisiert hat. In solchen Fällen kann es unmöglich, nur teilweise möglich oder sogar schädlich sein, zum vorherigen Zustand zurückzukehren. Welche Aktionen umkehrbar sein sollen, entscheidet sich deshalb nicht dadurch, dass auf jedem Bildschirm eine Schaltfläche ergänzt wird. Es muss klar sein, was sich ändert, wer von dieser Änderung abhängt und welche Wiederherstellung praktikabel ist.

Für Verantwortliche aus Produktmanagement, Design und Technik ergibt sich die richtige Entscheidung aus den Auswirkungen, der Erkennbarkeit eines Fehlers, den Kosten der Behebung und den Folgen außerhalb der Anwendung. Ziel ist nicht das Versprechen, alles rückgängig machen zu können. Nutzer sollen vielmehr einen klaren und sicheren Ausweg erhalten, wenn ihnen ein Fehler unterläuft – ohne dass die tatsächlichen Grenzen des Systems verschleiert werden.

Was bedeutet es, wenn eine Aktion umkehrbar ist?

Was bedeutet es, wenn eine Aktion umkehrbar ist?

Eine Aktion ist umkehrbar, wenn das Produkt nach ihrer Ausführung wieder einen akzeptablen Zustand herstellen kann. Das bedeutet nicht immer, dass die ursprüngliche Änderung buchstäblich rückgängig gemacht wird. Ein gelöschter Datensatz lässt sich beispielsweise wiederherstellen, wenn er für einen festgelegten Zeitraum im Papierkorb bleibt. Eine versendete E-Mail hingegen bleibt versendet, selbst wenn der Datensatz, der sie ausgelöst hat, wiederhergestellt wird.

Es ist hilfreich, vier Ergebnisse zu unterscheiden:

  • Rückgängig machen: Eine kürzlich ausgeführte Aktion abbrechen oder ausgleichen, üblicherweise direkt im selben Kontext.
  • Wiederherstellen: Eine frühere Version oder einen vorherigen Zustand aus einem Verlauf oder Papierkorb zurückholen.
  • Korrigieren: Eine neue Aktion erfassen, die den Fehler ausgleicht, ohne den vorherigen Vorgang zu löschen.
  • Nicht rückgängig machen: Die Änderung beibehalten und einen alternativen Weg anbieten, etwa eine Überprüfung anzufordern oder den Support zu kontaktieren.

Diese Unterscheidung prägt die Erwartungen. Wählt ein Nutzer „Rückgängig“, erwartet er, dass die Wirkung verschwindet. Haben sich manche Auswirkungen bereits weiterverbreitet, muss die Oberfläche erklären, was rückgängig gemacht wurde und was nicht. Eine mehrdeutige Schaltfläche kann mehr Schaden anrichten, als gar keine entsprechende Funktion anzubieten.

Auswirkungen, Erkennbarkeit und Wiederherstellungskosten einordnen

Bevor Sie ein Interaktionsmuster auswählen, sollten Sie die Aktion anhand von drei Fragen einordnen. Erstens: Welche Folgen hätte ein Fehler? Berücksichtigen Sie die Zahl der betroffenen Daten und Personen, die Sensibilität der Informationen sowie wirtschaftliche und operative Folgen. Zweitens: Wie lange dauert es wahrscheinlich, bis jemand den eigenen Fehler bemerkt? Drittens: Wie aufwendig ist es, einen korrekten Zustand wiederherzustellen – gemessen an Zeit, Arbeit und dem Risiko von Inkonsistenzen?

Eine persönliche Einstellung hat meist begrenzte Auswirkungen und lässt sich leicht korrigieren. Wird ein gemeinsam genutzter Bereich gelöscht, kann das ein ganzes Team betreffen. Eine Änderung von Berechtigungen kann anderen den Zugriff entziehen. Bei einer Finanztransaktion oder einer versendeten Mitteilung verschwinden externe Folgen nicht dadurch, dass der lokale Datensatz wiederhergestellt wird.

Nutzen Sie diese Faktoren als Orientierung, nicht als allgemeingültige Punktzahl. Sind die Auswirkungen gering und ist die Wiederherstellung sofort möglich, reicht unter Umständen eine gut sichtbare Gegenaktion. Wird ein Fehler erst spät entdeckt oder erfordert die Wiederherstellung, Informationen neu zusammenzutragen, sind ein Verlauf, ein Papierkorb oder eine Wiederherstellungsfunktion mit klaren Grenzen sinnvoll. Bei externen Auswirkungen sollte das Produkt einen Ausgleich oder Korrekturprozess vorsehen und erklären, dass dieser nicht einer Rückkehr zum vorherigen Zustand entspricht.

Fragen Sie auch, wer die Wiederherstellung veranlassen und abschließen kann. Darf nur eine administrative Person eine Aktion wiederherstellen, ist die Umkehrbarkeit zwar technisch gegeben, aber für die Person, der der Fehler unterlaufen ist, möglicherweise kein praktikabler Ausweg.

Das passende Muster zum Rückgängigmachen auswählen

Sofortiges Rückgängigmachen eignet sich, wenn die Aktion gerade ausgeführt wurde, der vorherige Zustand erhalten ist und das System die Wirkung sicher aufheben kann. Das passt zu lokalen oder leicht ausgleichbaren Änderungen. Die Funktion sollte für einen nachvollziehbaren Zeitraum verfügbar sein und nicht davon abhängen, dass Nutzer eine versteckte Tastenkombination kennen.

Verlauf oder Papierkorb ist besser geeignet, wenn ein Fehler möglicherweise erst später auffällt. Nutzer können nachvollziehen, was sich geändert hat, und Elemente wiederherstellen. Dafür müssen jedoch Aufbewahrungsdauer, Berechtigungen, Sichtbarkeit und das Verhalten bei Wiederherstellungen festgelegt werden. Bezeichnen Sie keinen Vorgang als „Wiederherstellen“, wenn er nur einen Teil der Daten zurückholt, ohne zu erklären, was davon ausgenommen ist.

Eine neue Korrekturaktion ist vorzuziehen, wenn das Löschen der Spuren irreführend wäre oder Beziehungen zu anderen Systemen zerstören könnte. Beispielsweise lässt sich eine Korrektur erfassen, die eine frühere Transaktion ausgleicht und gleichzeitig den Verlauf bewahrt. Nutzer müssen verstehen, wie die beiden Aktionen zusammenhängen und ob auch die Korrektur genehmigt werden muss.

Kein direktes Rückgängigmachen kann sinnvoll sein, wenn die Umkehrung ein größeres Risiko schafft als der unveränderte Zustand oder eine externe Wirkung bereits unumkehrbar ist. Bieten Sie dann eine konkrete Alternative an: noch ausstehende Schritte stoppen, Daten korrigieren, einen Einspruch einleiten oder eine Überprüfung anfordern. Lautet die einzige Antwort „Das kann nicht rückgängig gemacht werden“, wird die gesamte Last auf die Nutzer verlagert.

Externe Auswirkungen und verbundene Systeme berücksichtigen

Eine B2B-Anwendung arbeitet selten isoliert. Eine Aktion kann eine Integration aktualisieren, eine Automatisierung auslösen, eine Benachrichtigung versenden oder einen Prozess starten, den eine andere Person bereits genutzt hat. Zeichnen Sie vor dem Anbieten einer Wiederherstellung die gesamte Abfolge nach: Was ändert sich im Produkt, was wird nach außen übermittelt und welche Systeme bestätigen oder verzögern diese Änderungen?

Trennen Sie, wenn möglich, Vorbereitung und Ausführung. Eine Vorschau, eine kontextbezogene Bestätigung oder eine Warteschlange mit Abbruchmöglichkeit kann Fehler verhindern, bevor sie das System verlassen. Vermeiden Sie jedoch wiederholte Bestätigungen ohne zusätzlichen Informationswert. Bauen Sie Reibung nur bei Aktionen ein, deren Auswirkungen sie rechtfertigen, und zeigen Sie konkrete Angaben wie Umfang oder Empfänger.

Ist eine Synchronisierung bereits abgeschlossen, muss klar zwischen der Wiederherstellung des eigenen Zustands und einer ausgleichenden Aktion im verbundenen System unterschieden werden. Letztere kann fehlschlagen oder verspätet eintreffen. Kommunizieren Sie den Status – ausstehend, abgeschlossen oder fehlgeschlagen – und behaupten Sie nicht, alles sei korrigiert, bevor ausreichende Bestätigung vorliegt. Legen Sie außerdem fest, was geschieht, wenn das externe System nicht erreichbar ist.

Berechtigungen, Fristen und Änderungsprotokolle

Grenzen für die Wiederherstellung sollten Zuständigkeiten und Risiken widerspiegeln. Legen Sie fest, wer Aktionen rückgängig machen, wiederherstellen oder korrigieren darf, ob eine Genehmigung erforderlich ist und wie lange die Wiederherstellung möglich bleibt. Wählen Sie keine beliebige Frist: Berücksichtigen Sie betriebliche Anforderungen, die Sensibilität der Daten und den Aufwand, frühere Zustände aufzubewahren.

Ein Protokoll sollte erkennen lassen, was sich geändert hat, wer die Änderung vorgenommen hat, wann sie erfolgte und welche Wiederherstellung ausgeführt wurde. Es muss nicht allen Nutzern sensible Informationen offenlegen. Richten Sie den Zugriff auf den Verlauf nach denselben Berechtigungsregeln aus wie den Zugriff auf die ursprünglichen Daten. Achten Sie außerdem darauf, dass die Wiederherstellung eines Elements keine Berechtigungen verleiht, die nicht mehr angemessen sind.

Erklären Sie Grenzen, bevor sie überraschend zutage treten. Lässt sich eine Aktion ab einem bestimmten Zeitpunkt nicht mehr wiederherstellen, informieren Sie im passenden Kontext darüber. Eine Bestätigung ist hilfreich, wenn sie eine fundierte Entscheidung ermöglicht. Sie ersetzt jedoch weder eine praktikable Wiederherstellung noch macht sie Nutzer dafür verantwortlich, eine unsichere Erfahrung auszugleichen.

Gleichzeitige Bearbeitung und spätere Änderungen testen

Funktionen zum Rückgängigmachen scheitern häufig in Szenarien, die in einer linearen Produktdemo nicht vorkommen. Testen Sie, was passiert, wenn eine andere Person dasselbe Objekt zwischen der ursprünglichen Aktion und der Wiederherstellung bearbeitet. Wird eine alte Version ohne Prüfung späterer Änderungen wiederhergestellt, kann das System legitime Arbeit löschen. Legen Sie fest, ob der Vorgang blockiert, ein Vergleich angezeigt oder nur ein Teil wiederhergestellt wird.

Testen Sie auch teilweise Wiederherstellungen, erneute Versuche nach einem Fehler, doppelte Aktionen sowie gelöschte oder geänderte Abhängigkeiten. Prüfen Sie bei verbundenen Abläufen, was geschieht, wenn ein Teil erfolgreich ist und ein anderer fehlschlägt. Die Oberfläche muss das tatsächliche Ergebnis beschreiben, statt einen Vorgang als abgeschlossen darzustellen, wenn nur der lokale Zustand wiederhergestellt wurde.

Beobachten Sie nach der Einführung relevante Signale: die häufige Nutzung von „Rückgängig“, fehlgeschlagene Wiederherstellungen, Supportanfragen, wiederholte Korrekturen und die Zeit bis zur Entdeckung von Fehlern. Eine hohe Zahl an Wiederherstellungen kann bedeuten, dass die Funktion nützlich ist. Sie kann aber auch auf eine unklare Aktion, eine unzureichende Vorschau oder einen riskanten Standardwert hindeuten. Untersuchen Sie zunächst den Kontext, bevor Sie weitere Bestätigungen einführen.

Checkliste vor der Einführung

Checkliste vor der Einführung
  1. Welche Daten und Personen sind betroffen, und was wäre der schlimmste plausible Fehler?
  2. Wie lange kann es dauern, bis ein Fehler entdeckt wird, und wer wird ihn bemerken?
  3. Lässt sich der vorherige Zustand wiederherstellen, ohne spätere Änderungen zu verlieren?
  4. Sind Benachrichtigungen, Zahlungen, Automatisierungen oder externe Synchronisierungen beteiligt?
  5. Sollte die Aktion rückgängig gemacht, wiederhergestellt oder korrigiert werden – oder muss erklärt werden, dass keine Umkehrung möglich ist?
  6. Wer darf die Aktion wiederherstellen, und für welchen Zeitraum?
  7. Vermittelt die Oberfläche genau, was wiederhergestellt wurde und was nicht?
  8. Wurden gleichzeitige Bearbeitung, Teilausfälle, Berechtigungen und erneute Versuche getestet?
  9. Welche Signale werden nach der Einführung überprüft, um Designfehler zu erkennen?

Die beste Strategie für umkehrbare Aktionen maximiert nicht die Zahl der Schaltflächen, sondern verringert wahrscheinliche Schäden und bietet eine verständliche Wiederherstellung. Wenn sich ein Vorgang nicht rückgängig machen lässt, ist eine nachvollziehbare und ehrliche Korrektur meist besser als ein Versprechen, das das System nicht halten kann.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev