Case Study: Konzeption eines User Managements

SaaS-Applikation zur Digitalisierung von Prozessen in öffentlicher Verwaltung.

Tools: Figma und Miro

Rolle: Lead UX/UI Designer

Firma: Polyteia GmbH

Projektzeitraum: September – Dezember 2024

Projektstatus: in Entwicklung

Die Ausgangssituation

Das Startup Polyteia befindet sich derzeit in der Product Discovery Phase für eine neue Web-Anwendung, die Arbeitsprozesse der öffentlichen Verwaltung – sogenannte Fachverfahren – abbilden soll. Als ich als freiberufliche UX/UI Designerin zur Unterstützung ins Team kam, lagen bereits ein neues Design-System sowie erste Designs vor, die in Zusammenarbeit mit einer Agentur entwickelt wurden und auch bereits technisch umgesetzt waren.

Die Hauptfunktionalitäten der Applikation waren folgende:

1. Erstellung von Arbeitsbereichen
2. Erstellung von Formularen mithilfe eines Formulareditors
3. Das Versenden von Formularen
4. Darstellung der Formularergebnisse

Die Formulare waren den jeweiligen Arbeitsbereichen zugeordnet:

Das Ziel

Für die Verwaltung von Berechtigungen über die verschiedenen Arbeitsbereiche und die dazugehörigen Formulare, bestand die Notwendigkeit eines User-Management-Systems. Dieses sollte dem Administrator ermöglichen, Nutzer hinzuzufügen und zu verwalten, Rollen bzw. Berechtigungen zu vergeben, sowie Gruppen zu erstellen und zu verwalten. Ziel des Projekts war die Entwicklung eines Prototyps, der mithilfe von Usability-Tests evaluiert werden sollte.

Persona

Designprozess

Vom Low- zum High-Fidelity Design

Nachdem die verschiedenen Nutzerrollen und deren Berechtigungen im Vorfeld von der Produktmanagerin definiert worden waren, bestand meine Aufgabe darin, verschiedene Flows auszuarbeiten. Zunächst erstellte ich Flows für alle Aufgaben, die die Nutzer ausführen können sollten, um den Weg zur Umsetzung zu veranschaulichen. Diese wurden in Form einfacher Diagramme mithilfe des Tools Miro dargestellt. Sobald die Flows finalisiert waren, begann ich mit der Zeichnung erster Scribbles auf Papier.

Einstieg über das Konto-Menü

Es gab bereits ein Menü namens Konto in der Navigationsleiste, worin sich zu dem Zeitpunkt aber nur die Option befand sich abzumelden. Hier fügte ich eine Link zum neuen User-Management-Bereich hinzu, den ich zunächst Admin-Bereich nannte. Später wurde dieser in Teamverwaltung umbenannt.

Flow 1: User einladen

User- und Gruppen-Liste

In der Teamverwaltung sollte es möglich sein, Nutzer einzuladen und Gruppen zu erstellen. Zudem sollten Listen der eingeladenen Nutzer und der erstellten Gruppen angezeigt werden.

Um die beiden Bereiche klar abzugrenzen und die Navigation zu erleichtern, habe ich eine Tab-Leiste integriert. Diese ermöglicht den Nutzern, zwischen der Nutzer- und der Gruppenliste zu wechseln. Da dieses Design-Pattern bereits an anderer Stelle der Anwendung verwendet wird, fügt es sich nahtlos in das bestehende Konzept ein.

Formular zur Einladung der User

Für den Prozess, eine Person einzuladen, entschied ich mich für ein Overlay. Diese Lösung eignet sich besonders gut, da Informationen über eine begrenzte Anzahl von Formularfeldern abgefragt werden, die Aktion abgeschlossen, aber auch problemlos abgebrochen werden kann. Da es sich zudem um eine reine Desktop-Anwendung handelt, sprach nichts gegen die Verwendung von Overlays.

Ziel war es den Prozess so einfach wie möglich zu gestalten und daher entschieden wir uns in Rücksprache mit dem Development-Team nur ein Feld für die E-Mail Adresse, ein Dropdown-Menü zur Auswahl der Rolle anzuzeigen und ein Feld für eine Nachricht an die eingeladene Person anzuzeigen. Die eingeladene Person sollte ihren Namen beim ersten Login selbst eingeben.

Das Nachrichtenfeld wurde als optional gekennzeichnet und folgt somit der Empfehlung, ausschließlich optionale Felder zu markieren. Wichtig ist außerdem, dass der Haupt-Call-to-Action-Button „Einladung versenden“ stets aktiv bleibt und nicht im deaktivierten (disabled) Zustand angezeigt wird. Sind die Pflichtfelder nicht ausgefüllt, erhält der Nutzer stattdessen eine entsprechende Fehlermeldung. Damit wich ich bewusst von den bisherigen Design-Patterns der Anwendung ab und schlug vor, diese Praxis nicht weiter zu verfolgen.

Nach dem Absenden der Einladung erhält der Nutzer eine Nachricht, die bestätigt, dass die Aktion erfolgreich vom System ausgeführt wurde.

Gleichzeitig wird die neu eingeladene Person in der Nutzerliste angezeigt. Eine wichtige Frage war, wie wir kennzeichnen, ob die Einladung angenommen wurde oder nicht. Statt einen Status wie „Akzeptiert“ oder „Ausstehend“ anzugeben, der nach Annahme der Einladung keinen Mehrwert mehr bieten würde, haben wir uns entschieden, das Datum und die Uhrzeit des letzten Logins in der Liste anzuzeigen.

Ein weiteres Feature ermöglicht es dem Nutzer, mehrere Personen gleichzeitig mithilfe von Bulk-Actions einer Gruppe zuzuordnen (siehe Abb. 20). Nach der Auswahl einer Person erscheint oberhalb der Liste ein kleines Dropdown-Menü, das alle verfügbaren Gruppen anzeigt. Zusätzlich gibt es eine Suchfunktion, die die Auswahl der Gruppe erleichtert (siehe Abb. 21 und 22).

Flow 2: Gruppe erstellen

Gruppenerstellung über Gruppenliste

Im Tab „Gruppen“ kann der Nutzer eine Liste der erstellten Gruppen einsehen. Wurden noch keine Gruppen erstellt, ist die Liste leer. Mit Klick auf den Button „Gruppe erstellen“ öffnet sich ein Overlay zur Benennung und Beschreibung der Gruppe.

Für die Auswahl der Gruppenmitglieder steht eine scrollbare und durchsuchbare Liste aller hinzugefügten Personen zur Verfügung. Dieses Pattern wurde bereits für das Teilen von Formularen in der Anwendung genutzt. Ich habe es übernommen und durch die zusätzliche Anzeige der E-Mail-Adressen bei Personen mit gleichem Namen optimiert.

Gruppenerstellung aus User Liste als Sammelaktion

Eine Gruppe kann auch direkt aus der Nutzerliste heraus, in Form einer Massenaktion erstellt werden. Zuerst werden die gewünschten Mitglieder ausgewählt und anschließend kann eine bereits erstellte Gruppe ausgewählt oder eine neue erstellt werden.

Flow 3: Nutzer und Gruppen bearbeiten

Neben der Nutzer- und Gruppenliste gibt es auch Übersichts- bzw. Profilseiten für die einzelnen Nutzer und Gruppen.

Nutzerprofilseite

Für jeden angelegten Nutzer gibt es eine eigene Profilseite, die über die User-Liste aufgerufen werden kann. Auf dieser Seite können alle Mitglieder der Organisation die hinterlegte E-Mail-Adresse sowie die Gruppenmitgliedschaften der jeweiligen Person einsehen und zur entsprechenden Gruppenseite navigieren. Der Admin hat zusätzlich die Möglichkeit, die Rolle eines Nutzers zu ändern oder die Person zu löschen. Allerdings kann nur der jeweilige Nutzer selbst seinen Namen und seine E-Mail-Adresse bearbeiten.

Gruppenprofilseite

Auch für jede angelegte Gruppe gibt es eine eigene Profilseite, die über die Gruppenliste aufgerufen werden kann. Auf dieser Seite werden der Gruppenname, eine optionale Gruppenbeschreibung und alle Gruppenmitglieder angezeigt, mit der Möglichkeit, direkt zu den jeweiligen Profilseiten zu navigieren. Zusätzlich können der Gruppenname und die Beschreibung bearbeitet werden , sowie Mitglieder hinzugefügt oder entfernt werden. Ebenfalls kann eine Gruppe gelöscht werden. Diese Funktion ist als kritische Option hinter einem Kebab-Menü verborgen und erfordert eine zusätzliche Bestätigung.

Flow 4: Arbeitsbereich teilen

Hier siehst du den Arbeitsbereich, der bereits vor meinem Projektbeginn vorhanden war. In diesem können Nutzer alle erstellten Formulare einsehen und zu diesen navigieren. Meine Aufgabe bestand darin, eine Möglichkeit zu entwickeln, wie ein solcher Arbeitsbereich geteilt werden kann. Ein Teilen-Button war hierfür bereits im Headerbereich vorgesehen.

Formular zum Teilen eines Arbeitsbereiches

Ein Arbeitsbereich sollte sowohl mit Gruppen als auch mit Einzelpersonen geteilt werden können. Für diesen Flow habe ich habe ich wieder verschiedene Ansätze ausprobiert und sorgfältig abgewogen, um die nutzerfreundlichste Lösung zu finden.

Zunächst habe ich überlegt, dem Nutzer die Möglichkeit zu geben, vorab zu wählen, ob der Arbeitsbereich mit einer Gruppe oder einer Einzelperson geteilt werden soll (siehe Abb. 50). Allerdings traten dabei sofort einige Herausforderungen auf. Zum Beispiel stellte sich die Frage, wie es gehandhabt werden sollte, wenn der Arbeitsbereich sowohl mit Gruppen als auch mit Einzelpersonen geteilt werden soll. In diesem Fall müsste der Nutzer umständlich zwischen den Optionen hin und her navigieren. Zudem würden bei dieser Variante nach der Auswahl von Einzelpersonen und einer anschließenden Suche nach Gruppen die zuvor ausgewählten Personen nicht mehr sichtbar sein. Aufgrund dieser Probleme habe ich diesen Ansatz schnell verworfen.

Ein weiterer Ansatz war, zwei unterschiedliche Ansichten einzuführen. Zunächst sollte dem Nutzer nur eine Suchleiste angezeigt werden, über die sowohl nach Gruppen als auch nach Personen gesucht werden kann. Zusätzlich hätte ein Button die Möglichkeit geboten, alle Personen und Gruppen anzuzeigen – eine hilfreiche Option für den Fall, dass der Nutzer die genaue Schreibweise eines Namens oder den vollständigen Namen einer Abteilung nicht kennt (siehe Abb. 51).

Mit Klick auf den Button wären zwei Listen eingeblendet worden: eine Nutzerliste und eine Gruppenliste, die über Tabs zugänglich sind. Allerdings war die Trennung zwischen der Suchfunktion und der Darstellung der Listen nicht ideal. Der Nutzer hätte erneut umständlich zwischen den beiden Ansichten wechseln müssen. Zudem hätte eine Übersicht gefehlt, in der alle bereits ausgewählten Personen und Gruppen zusammen angezeigt werden. Aus diesen Gründen habe ich auch diesen Ansatz verworfen.

Letztlich habe ich mich für eine sehr einfache Lösung entschieden, indem ich auf die Unterteilung zwischen Personen und Gruppen verzichtet habe. Dadurch konnten alle zuvor identifizierten Probleme behoben werden. Im finalen Overlay hat der Nutzer die Möglichkeit, sowohl nach Gruppen als auch nach Personen in einem gemeinsamen Suchfeld zu suchen. Darunter wird eine Liste aller verfügbaren Gruppen und Personen angezeigt (siehe Abb. 51).

Sobald der Nutzer eine Person oder Gruppe auswählt, erscheint ein Dropdown-Menü zur Auswahl der Rolle (siehe Abb. 52 und 53). Standardmäßig ist die Rolle „Mitglied“ vorausgewählt. Zusätzlich hat der Nutzer die Möglichkeit, eine Nachricht zu verfassen, die den ausgewählten Personen oder Gruppen zusammen mit der Einladung per E-Mail zugesandt wird.

Klickbare Prototypen

Hier geht zu den beiden Prototypen:

👉 Prototyp 1

👉 Prototyp 2

Was ich gelernt habe

Während dieses Projekts konnte ich wertvolle Erfahrungen in der engen Zusammenarbeit mit der Produktmanagerin sammeln und habe gelernt, wie wichtig ein regelmäßiger Austausch mit Entwicklern ist. Ihr Feedback hat uns geholfen, technische Herausforderungen frühzeitig zu erkennen und Lücken im Konzept zu schließen. Zudem habe ich erlebt, wie entscheidend es ist, frühzeitig alle Stakeholder ins Boot zu holen, um Missverständnisse zu vermeiden.

Ein besonders wichtiger Lernmoment war für mich die Phase nach der Umsetzung: Ich habe gesehen, wie stark Designentscheidungen von der finalen Implementierung abhängen und wie wichtig es ist, den Entwicklungsprozess aktiv zu begleiten. Diese Erfahrung hat mir noch einmal verdeutlicht, dass gute UX nicht nur aus einem durchdachten Konzept besteht, sondern auch von einer sauberen technischen Umsetzung abhängt.

Das Projekt hat mir viel Freude bereitet, und ich nehme aus der Zusammenarbeit viele wertvolle Erkenntnisse für zukünftige Projekte mit.

Weitere Case Studies