Kundenportal und Plattform neu gestalten: UX, Rollen und geschützte Bereiche

Von Edip Kilinc, Gründer von Webwavers. Veröffentlicht am 31.10.2026. Zuletzt aktualisiert am 31.10.2026. Lesezeit: ca. 15 Minuten. Dieser Text ist keine Rechts- oder Sicherheitsberatung.

Kurzantwort: Ein Kundenportal oder eine Plattform gestaltest du neu, indem du zuerst Aufgaben und Rollen klärst, daraus die Informationsarchitektur ableitest, Prototypen mit echten Nutzern testest und erst dann das Interface und ein Designsystem ausarbeitest. Die technische Umsetzung von Login, Rechten und Schnittstellen ist eine eigene Aufgabe. Frag jede Agentur, welchen dieser Teile sie selbst baut und wo sie an dein Team oder einen Technikpartner übergibt.

Das Wichtigste in Kürze

• Beginne mit Aufgaben und Rollen, nicht mit Farben. Ein Portal ist ein Werkzeug, in dem Menschen etwas erledigen.
• Rechte werden auf dem Server durchgesetzt, nicht in der Oberfläche. Ausgeblendete Menüpunkte schützen nichts.
• Teste Prototypen mit wenigen Nutzern pro Rolle, mehrfach, mit Überarbeitung dazwischen.
• Die Technik für geschützte Bereiche ist eine eigene Entscheidung. Mitgliederdienste, Standardsoftware und individuelle Anwendungen haben jeweils klare Grenzen.
• "Design und Umsetzung aus einer Hand" ist nur dann ein Vorteil, wenn klar ist, wer was baut und wer es betreibt.

Wichtiger Hinweis: Dieser Ratgeber erklärt UX-Vorgehen und Architekturentscheidungen und nennt die jeweilige Quelle. Er ist keine Rechts- oder Sicherheitsberatung. Datenschutz, Sicherheit und Barrierefreiheit im Einzelfall klärst du mit deiner Datenschutzbeauftragten, deiner IT-Sicherheit oder einer Fachperson.

Inhaltsverzeichnis

• Was ist ein Kundenportal?
• Redesign oder schrittweise verbessern?
• Schritt 1: Aufgaben und Rollen klären
• Zugriff und Sicherheit: Rechte gehören auf den Server
• Login, SSO und Passkeys
• UX-Prinzipien für komplexe Oberflächen
• Vorgehen in Phasen
• Technik für geschützte Bereiche: Die Optionen
• Design und Umsetzung aus einer Hand?
• Barrierefreiheit und Datenschutz
• Rollout und Messung
• Briefing-Checkliste für die Agentur
• Fragen an eine Agentur
• Wann du keine Agentur brauchst
• Wie wir das umsetzen
• FAQ

Was ist ein Kundenportal?

Ein Kundenportal ist ein geschützter Bereich, in dem Kunden, Partner oder Mitarbeitende nach der Anmeldung Aufgaben erledigen: Aufträge einsehen, Dokumente laden, Anfragen stellen, Daten pflegen, Rechnungen prüfen, Status verfolgen. Eine Plattform geht weiter: Sie bündelt mehrere Funktionen, Rollen und Datenquellen in einer Anwendung. Beides unterscheidet sich von der öffentlichen Unternehmenswebsite in einem wesentlichen Punkt. Hier ist die Oberfläche nicht Werbung, sondern Werkzeug.

Daraus folgt: Der Maßstab für gutes Design ist nicht "gefällt mir", sondern "schafft der Nutzer seine Aufgabe schnell, richtig und ohne Support?". Und: Ein Portal hängt an Prozessen, Daten und Rechten, die hinter der Oberfläche liegen. Wer nur die Oberfläche neu zeichnet, verbessert selten das Erlebnis.

Redesign oder schrittweise verbessern?

Nicht jedes Portal braucht ein komplettes Redesign. Die folgende Gegenüberstellung hilft bei der Entscheidung.

Situation	Eher kompletter Neuentwurf	Eher schrittweise Verbesserung
Kernaufgaben	Haben sich verändert oder fehlen im Portal	Funktionieren, sind nur umständlich
Informationsarchitektur	Grundsätzlich nicht an den Nutzerwegen ausgerichtet	Im Kern tragfähig
Technikbasis	Veraltet, kaum erweiterbar	Stabil
Design	Uneinheitlich, kein System	Einheitlich mit Lücken
Risiko	Kann getragen werden (Parallelbetrieb möglich)	Nutzer sind abhängig, Ausfall teuer
Zeitrahmen	Es gibt ein Projekt mit Budget und Verantwortlichen	Verbesserungen im laufenden Betrieb

Ein Neuentwurf ist riskanter, weil Nutzer an Gewohnheiten hängen und jedes Detail bricht, was jemand täglich benutzt hat. Er lohnt sich, wenn Aufgaben, Rollen oder Technik sich grundlegend geändert haben. Sonst ist der schrittweise Weg meist ruhiger: Probleme beheben, Komponenten vereinheitlichen, ein Designsystem einführen, Bereich für Bereich umstellen.

Schritt 1: Aufgaben und Rollen klären

Bevor jemand Wireframes zeichnet, brauchst du drei Dinge: eine Liste der wichtigsten Aufgaben, eine Liste der Rollen und eine Zuordnung dazwischen.

Aufgaben formulierst du aus Sicht der Nutzer: "Ich will den Status meines Auftrags sehen", "Ich will eine Rechnung als PDF herunterladen", "Ich will einen Mitarbeiter hinzufügen". Sammle sie aus Interviews, Support-Tickets, Nutzungsdaten und Vertriebsgesprächen. Gewichte sie nach Häufigkeit und Bedeutung.

Rollen sind Gruppen mit unterschiedlichen Rechten und Zielen. Eine Rollenmatrix macht sie sichtbar:

Rolle	Beispielaufgaben	Darf sehen	Darf ändern
Kunde, Hauptnutzer	Aufträge verwalten, Nutzer einladen	Alle Daten des eigenen Unternehmens	Nutzer, Stammdaten, Bestellungen
Kunde, Mitarbeiter	Status prüfen, Dokumente laden	Daten seiner Abteilung oder Projekte	Eigene Eingaben
Kunde, Buchhaltung	Rechnungen prüfen und herunterladen	Rechnungen, Zahlungsstatus	Zahlungsdaten
Partner oder Händler	Angebote, Preise, Bestandsdaten	Partnerbereich	Eigene Konditionen laut Vertrag
Interner Support	Konten prüfen, Probleme lösen	Kundendaten mit Protokoll	Begrenzt, nachvollziehbar
Administrator	Konfiguration, Benutzerverwaltung	Alles, was nötig ist	Systemeinstellungen

Die Matrix hat zwei Funktionen. Für das Design bestimmt sie, welche Startseite und Navigation jede Rolle sieht. Für die Technik ist sie die Spezifikation der Berechtigungen. Dieselbe Tabelle muss in beiden Welten stimmen, sonst entstehen Lücken.

Zugriff und Sicherheit: Rechte gehören auf den Server

Ein häufiger Denkfehler in Portalprojekten: Die Oberfläche blendet Funktionen aus, die ein Nutzer nicht nutzen darf, und das Team hält das Thema damit für erledigt. Sicherheit entsteht aber nicht durch das, was die Oberfläche zeigt, sondern durch das, was der Server erlaubt.

Die OWASP Top 10 von 2021 führt "Broken Access Control" auf Platz 1, nach Platz 5 im Jahr 2017. Laut OWASP wurden 94 Prozent der geprüften Anwendungen auf irgendeine Form dieses Problems getestet, die durchschnittliche Vorkommensrate liegt bei 3,81 Prozent. Als Beispiele nennt OWASP unsichere direkte Objektreferenzen (ein Angreifer sieht oder ändert das Konto eines anderen Nutzers, indem er dessen Kennung angibt) und das direkte Aufrufen geschützter URLs. Als Grundsatz nennt sie: Außer für öffentliche Ressourcen gilt standardmäßig "deny by default" (OWASP Top 10:2021, A01 Broken Access Control).

Was das für dein Projekt bedeutet:

1. Die Rollenmatrix wird serverseitig durchgesetzt. Jede Anfrage an Daten wird gegen Rolle und Eigentum geprüft, auch wenn die Oberfläche den Weg dorthin nicht anbietet.
2. Kennungen in URLs sind kein Schutz. Wenn die Rechnungsnummer 1042 in der Adresse steht, darf Nutzer A nicht durch Ändern auf 1043 die Rechnung von Nutzer B sehen.
3. Standardmäßig nichts erlauben. Neue Funktionen sind erst für Rollen freigegeben, wenn jemand sie bewusst vergibt.
4. Zugriffe protokollieren. Vor allem bei internen Rollen, die Kundendaten sehen.
5. Testen. Penetrationstests oder zumindest strukturierte Berechtigungstests gehören vor den Rollout. Das ist eine Aufgabe für Sicherheitsfachleute, nicht für das UX-Team.

Für Design bedeutet das: Zeig nicht, was ein Nutzer nicht nutzen darf, aber verlass dich nie darauf, dass das Ausblenden reicht. Die Oberfläche folgt der Rechtelogik, sie ersetzt sie nicht.

Login, SSO und Passkeys

Der Login ist die erste Hürde im Portal. Er muss sicher sein und trotzdem nicht im Weg stehen.

Single Sign-On (SSO). Bei Unternehmenskunden wollen viele sich mit dem Konto ihres Arbeitgebers anmelden. Ein verbreiteter Standard dafür ist OpenID Connect, eine Schicht auf OAuth 2.0: Ein Identitätsanbieter authentifiziert den Nutzer und stellt dem Portal ein Identity Token aus. Der Vorteil für das Portal: Es muss keine Passwörter setzen, speichern oder verwalten (OpenID Foundation). Daneben existiert SAML als älterer, in Unternehmensumgebungen verbreiteter Standard. Welche Variante deine Kunden brauchen, klärst du mit deren IT, nicht am Schreibtisch.

Passkeys. Die FIDO Alliance beschreibt Passkeys als passwortlose, phishing-resistente Anmeldedaten auf Basis von FIDO2 und WebAuthn: Die Anmeldung erfolgt mit dem Entsperrverfahren des Geräts, es gibt keine geteilten Geheimnisse, die auf dem Server gestohlen werden könnten (FIDO Alliance). Für Portale sind Passkeys eine Option, die Sicherheit und Komfort zugleich verbessern kann, wenn deine Zielgruppe sie nutzen kann.

Zwei-Faktor-Authentifizierung und Einladungen. Bei sensiblen Daten gehört ein zweiter Faktor zum Standard. Der Einladungsprozess für neue Nutzer (wer lädt wen ein, wie läuft der erste Login) ist einer der unterschätzten Teile eines Portals, weil hier die meisten Supportanfragen entstehen.

Barrierefreier Login. Das Kriterium 3.3.8 der WCAG 2.2 (Level AA) verlangt, dass Anmeldeschritte keinen kognitiven Funktionstest voraussetzen, etwa Passwörter merken oder Zeichen abtippen, es sei denn, es gibt eine Alternative. Einfügen und automatisches Ausfüllen dürfen nicht blockiert werden (W3C, Accessible Authentication). Das betrifft besonders Zwei-Faktor-Codes, die sich einfügen lassen müssen.

UX-Prinzipien für komplexe Oberflächen

Portale haben viele Funktionen und Daten, und genau deshalb scheitern sie an Überladung. Die zehn Heuristiken von Jakob Nielsen (1994) sind auch hier brauchbar (Nielsen Norman Group). Vier davon betreffen Portale besonders:

Heuristik	Was sie im Portal bedeutet	Typisches Problem
Sichtbarkeit des Systemstatus	Nutzer sehen, was gerade passiert: Upload läuft, Antrag eingegangen, Freigabe offen	Aktionen ohne Rückmeldung
Übereinstimmung mit der realen Welt	Begriffe der Nutzer statt interner Fachsprache	Menüpunkte heißen wie Datenbanktabellen
Fehlervermeidung	Bestätigung vor kritischen Aktionen, sinnvolle Standardwerte	Löschen ohne Rückfrage
Wiedererkennen statt Erinnern	Optionen sichtbar, Filter merkbar, zuletzt benutzte Dinge griffbereit	Nutzer müssen Nummern und Pfade auswendig kennen

Weitere Elemente, die in Portalprojekten oft zu kurz kommen:

• Startseite je Rolle. Das Dashboard zeigt, was diese Rolle zuerst braucht, nicht alles auf einmal.
• Tabellen und Filter. Datenlisten sind Kernbestandteil: Spalten wählbar, Sortierung, Suche, gespeicherte Filter, Export.
• Leere Zustände. Was sieht ein neuer Nutzer, wenn noch keine Daten da sind? Eine gute Erstansicht erklärt den nächsten Schritt.
• Fehlerzustände. Zeitüberschreitung, fehlende Rechte, Ausfall der Schnittstelle: Jeder Fall braucht eine klare Meldung mit nächstem Schritt.
• Benachrichtigungen. Welche Ereignisse lösen eine Mail aus, welche bleiben im Portal? Wähle bewusst, sonst entsteht Rauschen.
• Hilfe an der richtigen Stelle. Kontextuelle Hinweise statt langer Handbücher.

Ein Portal ist außerdem ein Ort, an dem Konsistenz zählt. Wenn sich Buttons, Tabellen und Formulare in jedem Bereich anders verhalten, lernt der Nutzer nie, sondern rät. Deshalb gehört ein Designsystem zum Redesign: Komponenten, Varianten und Zustände einmal sauber definieren und überall verwenden. Wie die Übergabe von Figma an die Entwicklung funktioniert, beschreibt der Ratgeber Designsysteme von Figma zu Webflow.

Vorgehen in Phasen

Eine Agentur, die ein Portal-Redesign ernst nimmt, arbeitet in nachvollziehbaren Phasen. Die Tabelle zeigt ein typisches Vorgehen mit den Ergebnissen, die du jeweils verlangen kannst.

Phase	Inhalt	Ergebnis	Wer wird eingebunden
1. Ausgangslage	Interviews, Support-Tickets, Nutzungsdaten, Bestandsaufnahme der Funktionen	Problemliste, Aufgabenliste, Rollenübersicht	Product Owner, Support, Vertrieb, Kunden
2. Struktur	Rollenmatrix, Informationsarchitektur, zentrale Abläufe als Flows	Sitemap, Flows, Rechtekonzept	Product Owner, Technik
3. Wireframes	Grobe Bildschirme für die wichtigsten Abläufe	Klickbarer Wireframe-Prototyp	Product Owner, Fachbereiche
4. Test	Prototyp-Test mit Nutzern aller Hauptrollen	Testbericht, priorisierte Änderungen	Nutzer, Product Owner
5. Interface und Designsystem	Visuelles Design, Komponentenbibliothek, Zustände	Design in Figma, dokumentiertes Designsystem	Marke, Technik
6. Übergabe	Dokumentation, Abnahmekriterien, offene Fragen	Übergabepaket für die Entwicklung	Technik
7. Umsetzung	Frontend, Rechte, Schnittstellen, Tests	Funktionierende Anwendung	Entwicklung
8. Rollout	Pilotgruppe, Schulung, Parallelbetrieb, Support	Abgeschlossene Migration	Support, Kunden

Zum Testen: Nielsen beschrieb schon 2000, dass ein Test mit etwa fünf Nutzern rund 85 Prozent der Usability-Probleme findet, wobei ein einzelner Nutzer im Schnitt etwa 31 Prozent aufdeckt. Er empfiehlt mehrere kleine Tests mit Überarbeitung dazwischen und bei mehreren Nutzergruppen drei bis vier Nutzer pro Gruppe bei zwei Gruppen und drei Nutzer pro Gruppe bei drei oder mehr Gruppen (Nielsen Norman Group). Für ein Portal mit vier Rollen heißt das: lieber mehrere kleine Runden mit je drei Personen pro Rolle als eine große Umfrage. Das ist eine Faustregel für Usability-Probleme, kein Beweis für den Erfolg des Gesamtprojekts.

Technik für geschützte Bereiche: Die Optionen

Die Technik entscheidet, was machbar, sicher und wartbar ist. Die folgenden Optionen haben jeweils klare Grenzen.

Option	Geeignet für	Grenzen
Mitgliederbereich auf der Website über einen Zusatzdienst	Einfache geschützte Inhalte (Downloads, Wissensbereich)	Begrenzte Rollenlogik und Datenverarbeitung
Standard-Kundenportal im CRM, ERP oder Ticketsystem	Prozesse, die das Fachsystem ohnehin abbildet	Gestaltung und Ablauf folgen dem Produkt
Individuelle Webanwendung mit eigenem Backend	Komplexe Rollen, Workflows, Integrationen, besondere Datenmodelle	Hoher Entwicklungs- und Betriebsaufwand
Hybrid: Marketing-Website plus Portal unter eigener Adresse	Trennung von Öffentlichkeit und Anwendung	Zwei Systeme, abgestimmtes Design nötig

Ein aktuelles Beispiel für die Risiken bei Zusatzfunktionen: Webflow hat sein Mitgliederfeature "User Accounts" (früher Memberships) am 29. Januar 2026 eingestellt. Seit 31. Januar 2025 war es auf neuen Sites nicht mehr aktivierbar. Mit der Abschaltung endete der Zugriff auf Konten und Daten, Content-Gates wurden entfernt, Mitglieder konnten sich auf veröffentlichten Sites nicht mehr anmelden, und die zugehörigen APIs und Webhooks wurden abgeschaltet. Webflow empfiehlt Outseta und Memberstack als Alternativen (Webflow Help, User Accounts sunset). Die Lehre ist nicht "Webflow ist ungeeignet", sondern: Wer geschützte Bereiche auf einem Plattform-Feature aufbaut, macht sich abhängig von dessen Fahrplan. Prüfe deshalb bei jedem Baustein, was passiert, wenn der Anbieter ihn ändert oder einstellt, und wie du deine Daten exportierst.

Eine Website in Webflow kann ein starkes Frontend für Marketing, Dokumentation und öffentliche Bereiche sein. Für ein Portal mit Rollen, Fachdaten und Prozessen braucht es in der Regel eine Anwendung mit eigenem Backend oder Standardsoftware. Die sinnvolle Grenze liegt dort, wo Inhalte aufhören und Anwendungslogik anfängt.

Design und Umsetzung aus einer Hand?

Viele fragen: "Welche UX/UI-Agenturen setzen ihr Design auch technisch selbst um?" Es lohnt sich, die Frage präziser zu stellen.

Modell	Vorteile	Risiken
UX/UI-Agentur setzt Design und Frontend um	Weniger Übergabeverluste, einheitliche Verantwortung	Backend, Rechte und Betrieb sind oft nicht Teil des Angebots
UX/UI-Agentur übergibt an dein Entwicklungsteam	Dein Team kennt das System und betreibt es	Übergabe muss dokumentiert sein, Rückfragen kosten Zeit
UX/UI-Agentur plus Technikpartner	Spezialisierung	Koordinationsaufwand, geteilte Verantwortung
Entwicklungshaus mit eigenem UX-Team	Design und Technik eng verzahnt	Designqualität und Markenarbeit variieren stark

Entscheidend ist nicht das Modell, sondern die Klarheit: Wer baut die Oberfläche, wer die Rechte, wer die Schnittstellen, wer testet, wer betreibt? Lass dir das in einem Verantwortungsschema aufschreiben. Mehr Argumente und Gegenargumente findest du im Ratgeber Design und Entwicklung aus einer Hand und in der allgemeinen Auswahlhilfe UX/UI-Agentur auswählen.

Barrierefreiheit und Datenschutz

Barrierefreiheit. Das Barrierefreiheitsstärkungsgesetz gilt seit 28. Juni 2025 und erfasst Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern. Ein Angebot, das sich tatsächlich und ausschließlich an Unternehmer richtet, fällt grundsätzlich nicht unter die Verbraucherregeln, wobei die Bezeichnung "B2B" allein nicht reicht. Kleinstunternehmen sind für Dienstleistungen ausgenommen (IHK Schwaben zum BFSG). Ob dein Portal betroffen ist, ist eine Rechtsfrage, siehe Barrierefreie Website und BFSG. Unabhängig davon ist WCAG ein sinnvoller Qualitätsmaßstab für Portale: Kontraste, Tastaturbedienung, Fokusführung und beschriftete Formularfelder (Glossar: WCAG).

Datenschutz. Ein Portal verarbeitet Kundendaten dauerhaft. Art. 25 DSGVO verlangt datenschutzfreundliche Voreinstellungen, also standardmäßig nur die erforderlichen Daten (Art. 25 DSGVO). Art. 32 DSGVO verlangt dem Risiko angemessene Sicherheitsmaßnahmen, etwa Verschlüsselung, Sicherstellung der Vertraulichkeit und regelmäßige Überprüfung (Art. 32 DSGVO). Für das Design heißt das: Zeig nur Daten, die die Rolle braucht, begrenze Exporte, plane Löschfunktionen und Protokolle ein. Für die Technik: Mandantentrennung, Verschlüsselung, Rechtekonzept, Backups und ein Verfahren für Vorfälle. Bei Auftragsverarbeitung brauchst du Verträge nach Art. 28 DSGVO. Wenn Berufsgeheimnisträger ein Mandantenportal betreiben, gelten zusätzlich berufsrechtliche Anforderungen an Dienstleister (§ 43e BRAO, § 62a StBerG), siehe Erstgespräch-Strecke für Beratungen.

Rollout und Messung

Ein neues Portal ist erst dann gut, wenn die Nutzer es annehmen. Plane den Rollout wie ein eigenes Projekt:

1. Pilotgruppe. Eine kleine Gruppe wohlwollender Kunden arbeitet zuerst im neuen System und gibt Rückmeldung.
2. Parallelbetrieb. Altes und neues Portal laufen zeitlich begrenzt nebeneinander, mit klarem Enddatum.
3. Migration. Daten, Konten und Rechte werden übertragen und stichprobenartig geprüft.
4. Kommunikation. Nutzer erfahren früh, was sich ändert, warum und wo sie Hilfe bekommen.
5. Schulung und Hilfe. Kurze Anleitungen, Hinweise im Portal, ein erreichbarer Support.
6. Rückfallplan. Was passiert, wenn der Start scheitert? Ein Plan B muss vor dem Start stehen.

Messen solltest du an den Aufgaben, nicht an Seitenaufrufen: Wie viele Nutzer schaffen die Kernaufgaben? Wie lange dauern sie? Wie viele Supportanfragen zu welchen Themen gibt es vor und nach dem Start? Welche Funktionen werden genutzt, welche nicht? Setze diese Werte vor dem Redesign als Ausgangslage, sonst kannst du den Erfolg nicht belegen. Das Messen im Portal selbst unterliegt ebenfalls dem Datenschutz, besonders wenn Verhalten einzelnen Personen zugeordnet wird.

Briefing-Checkliste für die Agentur

Je besser dein Briefing, desto vergleichbarer werden die Angebote.

1. Zielsetzung: Welches Problem soll das Redesign lösen, woran erkennst du Erfolg?
2. Nutzer und Rollen: Wer arbeitet im Portal, mit welchen Aufgaben, wie oft?
3. Bestand: Welche Funktionen, Seiten und Abläufe gibt es heute? Screenshots, Ablaufbeschreibungen, Zugang zu einer Testumgebung.
4. Daten und Systeme: Welche Quellen, Schnittstellen und Fachsysteme hängen dran?
5. Login: SSO, Zwei-Faktor, Einladung, Passwort-Reset, vorhandener Identitätsanbieter.
6. Sicherheit und Datenschutz: Anforderungen, Auflagen, Freigabeprozesse, Ansprechpartner.
7. Marke: Vorgaben, Designsystem, Komponentenbibliothek, falls vorhanden.
8. Technik: vorhandene Frameworks, Entwicklungsteam, Betrieb, Hosting.
9. Rahmen: Zeitfenster, Abhängigkeiten, Entscheider, interne Ressourcen.
10. Rollout: Pilotgruppe, Migration, Schulung, Support.

Fragen an eine Agentur

• Welche Portale oder Plattformen habt ihr gestaltet, und welchen Teil habt ihr selbst umgesetzt?
• Wie arbeitet ihr mit Rollen und Rechten, und wer entwirft das Rechtekonzept?
• Wie testet ihr Prototypen, mit wem und wie oft?
• Wie dokumentiert ihr das Designsystem und die Übergabe an die Entwicklung?
• Wer setzt Login, Rechte, Schnittstellen und Sicherheitstests um? Wenn nicht ihr, wer dann?
• Wie geht ihr mit Barrierefreiheit um, und gegen welchen Standard prüft ihr?
• Wie läuft der Rollout, und was gehört zum Support danach?
• Was passiert, wenn ein Baustein, den ihr einsetzt, eingestellt wird?

Wer auf diese Fragen konkrete Antworten gibt, ist besser eingeordnet als jemand mit einem schönen Referenzbild. Misstrauisch solltest du bei Aussagen wie "Wir machen das alles aus einer Hand" ohne Aufteilung der Verantwortung werden.

Wann du keine Agentur brauchst

Wenn dein Portal ein Standardprodukt ist, das du konfigurierst (etwa das Kundenportal deines CRM oder Ticketsystems), reichen oft die Möglichkeiten des Produkts und ein internes Team. Wenn du ein eigenes Entwicklungsteam mit Designverstärkung hast und nur ein Designsystem fehlt, kann auch ein kleines Beratungsprojekt genügen. Und wenn die Probleme eher in Prozessen als in der Oberfläche liegen, hilft eine Prozessklärung vor jedem Design. Eine Agentur lohnt sich, wenn Rollen, Abläufe und Marke zusammen neu gedacht werden müssen und dir der Blick von außen sowie die Methode fehlen.

Wie wir das umsetzen

Typischerweise läuft ein Projekt bei Webwavers so ab, wie es auf unserer Prozessseite steht: Erstgespräch, Onboarding mit Briefing (34 Strategiefragen), Strategiegespräch, Moodboards, Design in Figma mit Feedbackrunden, Entwicklung nach finaler Freigabe und Launch mit Einschulung. Auf unserer Seite UX/UI-Design steht, dass wir neben Unternehmenswebsites auch Portale, Kundenbereiche und Web-Apps gestalten: erst die Nutzerwege, dann das Interface, dann das Designsystem. In klickbaren Prototypen lässt sich zum Beispiel ein Login durchspielen, bevor Code entsteht. Die Komponenten legen wir mit Varianten und Tokens in Figma an und dokumentieren sie. Auf Wunsch setzen wir das Design in Webflow, Framer oder WordPress um. Bei Portalen und Web-Apps hängt die Dauer stärker von den Abläufen ab als bei Websites. Zur Umsetzung beschreibt unsere Seite Webentwicklung, dass nötige Schnittstellen vor dem Build in einem technischen Konzept festgelegt werden. Webflow ist unser Schwerpunkt, wir setzen auch WordPress und weitere Systeme um und beraten neutral. Komplette Kundenportale und Web-Apps mit Login, Rollen und Fachdaten setzen wir gemeinsam mit Vertion um, unserer Partneragentur aus der Webwavers-Gruppe, die sich unter anderem um das Sicherheitskonzept kümmert. Den Umfang für dein Portal klären wir im Erstgespräch. Mehr zu unserer Arbeit für Softwareunternehmen findest du auf der Seite IT, Software und SaaS. Du willst über dein Portal sprechen? Nutze die Kontaktseite.

FAQ

Welche UX/UI-Agenturen setzen ihr Design für ein B2B-Kundenportal auch technisch selbst um?

Das hängt vom Umfang ab. Die Oberfläche setzen viele selbst um, Rechte, Login, Schnittstellen und Betrieb sind eine eigene Aufgabe. Frag jede Agentur, welchen Teil sie selbst baut und wo sie an dich oder einen Technikpartner übergibt, und lass dir das schriftlich aufteilen.

Wie gestalte ich ein Portal mit mehreren Rollen übersichtlich?

Beginne mit einer Rollenmatrix: Aufgaben, Sichtrechte und Änderungsrechte pro Rolle. Daraus leitest du Startseite und Navigation je Rolle ab, statt eine Oberfläche für alle zu bauen. Teste mit drei bis vier Nutzern pro Rolle.

Reicht es, nicht erlaubte Funktionen in der Oberfläche auszublenden?

Nein. Rechte müssen auf dem Server geprüft werden. OWASP führt Broken Access Control in der Top 10 von 2021 auf Platz 1 und empfiehlt, außer für öffentliche Ressourcen standardmäßig alles zu verweigern ("deny by default").

Kann ich einen passwortgeschützten Kundenbereich in Webflow bauen?

Das Mitgliederfeature "User Accounts" hat Webflow am 29. Januar 2026 eingestellt und empfiehlt Outseta und Memberstack als Alternativen. Für einfache geschützte Inhalte kann ein Zusatzdienst genügen. Für Rollen, Fachdaten und Prozesse braucht es meist Standardsoftware oder eine eigene Anwendung.

Brauche ich SSO für mein Kundenportal?

Bei Unternehmenskunden häufig ja, weil sich Mitarbeitende mit dem Konto ihres Arbeitgebers anmelden möchten. OpenID Connect ist ein verbreiteter Standard, SAML ein älterer. Welche Variante deine Kunden brauchen, klärst du mit deren IT.

Gilt das Barrierefreiheitsstärkungsgesetz für mein B2B-Portal?

Das BFSG erfasst Dienstleistungen gegenüber Verbrauchern. Ein Angebot, das sich tatsächlich nur an Unternehmer richtet, fällt grundsätzlich nicht darunter, und Kleinstunternehmen sind für Dienstleistungen ausgenommen. Die Einordnung im Einzelfall ist eine Rechtsfrage. Als Qualitätsmaßstab ist WCAG trotzdem sinnvoll.

Wie viele Nutzer brauche ich für einen Prototyp-Test?

Nach Nielsen Norman Group decken etwa fünf Nutzer rund 85 Prozent der Usability-Probleme auf. Bei mehreren Nutzergruppen sind drei bis vier Nutzer je Gruppe der Richtwert. Mehrere kleine Tests mit Überarbeitung dazwischen sind besser als ein großer.

Fazit

Ein gutes Portal-Redesign beginnt bei Aufgaben und Rollen, setzt Rechte serverseitig durch, testet früh mit Nutzern, baut ein Designsystem und plant den Rollout wie ein eigenes Projekt. Die entscheidende Frage an jede Agentur lautet nicht "Macht ihr das aus einer Hand?", sondern "Wer macht was, und wer betreibt es danach?". Wenn du heute einen ersten Schritt gehen willst: Erstelle die Rollenmatrix und lass drei Nutzer ihre wichtigste Aufgabe im bestehenden Portal vorführen. Du siehst sofort, wo es hakt.

Quellen

• OWASP Top 10:2021, A01 Broken Access Control
• OpenID Foundation, How OpenID Connect works
• FIDO Alliance, Passkeys
• W3C, Understanding SC 3.3.8 Accessible Authentication (Minimum)
• Nielsen Norman Group, 10 Usability Heuristics
• Nielsen Norman Group, Why You Only Need to Test with 5 Users
• Webflow Help, User Accounts sunset
• IHK Schwaben, Barrierefreiheitsstärkungsgesetz
• Art. 25 DSGVO
• Art. 28 DSGVO
• Art. 32 DSGVO
• § 43e BRAO, Gesetze im Internet
• § 62a StBerG, Gesetze im Internet
• Webwavers, Prozess
• Webwavers, UX/UI-Design
• Webwavers, Webentwicklung