Nutzerrollen und Berechtigungen: Vor dem Bauen planen

Entscheide die Rollen zuerst

Nutzerrollen und Berechtigungen lassen sich leichter planen, bevor auch nur ein einziger Bildschirm generiert wird.

Es wirkt manchmal schneller, anfangs allen den gleichen Zugriff zu geben. Praktisch führt diese Entscheidung jedoch fast sofort zu Problemen. Ein Inhaber, ein Mitarbeiter, ein Kunde und ein Administrator brauchen nicht dieselben Bildschirme, Aktionen oder Daten.

Wenn der Zugriff zu breit ist, sehen Menschen Dinge, die ihnen nicht helfen — und die manchmal überhaupt nicht sichtbar sein sollten. Ein Kunde könnte interne Notizen entdecken. Ein Mitarbeiter könnte auf Abrechnungseinstellungen zugreifen. Ein Inhaber könnte hohe Berichte und Steuerungen erwarten, landet aber auf derselben abgespeckten Ansicht, die ein Mitarbeiter an der Rezeption sieht. Selbst wenn nichts Privates offenbart wird, wirkt die App unordentlich, weil jeder Bildschirm versucht, allen zu dienen.

Dieses Problem breitet sich schnell aus. Rollen beeinflussen Menüs, Dashboards, Formulare, Genehmigungen, Berichte, Exporte und die Regeln hinter gespeicherten Daten. Eine klein klingende Regel wie „Mitarbeiter können Bestellungen ansehen, aber keine Rückerstattungen ausstellen" verändert oft viel mehr als nur einen Button. Sie kann Workflows, Benachrichtigungen, Logs und Bearbeitungsregeln im ganzen Produkt betreffen.

Späte Berechtigungsänderungen sind selten klein. Sobald falscher Zugriff eingebaut ist, änderst du nicht nur Einstellungen. Du musst Bildschirme neu gestalten, Daten verschieben, Workflows retesten und die neuen Regeln echten Nutzern erklären, die sich schon an die alten gewöhnt haben.

Ein wenig Planung zu Beginn vermeidet das meiste davon. Wenn Rollen von Anfang an klar sind, hat die App am ersten Tag eine sauberere Struktur. Inhaber erreichen Geschäftseinstellungen und Übersichtsberichte. Mitarbeiter erledigen die tägliche Arbeit, ohne Kontoeinstellungen zu berühren. Kunden sehen nur ihre eigenen Informationen. Admin-Zugriff bleibt auf die Personen beschränkt, die ihn wirklich brauchen.

Wenn du mit Koder.ai baust, ist das noch wichtiger, weil die erste Version per Chat schnell generiert werden kann. Klare Rollendefinitionen geben der Plattform bessere Anweisungen, sodass die App näher an dem startet, was das Geschäft wirklich braucht.

Die vier Rollen, die du früh festlegen solltest

Die meisten ersten Versionen kommen gut mit vier Rollen zurecht: Inhaber, Mitarbeiter, Kunde und Administrator. Du kannst später unterteilen, falls nötig, aber dieser Start gibt dir eine solide Basis.

Inhaber

Der Inhaber ist die für das Geschäftskonto verantwortliche Person. Diese Rolle steuert üblicherweise Abrechnung, Abo-Änderungen, rechtliche Einstellungen, Eigentumsübertragungen und die sensibelsten Kontenentscheidungen.

Definiere diese Rolle klar und früh. Bleibt „Inhaber" vage, geben Teams diese Rechte oft versehentlich an andere Nutzer, nur um die Arbeit am Laufen zu halten.

Mitarbeiter

Mitarbeiter kümmern sich um die tägliche Arbeit. Sie aktualisieren Datensätze, beantworten Kunden, legen Bestellungen an, prüfen Status, verwalten Inhalte oder bringen Aufgaben voran.

Sie brauchen genug Zugriff, um ihre Arbeit schnell zu erledigen, aber meist keine volle Kontrolle über kontoweite Einstellungen. Ein einfacher Test: Wenn ein Fehler dem gesamten Geschäftschaccount schaden könnte, gehört diese Aktion wahrscheinlich einem Administrator oder Inhaber.

Kunde

Kunden brauchen die engste Sicht. In den meisten Apps sollten sie nur ihre eigenen Daten sehen, z. B. Profil, Buchungen, Käufe, Nachrichten oder Fortschritte.

Hier schleichen Teams oft Fehler ein. Sie überlegen genau, was Kunden tun dürfen, vergessen aber zu definieren, was Kunden niemals sehen sollten.

Administrator

Admin und Inhaber werden oft gleichgesetzt, sind aber nicht immer dasselbe.

Ein Administrator verwaltet üblicherweise den Betrieb innerhalb der App. Das kann das Hinzufügen von Mitarbeitern, Zurücksetzen von Berechtigungen, Überprüfung von Aktivitäten oder die Bearbeitung von Support-Anfragen umfassen. In vielen Produkten sollte ein Administrator nicht die Abrechnung, Eigentumsübertragungen oder die sensibelsten Geschäftseinstellungen kontrollieren.

Eine einfache Trennung der vier Rollen lautet:

• Inhaber kontrolliert das Geschäftskonto.
• Administrator verwaltet interne Abläufe.
• Mitarbeiter erledigt die tägliche Arbeit.
• Kunde nutzt den Service.

Diese Aufteilung macht spätere Entscheidungen deutlich einfacher.

Sichtbarkeit und Aktionen sind unterschiedlich

Eine Rolle ist nicht nur ein Etikett. Sie beantwortet zwei getrennte Fragen:

1. Was kann diese Person sehen?
2. Was kann diese Person tun, wenn sie es sieht?

Beides ist nicht dasselbe.

Ein Mitarbeiter darf Bestellungen einsehen, aber nicht löschen. Ein Administrator kann Rückerstattungen genehmigen, während ein Kunde nur eine Anfrage stellen kann. Wenn Sichtbarkeit und Aktionsrechte vermischt werden, werden Menschen entweder in ihrer Arbeit blockiert oder erhalten Zugriff, den sie nicht haben sollten.

Die meisten Apps beschreiben Berechtigungen mit einer kleinen Menge an Aktionen: ansehen, erstellen, bearbeiten, löschen, genehmigen und manchmal exportieren. Diese Aktionen klingen einfach, verändern sich aber je nach Bildschirm und den betroffenen Daten.

Jemand darf vielleicht sein eigenes Profil bearbeiten, aber nicht die Unternehmensabrechnung. Er kann ein Support-Ticket erstellen, aber keinen Rabatt genehmigen. Er kann eine Bestellung aktualisieren, bevor die Zahlung erfasst ist, aber nicht danach.

Es hilft auch, Kontoeinstellungen von Geschäftsdaten zu trennen. Kontoeinstellungen umfassen in der Regel Passwörter, Profile, Benachrichtigungen, Abrechnung, Teammitglieder und Login-Sicherheit. Geschäftsdaten sind die täglichen Informationen in der App, wie Bestellungen, Projekte, Rechnungen, Nachrichten, Termine oder Lagerbestand.

Diese Unterscheidung ist wichtig, weil „Bearbeitungszugriff" in beiden Fällen sehr verschiedene Bedeutungen hat. Die eigene Telefonnummer zu ändern ist nicht dasselbe wie Lohnabrechnung, Kundendaten oder Systemregeln zu bearbeiten.

Erstelle eine einfache Berechtigungskarte

Eine gute Berechtigungskarte beginnt mit echter Arbeit, nicht mit Jobtiteln.

Bevor du Bildschirme oder Datenbanken generierst, schreibe die Hauptsachen auf, die Menschen täglich in der App tun müssen. Denke in Aktionen: eine Bestellung erstellen, eine Rückerstattung genehmigen, einen Kundendatensatz aktualisieren, Berichte ansehen, Abrechnung ändern. So bleibt die Planung an konkreter Nutzung statt an Vermutungen orientiert.

Ein einfacher Prozess funktioniert meist gut:

1. Liste die Kern-Workflows in einfacher Sprache auf.
2. Zerlege jeden Workflow in Schritte.
3. Markiere, wer in jedem Schritt ansehen, erstellen, bearbeiten, genehmigen, löschen oder exportieren kann.
4. Notiere Ausnahmen, z. B. „Mitarbeiter können Bestellungen bearbeiten, aber nicht, nachdem die Zahlung erfasst wurde."

Beginne mit drei bis fünf Workflows. Für ein kleines Geschäft könnten das Kunden-Onboarding, Zahlungen abwickeln, Support bearbeiten und Performance prüfen sein. Frage dann, wer in jedem dieser Fälle die entscheidenden Schritte macht.

Wenn das klar ist, arbeite Seite für Seite. Für jede Seite stelle zwei Fragen: Wer kann sie sehen und was können sie hier tun?

Ein Dashboard kann sowohl für Inhaber als auch Mitarbeiter sichtbar sein, aber nur der Inhaber sieht Umsatzsummen. Eine Kundenprofilseite lässt Kunden vielleicht ihre Kontaktdaten bearbeiten, während Mitarbeiter sie nur ansehen dürfen. Ein Rückerstattungsbildschirm kann Support-Mitarbeitern sichtbar sein, die Genehmigung bleibt aber beim Administrator.

Hier wird oft eine Rollenmatrix nützlich. Sie muss nicht kompliziert sein. Eine einfache Tabelle oder ein kurzes Dokument reicht, wenn es zeigt, welche Rolle welche Aktion an welchem Teil des Produkts durchführen kann.

Wenn du Koder.ai nutzt, liefert dieser Schritt bessere Prompts. „Baue ein Admin-Panel" ist zu vage. „Inhaber kann Pläne und Rückerstattungen verwalten, Mitarbeiter können Konten ansehen und Tickets beantworten, Kunden können nur ihr eigenes Profil und Bestellungen bearbeiten" gibt dem System konkrete Vorgaben.

Bevor du etwas festschreibst, teste die Karte mit ein paar realen Szenarien. Probiere einfache Aufgaben wie ein Mitarbeiter, der eine Rückerstattung ausführt, ein Kunde, der eine Adresse ändert, oder ein Inhaber, der Monatsumsätze überprüft. Fühlt sich ein Schritt unklar an, sind die Berechtigungen noch zu vage.

Beispiel: Eine Salonbuchungs-App

Eine kleine Salonbuchungs-App ist ein gutes Beispiel, weil das Produkt simpel wirkt, bis man genau schaut, wer Zugriff auf was braucht.

Maya ist die Inhaberin. Sie braucht eine vollständige Sicht auf das Geschäft: Buchungen, Mitarbeiterkalender, Kundenhistorie, Servicepreise und Umsatzzahlen. Sie kann Mitarbeiter hinzufügen oder entfernen, Öffnungszeiten ändern, Feiertage blockieren, Rückerstattungen ausstellen und Zugriffsregeln ändern.

Leo ist Stylist. Er braucht nur das, was ihm hilft, seinen Tag zu organisieren. Er sollte seine eigenen Termine, grundlegende Kundennotizen und die Services sehen, die er durchführen kann. Er kann einen Termin als erledigt markieren, nach dem Besuch eine Notiz hinzufügen und eine Buchung verschieben, solange es innerhalb der von Maya gesetzten Regeln bleibt.

Er sollte nicht Preise ändern, vollständige Geschäftsberichte sehen, die Zeitpläne anderer Mitarbeiter bearbeiten oder Kunden aus dem System entfernen können. Das sind Inhaber-Aktionen, keine täglichen Arbeitsaktionen.

Nina ist Kundin. Ihre Ansicht sollte die einfachste sein. Sie kann eine offene Zeit buchen, kommende Termine sehen, vergangene Besuche einsehen und ihre eigene Buchung vor Ablauf der Stornofrist ändern oder stornieren. Sie kann ihre Telefonnummer oder E-Mail aktualisieren, darf aber keine anderen Kunden, interne Notizen oder mitarbeiterinterne Zeitplandetails sehen.

Eine Administratorrolle kann in dieser App trotzdem existieren, dient aber einem anderen Zweck. Admin kümmert sich um Kontowiederherstellung, Abrechnungsfragen oder Sicherheitseinstellungen. Diese Rolle ist nicht dasselbe wie das Führen des Salons.

Deshalb sollten „Inhaber, Mitarbeiter, Kunde und Administrator" vor dem Bau festgelegt werden. Startet jeder mit demselben Buchungsbildschirm, stellst du oft zu spät fest, dass Mitarbeiter private Umsatzdaten sehen oder Kunden Zugriff auf Einstellungen haben, die sie niemals berühren sollten. Das später zu beheben heißt Bildschirme, Regeln und Tests neu aufzubauen statt eine frühe Planungsentscheidung zu treffen.

Fehler, die zu Nacharbeit führen

Die meisten Berechtigungsprobleme beginnen mit Abkürzungen.

Der erste häufige Fehler ist, anfangs zu viel Zugriff zu geben. Eine Person, die nur Mitarbeiter-Tools braucht, erhält volle Admin-Rechte, weil das bei der Einrichtung leichter erscheint. Das funktioniert kurz, führt aber später zu Aufräumarbeiten, wenn du Einstellungen verstecken, Daten schützen und Bildschirme für die richtige Rolle neu bauen musst.

Der zweite Fehler ist, alle Mitarbeiter gleich zu behandeln. Ein Vertriebsmitarbeiter, Support-Agent, Lagerarbeiter und Finanzleiter brauchen in der Praxis selten dieselben Werkzeuge. Teilen sie sich eine breite „Mitarbeiter"-Rolle, wird die App schnell unübersichtlich. Menschen sehen Buttons, die sie nicht verwenden sollten, und einfache Aufgaben wirken riskant.

Der dritte Fehler ist, Edge-Cases zu ignorieren. Teams planen häufige Aktionen wie Bestellungen ansehen oder Profile aktualisieren, vergessen aber sensible Aktionen: Rückerstattungen, Exporte, Konto-Schließung, Wiederherstellung von Abos oder das Löschen von Datensätzen. Diese Aktionen brauchen oft engere Regeln, Genehmigungsschritte oder ein Protokoll, wer was getan hat.

Der vierte Fehler ist, interne private Daten mit kundenorientierten Daten zu vermischen. Liegen Support-Notizen, Betrugskennzeichnungen oder Abrechnungs-Kommentare neben Feldern, die Kunden sehen können, wird irgendwann etwas falsch offenbart. Dann änderst du nicht nur einen Bildschirm — eventuell musst du auch das Datenmodell anpassen.

Eine teure Gewohnheit ist, zuerst Bildschirme zu bauen und erst später den Zugriff zu definieren. Die Oberfläche mag in einer frühen Demo gut aussehen, bricht aber, sobald echte Rollen ins Spiel kommen. Ein Dashboard, das für einen Administrator funktioniert, braucht möglicherweise ein anderes Menü, andere Beschriftungen und weniger Aktionen für Mitarbeiter oder Kunden.

So kommen Teams dazu, Berechtigungsnacharbeit doppelt zu leisten: einmal nach dem ersten Build und nochmal, nachdem echte Nutzer testen.

Kurz-Check bevor du etwas generierst

Bevor du baust, halte kurz inne und beantworte ein paar einfache Fragen. Diese schnelle Prüfung hilft, spätere Nacharbeit zu vermeiden.

• Kann jede Rolle ihre Hauptaufgabe in wenigen Schritten erledigen?
• Sind sensible Daten vor falschen Nutzern verborgen?
• Liegen Genehmigungsaktionen bei der richtigen Person?
• Kann ein neues Teammitglied die Rollen schnell verstehen?
• Was passiert, wenn jemand die Rolle wechselt oder das Team verlässt?

Diese Fragen fangen Probleme früh ab.

Beispielsweise: Wenn ein Mitarbeiter zum Filialleiter befördert wird, kann er jetzt vielleicht Rabatte genehmigen und Teampläne sehen. Das bedeutet nicht automatisch, dass er Abrechnungseinstellungen oder Exporte aller Kundendaten sehen sollte. Eine Rollenänderung sollte ihm die neuen Zugriffe geben und alte entziehen, die er nicht mehr braucht.

Das ist auch der richtige Zeitpunkt, um unangenehme Szenarien zu prüfen. Was kann ein gesperrter Nutzer noch sehen? Was passiert, wenn ein Administrator zum Mitarbeiter herabgestuft wird? Bleiben alte Daten nach der Änderung sichtbar?

Wenn du diese Fragen in einfachen Worten beantworten kannst, ist dein Rollen- und Berechtigungsplan wahrscheinlich bereit. Wenn nicht, behebe die Karte jetzt, solange Änderungen noch günstig sind.

Mach aus dem Plan ein kurzes Briefing

Wenn die Rollen klar sind, fasse sie in einem kurzen Dokument zusammen, das das Team in ein oder zwei Minuten versteht. Es muss nicht formell sein. Es muss nur spezifisch sein.

Für jede Rolle notiere, was sie sehen, was sie ändern und was sie niemals anfassen sollten. Bleib praktisch. Ein Inhaber sieht Abrechnung und Berichte. Mitarbeiter aktualisieren Bestellungen und Kundendaten. Kunden sehen nur ihr eigenes Konto. Admins verwalten Nutzer und Einstellungen, ohne die Eigentümerkontrollen zu übernehmen.

Ein kurzes Briefing deckt meist vier Dinge ab:

• die Rollen in der App
• die Hauptaktionen, die jede Rolle durchführen kann
• die Daten, die jede Rolle sehen oder bearbeiten darf
• alle sensiblen Bereiche, die zusätzliche Beschränkungen brauchen

Nutze dieses Briefing, wenn du Bildschirme, Workflows und Datenregeln generierst. Es gibt dem Bauprozess von Anfang an Leitplanken.

Das ist besonders wichtig bei Koder.ai, wo du Web-, Server- und Mobile-Apps per Chat erstellen kannst. Weil die Generierung schnell ist, hilft ein klares Berechtigungsbriefing, dass die erste Version deutlich näher an dem liegt, was dein Team wirklich braucht.

Bevor du weitergehst, prüfe die erste Version mit einem realen Szenario für jede Rolle. Melde dich als Inhaber, Mitarbeiter, Kunde und Admin an. Erledige eine übliche Aufgabe, prüfe sichtbare Daten und probiere eine Aktion, die blockiert sein sollte.

Dieser einfache Test fängt Probleme ein, die in der Planung leicht übersehen werden und später teuer zu beheben sind. Eine klare Rollenkarte, ein einseitiges Briefing und ein schneller Test pro Rolle reichen meist, um die meisten Zugriffsfehler zu vermeiden, bevor sie zu einer Neugestaltung werden.