Genehmigungsmatrix vor der UI gestalten: Regeln vor Bildschirmen abbilden

Warum Bildschirme ohne klare Matrix scheitern

Eine saubere Oberfläche kann trotzdem einen unordentlichen Prozess verbergen. Wenn die Genehmigungslogik nicht zuerst definiert wird, sehen die Leute vielleicht Schaltflächen für Genehmigen und Ablehnen, wissen aber nicht, wer handeln soll, wann gehandelt werden muss oder was danach passiert.

Diese Verwirrung zeigt sich schnell in der täglichen Arbeit. Jemand reicht eine Anfrage ein, sie landet in der App, und die erste Frage lautet: "Geht das an die Führungskraft, an die Buchhaltung oder an beide?" Der Bildschirm sieht fertig aus, aber der Entscheidungsweg fehlt.

Das passiert, weil Bildschirme Regeln oft einfacher aussehen lassen, als sie sind. Ein Formular kann Status, Kommentare und Aktionsbuttons zeigen, aber nicht die zugrundeliegende Genehmigungsmatrix erraten. Wenn das Unternehmen Betragsgrenzen, Abteilungsregeln oder temporäre Stellvertreter hat, beginnt die UI zu versagen, sobald solche Fälle auftreten.

Oft reicht eine einzige Ausnahme, damit die Arbeit außerhalb der App weiterläuft. Gewöhnlich gehen Genehmigungen an einen Abteilungsleiter, außer die Anfrage ist dringend, über einem bestimmten Betrag oder der Genehmigende ist abwesend. Wenn dieser Fall nie erfasst wurde, fällt man auf E-Mail, Chat oder Tabellenkalkulationen zurück.

Dann entsteht ein größeres Problem: Jedes Team wendet seine eigene Version der Regeln an. Operations schickt Anfragen auf eine Weise, Finance auf eine andere, und der Support behandelt Ausnahmen anders als HR. Die App wird zu einem gemeinsamen Bildschirm für inkonsistente Entscheidungen, statt zu einem gemeinsamen Prozess.

Warnsignale sind meist leicht zu erkennen:

• Benutzer fragen, wer den nächsten Schritt besitzt
• ähnliche Anfragen haben unterschiedliche Ergebnisse teamübergreifend
• Ausnahmen werden in Chat oder E-Mail geklärt
• Policy-Änderungen erzwingen UI-Änderungen statt Regeländerungen

Policy-Updates legen diese Schwäche schnell offen. Wenn die Logik in der Oberfläche statt in klaren Workflow-Regeln lebt, wird jede Schwellenwert- oder Rollenänderung zur UI-Neuentwicklung. Das verlangsamt Teams, erzeugt neue Fehler und lässt die Nutzer Vertrauen verlieren.

Der Bildschirm sollte den Entscheidungsweg widerspiegeln, nicht ihn definieren. Wenn die Matrix zuerst klar ist, wird die UI einfacher, stabiler und leichter zu benutzen.

Was Sie vor jedem Wireframe abbilden sollten

Beginnen Sie mit der Entscheidungslogik, nicht mit dem Bildschirm. Eine solide Genehmigungsmatrix entsteht als einfache Tabelle, die zeigt, wer was genehmigen kann, unter welchen Bedingungen und was passiert, wenn jemand nicht verfügbar ist. Ist diese Logik unklar, verwirrt selbst eine ausgefeilte Oberfläche die Menschen.

Für jeden Anfragetyp kartieren Sie die Genehmigungsstufen in der Reihenfolge. Notieren Sie die Rolle, die jeden Schritt besitzt, und was dieser Schritt erlaubt: genehmigen, ablehnen, prüfen oder zurückschicken. Rollen funktionieren besser als Namen, weil Menschen wechseln, Teams sich verändern und der Prozess trotzdem hält.

Definieren Sie dann die Regeln, die die Route verändern. Betrag ist der offensichtliche Auslöser, aber selten der einzige. Genehmigungslogik hängt oft von Region, Abteilung, Lieferantentyp, Anfragekategorie oder Risiko ab. Derselbe Betrag kann in einem Team Routine und in einem anderen sensibel sein.

Abwesenheiten brauchen ebenfalls Regeln. Wenn der Hauptgenehmigende nicht da ist, wer übernimmt sofort? Ist der Ersatz temporär, welche Daten gelten? Ohne das stehen Anfragen, weil niemand weiß, wer diese Woche zuständig ist.

Zeitlimits sind genauso wichtig. Entscheiden Sie, was passiert, wenn keine Antwort erfolgt. Vielleicht senden Sie nach einem Tag eine Erinnerung, nach zwei Tagen eine Eskalation und benachrichtigen nach drei Tagen Operations. Diese Entscheidungen beeinflussen Status-Labels, Benachrichtigungen und Warteschlangenansichten, daher sollten sie vor dem Bildschirmdesign getroffen werden.

Eine praktische Matrix beantwortet in der Regel fünf Grundfragen:

• Welche Bedingung startet diese Regel?
• Welche Rolle genehmigt auf dieser Stufe?
• Wer ist der Backup?
• Wie viel Zeit hat der Genehmigende zum Handeln?
• Was passiert, wenn die Frist verpasst wird?

Wenn Sie diese Antworten früh festlegen, wird der Rest des Aufbaus deutlich einfacher.

Wie man die Matrix Schritt für Schritt erstellt

Nutzen Sie eine Tabelle, ein Whiteboard oder ein Spreadsheet. Halten Sie es so einfach, dass ein Manager, Teamleiter und Prozessverantwortlicher alles in einem Durchgang verstehen.

Listen Sie zuerst jeden Anfragetyp auf, der eine Genehmigung benötigt. Versuchen Sie nicht, alles in einen generischen Ablauf zu zwängen, wenn das Unternehmen Anfragen bereits unterschiedlich behandelt. Eine Bestellanforderung, Rückerstattung, Rabattgenehmigung und Zugriffsanfrage benötigen oft verschiedene Genehmigende, Limits und Fristen.

Schreiben Sie als Nächstes den ersten Genehmigenden und dann jeden Entscheidungs-Punkt danach auf. Für jeden Anfragetyp notieren Sie, wer zuerst prüft und was nach Genehmigung oder Ablehnung passiert. Folgen Sie dem Pfad bis zu einem Endergebnis wie genehmigt, abgelehnt, zur Überarbeitung zurückgeschickt oder storniert.

Fügen Sie danach die Schwellenwerte hinzu, die die Route ändern. Hier bleiben viele Teams später hängen. Wenn eine Anfrage unter 500 $ an einen Teamleiter geht, alles darüber an einen Abteilungsleiter, schreiben Sie das jetzt auf. Wenn dringende Anfragen einen Schritt überspringen oder einen schnelleren Pfad folgen, erfassen Sie das ebenfalls.

Dokumentieren Sie dann Ausnahmen, Fristen und Endzustände. Schließen Sie Fälle wie fehlende Dokumente, doppelte Anfragen, Policy-Verstöße und überfällige Genehmigungen ein. Die Regel ist erst fertig, wenn Sie wissen, wie sie sich verhält, wenn etwas schiefgeht.

Überprüfen Sie den Entwurf abschließend mit den Personen, die heute Anfragen genehmigen. Fragen Sie, wo Arbeit normalerweise stockt, wo Schritte übersprungen werden und was passiert, wenn der übliche Genehmigende nicht verfügbar ist. Tatsächliche Gewohnheiten decken oft Regeln auf, die nie dokumentiert wurden.

Ein kleines Beispiel macht das deutlich. Stellen Sie sich eine Bestellanforderung vor: Büromaterial bis 200 $ geht an den Teamleiter, Software zwischen 200 $ und 2.000 $ an den Abteilungsleiter, und alles darüber braucht zusätzlich Finance. Wenn das Formular Betrag und Kategorie nicht früh erfasst, kann die UI die Anfrage nicht korrekt routen.

Schwellenwerte festlegen, denen Menschen wirklich folgen können

Schwellenwerte funktionieren nur, wenn Menschen sie schnell lesen und jedes Mal gleich anwenden können. Wenn eine Regel "kleine Käufe" oder "hochriskante Lieferanten" sagt, interpretieren verschiedene Personen das unterschiedlich. Verwenden Sie feste Zahlen, Daten und benannte Bedingungen.

Eine klarere Regel lautet: "Bis zu 1.000 $ geht an den Teamleiter. 1.001 $ bis 5.000 $ geht an den Abteilungsleiter. Über 5.000 $ geht an Finance und die Direktion." Niemand muss raten, wohin die Anfrage gehört.

Betrag ist üblich, sollte aber nicht der einzige Auslöser sein, wenn Ihr Prozess von anderen Faktoren abhängt. Ein kostengünstiger Softwarekauf von einem neuen Lieferanten kann mehr Prüfung benötigen als eine größere Bestellung von einem genehmigten Anbieter.

Die meisten Teams benötigen nur eine kleine Menge Routing-Regeln. Häufige Beispiele sind Betragsbereich, Lieferantenstatus, Einkaufskategorie, Abteilung und Dringlichkeit. Wichtiger als die Anzahl der Regeln ist, ob alle sie gleich anwenden.

Die Reihenfolge der Regeln ist ebenfalls wichtig. Wenn niemand weiß, welche Bedingung Vorrang hat, routen sie dieselbe Anfrage unterschiedlich. Wählen Sie eine Reihenfolge und halten Sie sie konsistent. Sie könnten zuerst den Lieferantenstatus prüfen, dann die Kategorie, dann den Betrag. Oder Sie prüfen zuerst den Betrag und behandeln Ausnahmen danach. Beide Ansätze funktionieren, wenn alle derselben Reihenfolge folgen.

Definieren Sie auch, wer einen Schwellenwert außer Kraft setzen kann und wann. Andernfalls warten Mitarbeiter zu lange oder umgehen den Prozess per E-Mail und Chat. "Der Finance-Direktor darf überlimitige Anfragen während Monatsabschluss genehmigen" ist nützlich. "Das Senior Management kann Ausnahmen machen" ist zu vage.

Ein einfacher Test hilft: Geben Sie drei Personen dieselbe Beispielanfrage und fragen Sie, wohin sie gehen sollte. Wenn Sie drei verschiedene Antworten bekommen, sind die Schwellenwerte noch zu unklar.

Fallback-Genehmigende, Stellvertreter und Eskalationen planen

Eine starke Matrix endet nicht beim Hauptgenehmigenden. Die tatsächliche Arbeit läuft weiter, wenn jemand im Urlaub ist, krank oder einfach nicht rechtzeitig reagiert. Wenn Sie das nicht früh planen, sieht der Bildschirm ordentlich aus, der Prozess steht aber still.

Nennen Sie für jeden wichtigen Schritt den Fallback-Genehmigenden. Das sollte eine Person oder Rolle mit dem entsprechenden Kontext sein, nicht einfach "der nächste Manager" per Default. Wenn ein Finance-Lead Ausgaben über einem bestimmten Betrag genehmigt, legen Sie fest, wer einspringt, wenn diese Person nicht verfügbar ist.

Temporäre Stellvertreter brauchen Grenzen. Ein Stellvertreter sollte nur für einen definierten Zeitraum Genehmigungsrechte erhalten, z. B. Urlaubsdaten oder geplante Abwesenheit. Das hält die Verantwortlichkeit klar und verhindert, dass jemand lange nach Ablauf weiter genehmigt.

Eine einfache Struktur sollte vier Dinge beantworten: Wer ist der Hauptgenehmigende, wer ist die Vertretung, wie lange darf der Stellvertreter handeln und wann wird die Anfrage weiter oben eskaliert.

Eskalationen sollten auf klaren Auslösern basieren, nicht auf Vermutungen. Gängige Auslöser sind Zeit, Betrag, Risiko oder fehlende Informationen. Beispielsweise kann eine Bestellung über 10.000 $, die 24 Stunden lang unbeachtet bleibt, an den Abteilungsleiter eskalieren.

Halten Sie den Eskalationsweg kurz. Brauchen Menschen ein komplexes Diagramm, um zu verstehen, wer als Nächstes die Anfrage bekommt, ist die Regel wahrscheinlich zu kompliziert. Ein oder zwei klare Sprünge reichen meist.

Dokumentieren Sie jede Entscheidung. Speichern Sie, wer genehmigt hat, wer vertreten hat, wann die Übergabe stattfand und warum die Anfrage eskaliert wurde. Diese Historie ist wichtig, wenn später gefragt wird, warum etwas verzögert oder von einem Stellvertreter genehmigt wurde.

Eine weitere wichtige Regel: Vermeiden Sie Schleifen. Eine Anfrage sollte nie zu jemandem zurückspringen, der sie bereits genehmigt hat, oder zu einem Stellvertreter für dieselbe Person. Prüfen Sie die Matrix auf zyklische Pfade, bevor Sie Logik in einer App umsetzen.

Ein einfaches Beispiel: Genehmigung einer Bestellanforderung

Stellen Sie sich ein kleines Unternehmen vor, das alltägliche Artikel kauft. Ein Mitarbeiter reicht eine Anfrage mit Artikel, Betrag, Begründung und benötigtem Datum ein. Die Weiterleitung folgt den Regeln, nicht dem, wer gerade online ist.

Bei 420 $ geht die Anfrage direkt an den Teamleiter. So bleiben kleine Käufe in Bewegung. Eine Anfrage über 3.200 $ umgeht den Teamleiter und geht an den Abteilungsleiter, weil die Budgetauswirkung größer ist.

Bei 7.800 $ für neue Geräte prüft zwar der Abteilungsleiter noch, aber das reicht nicht aus. Da der Betrag über 5.000 $ liegt, muss Finance ebenfalls prüfen. Hier hilft eine klare Matrix: höhere Beträge fügen Kontrolle hinzu, ohne Ratespiele zu erzeugen.

Abwesenheiten sind auch hier wichtig. Ist der Abteilungsleiter im Urlaub, sollte die Anfrage nicht liegen bleiben. Ein benannter Stellvertreter erhält sie automatisch und kann für den definierten Zeitraum handeln.

Zeitlimits brauchen ebenso Klarheit. Reagiert niemand innerhalb von zwei Tagen, eskaliert die Anfrage an Operations. Operations kann nachfassen, neu zuweisen oder sicherstellen, dass die Arbeit nicht blockiert wird.

In diesem Beispiel beantwortet die Matrix einfache, aber wichtige Fragen: Wie hoch ist der Betrag, welche Rolle genehmigt bei welchem Betrag, wann wird Finance hinzugezogen, wer deckt Abwesenheiten ab und was passiert bei Fristüberschreitung.

Sind diese Antworten definiert, wird das Bildschirmdesign unkompliziert. Das Formular braucht nur die richtigen Daten, und die Anfrageseite muss nur den aktuellen Genehmigenden, etwaige Stellvertreter und den Eskalations-Timer anzeigen.

Häufige Fehler, die Nacharbeit verursachen

Die meisten Nacharbeiten beginnen, bevor auch nur ein Screen entworfen wurde. Teams raten den Genehmigungsweg und versuchen dann, die UI an Regeln anzupassen, die nie wirklich vereinbart wurden.

Ein häufiger Fehler ist, das Organigramm zu kopieren und es Workflow zu nennen. Das wirkt ordentlich, aber echte Anfragen bewegen sich oft nach Betrag, Risiko, Standort oder Anfragetyp. Ignoriert die Matrix das, brauchen die Screens später zusätzliche Felder, Zustände und umständliche Ausnahmen.

Ein weiteres Problem ist, spezielle Fälle zu vergessen. Dringende Anfragen, regulierte Einkäufe oder bereichsübergreifende Anfragen brauchen oft eine andere Route. Werden diese Ausnahmen nicht frühzeitig abgebildet, verlangen Menschen manuelle Workarounds, und die Oberfläche füllt sich mit Einmal-Optionen, die alle verwirren.

Schwierigkeiten entstehen auch, wenn zwei Personen die gleiche Rolle bekommen ohne Tiebreak-Regel. Können beide genehmigen, wer handelt zuerst? Stimmen sie nicht überein, wessen Entscheidung gilt? Ohne Antwort springen Anfragen hin und her und Nutzer verlieren Vertrauen.

Stellvertreter-Regeln sind ein weiterer Schwachpunkt. Ein Stellvertreter soll eine Abwesenheit abdecken, nicht stillschweigend dauerhafter Besitzer werden. Vermischt man temporäre Vertretung und permanente Zuständigkeit, werden Berichte unübersichtlich und Verantwortlichkeit verschwindet.

Formulare zu gestalten, bevor das Routing geklärt ist, führt zu zusätzlicher Arbeit. Ein Formular mag vollständig aussehen, aber sobald die Genehmigungsregeln final sind, fehlen oft Felder wie Betragsband, Abteilung, Dringlichkeit oder Policy-Flag. Dann müssen Layout, Validierung und Benachrichtigungen geändert werden.

Ein kurzer Reality-Check hilft, das früh zu erkennen:

• Können zwei Genehmigende dieselbe Anfrage gleichzeitig erhalten?
• Gibt es einen klaren Unterschied zwischen temporärer Vertretung und permanenter Zuständigkeit?
• Folgen dringende oder regulierte Fälle einem anderen Weg?
• Hängt jede Routing-Entscheidung von einem Feld ab, das bereits existiert?
• Würde der Prozess noch Sinn ergeben, wenn ein Genehmigender das Unternehmen verlässt?

Ist eine dieser Antworten unklar, stoppen Sie. Korrigieren Sie die Matrix, bevor Sie die Screens verfeinern.

Schnelle Prüfungen, bevor Sie die Bildschirme entwerfen

Bevor Sie ein Formular oder ein Status-Badge skizzieren, testen Sie die Logik in Klartext. Eine gute Genehmigungsmatrix sollte sich leicht erklären lassen, ohne ein Diagramm zu öffnen. Kann ein Manager, Finance-Lead oder Operations-Kollege die Route nicht in etwa einer Minute beschreiben, ist der Prozess zu vage für UI-Arbeiten.

Führen Sie eine schnelle Überprüfung mit realen Beispielen durch. Lassen Sie eine Person den kompletten Weg von Anfrage bis zur endgültigen Entscheidung erklären. Prüfen Sie, dass jedes wahrscheinliche Ergebnis einen benannten nächsten Genehmigenden hat, nicht nur den Happy Path. Formulieren Sie vage Schwellenwerte als genaue Regeln wie "1.000 $ und darunter" oder "mehr als 10 % Rabatt." Bestätigen Sie, dass Fallback- und Eskalationsregeln klare Zeitlimits verwenden wie "nach 24 Stunden" oder "nach 2 Arbeitstagen."

Testen Sie dann die Rückverfolgbarkeit. Später wird jemand fragen, warum eine Anfrage verzögert war, wer eine Ausnahme genehmigt hat oder wann ein Stellvertreter einsprang. Ihr Prozess sollte diese Fragen bereits beantworten. Zeitstempel, Entscheidungsverlauf und klare Statusänderungen sind keine Extras. Sie gehören zur Regeldefinition.

Ein einfaches Szenario deckt Schwachstellen auf. Stellen Sie sich eine Anfrage über 4.800 $ vor, die freitagnachmittags eintrifft, während der übliche Genehmigende abwesend ist. Wer bekommt sie als Nächstes? Wie lange wartet das System, bevor es weiterleitet? Was passiert, wenn auch der Backup nichts tut? Sind diese Antworten nicht schriftlich festgehalten, verschleiert die UI die Verwirrung statt sie zu lösen.

Wenn diese Prüfungen bestanden sind, wird das Bildschirmdesign deutlich einfacher. Sie raten nicht mehr, welche Informationen die Oberfläche zeigen soll, sondern Sie geben einer klaren Regel eine klare Form.

Nächste Schritte: Die Matrix in eine funktionierende App überführen

Sind die Regeln klar, bauen Sie den Prozess, bevor Sie die Bildschirme polieren. Beginnen Sie mit der Logik, den Datenfeldern und den Genehmigungszuständen. Wenn das Routing funktioniert, lässt sich die Oberfläche viel leichter gestalten. Ist das Routing noch im Fluss, kaschieren ansprechende Bildschirme nur die Probleme.

Eine praktische erste Version enthält meist das Nötigste: Anfragetyp, Betrag, Abteilung, aktueller Genehmigender, Endstatus und eine klare Historie jeder Entscheidung. Fügen Sie dann die Regeln hinzu, die eine Anfrage weiterbewegen, an einen Fallback-Genehmigenden senden oder eine Eskalation auslösen, wenn jemand nicht rechtzeitig reagiert.

Halten Sie die ersten Bildschirme simpel. Ein Antragstellender sollte einreichen, den Status prüfen und auf Rückfragen antworten können. Ein Genehmigender sollte prüfen, genehmigen, ablehnen oder neu zuweisen können. Das reicht, um zu testen, ob der Workflow im Alltag funktioniert.

Eine sinnvolle Reihenfolge beim Aufbau ist:

• Definieren Sie die Kerndatenfelder und Statuswerte
• Fügen Sie Routing-Regeln für Schwellenwerte, Fallbacks, Stellvertreter und Eskalationen hinzu
• Erstellen Sie Basis-Bildschirme für Antragstellende und Genehmigende
• Stellen Sie sicher, dass alle Kanäle dieselbe Quelle der Wahrheit verwenden
• Testen Sie eine echte Anfrage von Anfang bis Ende, bevor Sie breiter ausrollen

Diese gemeinsame Quelle der Wahrheit ist wichtiger, als viele Teams erwarten. Wenn Mobile einen Status zeigt, das Web-Panel einen anderen und das Backend andere Schwellenwerte anwendet, schwindet das Vertrauen schnell.

Wenn Sie das in AppMaster aufbauen, erleichtert eine klare Matrix das Setup erheblich. Sie können zuerst die Daten, die Business-Logik und den Genehmigungsfluss modellieren und denselben Prozess dann über Backend, Web und Mobile hinweg verwenden, ohne Regeln in verschiedenen Tools neu zu schreiben.

Nutzen Sie einen echten Fall für den ersten Test. Führen Sie eine tatsächliche Bestellanforderung mit Schwellenwert, Stellvertreter und überfälliger Eskalation durch. Beobachten Sie, wo Menschen zögern, welche Daten fehlen und welche Statusbezeichnungen verwirren.

Verbessern Sie danach Wortwahl und Layout. Funktioniert der Prozess mit einer echten Anfrage, lassen sich die Bildschirme viel leichter gestalten und werden weniger wahrscheinlich eine Woche später neu aufgebaut.