idgard ist eine auf Datensicherheit spezialisierte Cloud-Storage-Lösung, die mithilfe der patentierten Sealed-Cloud-Technologie geschützte Zusammenarbeit im Enterprise-Umfeld ermöglicht. Zentrales Konzept sind sogenannte Boxen, also Ordner, in die Eigentümer weitere Nutzer einladen und mit granularen Berechtigungen ausstatten können (Lesen, Schreiben, Löschen, Mitglieder sehen, Mitglieder einladen).
In der Web-Anwendung ist die Verwaltung dieser Box-Mitglieder als breite Tabelle umgesetzt: eine Liste mit Namen auf der linken Seite, daneben mehrere Spalten mit Eigenschaften und Berechtigungen, die pro Nutzer per Checkbox umgeschaltet werden können. Ziel dieses Projekts war, die Mitglieder-Verwaltung auch in den Mobile-Apps bereitzustellen, ohne relevante Funktionalität gegenüber der Web-Version zu verlieren.
Ausgangslage
Die Herausforderung war in erster Linie eine gestalterische: Eine Oberfläche, die für Full-HD-Desktop-Monitore konzipiert war, musste auf den schmalen, vertikalen Screen eines Smartphones übertragen werden. Gleichzeitig sollten beide Plattformen den jeweiligen Design-Konventionen (Human Interface Guidelines für iOS, Material Design für Android) folgen, um sich nativ anzufühlen.
Zentrale Fragen zu Beginn des Projekts:
Wie werden Mitgliederliste und nutzerspezifische Berechtigungen aufgeteilt, wenn der Platz für eine Tabelle fehlt?
Welche Aktionen aus der Web-Version sind mobil wirklich relevant, welche können vereinfacht oder weggelassen werden?
Wie wird das Auffinden einzelner Nutzer in längeren Listen auf Mobilgeräten gelöst?
Meine Rolle
Ich war als einziger UX-Designer für Konzeption und Umsetzung verantwortlich:
Übertragung der bestehenden Funktionalität in plattformkonforme Mock-ups für iOS und Android in Figma
Erstellung eines Klick-Dummys mit allen zentralen Handlungsmöglichkeiten
Durchführung kleiner Nutzertests mit Bestandskunden per MS Teams
Design von Empty States (z. B. „no members in this folder yet") und Error States (z. B. „online connection lost")
Hand-over an die iOS- und Android-Entwickler
Da es um die Übertragung einer bestehenden Funktionalität und nicht um die Definition neuer Features ging, war der Funktionsumfang weitgehend vorgegeben. Der Research-Fokus lag entsprechend auf qualitativer Validierung des Interaktionskonzepts.
Qualitative Validierung
Mit fünf Bestandskunden wurden moderierte Tests am Klick-Dummy durchgeführt. Beobachtet wurden insbesondere:
Auffinden einzelner Mitglieder in der Liste
Verständnis der Aufteilung zwischen Listenansicht und Detailseite
Nachvollziehbarkeit der Mehrfachauswahl beim Hinzufügen oder Entfernen mehrerer Mitglieder
Zentrale Erkenntnis: Mehrere Testpersonen wirkten nach der Mehrfachauswahl verunsichert, ob ihre Aktion tatsächlich wie beabsichtigt ausgeführt worden war, und scrollten die Liste anschließend noch einmal durch, um zu prüfen, ob die markierten Namen wirklich verschwunden waren. Einige Nutzer tippten außerdem auf den Zurück-Button, bevor sie ihre Änderungen bestätigt hatten, und verloren dadurch ihre Auswahl.
Als Reaktion auf diese Beobachtungen wurden zwei Bestätigungsdialoge ergänzt ("Folgende Änderungen übernehmen?" und "Änderungen verwerfen?").
1. Aufteilung auf Liste und Detailseite
Was sich geändert hat
Was in der Web-Version auf einer einzigen Seite nebeneinander Platz fand, wurde für Mobile in zwei Ebenen aufgeteilt: eine Übersichtsliste mit allen Mitgliedern der Box und einer Chevron-Angabe nach rechts sowie eine Detailseite pro Nutzer mit den einzelnen Berechtigungen und einem „Remove user"-Button.
Warum das wichtig ist
Die Detailseite entlastet die Übersicht visuell und reduziert die Informationsdichte auf das mobil Notwendige. Der Chevron signalisiert eindeutig, dass sich hinter jedem Eintrag eine Unterseite verbirgt.
2. Alphabetische Gliederung nach Kontaktlisten-Vorbild
Was sich geändert hat
Anders als in der Web-Version wurden in der Mobile-Liste Zwischenüberschriften mit den Anfangsbuchstaben der Namen eingeführt in Anlehnung an die Kontakte-Apps unter iOS und Android. Ergänzend wurde das aus der Kontaktliste bekannte Verhalten übernommen, beim Scrollen neben dem Scrollbalken das Alphabet anzuzeigen, sodass gezielt zu einem Buchstaben gesprungen werden kann.
Warum das wichtig ist
In Boxen mit vielen Mitgliedern lassen sich einzelne Nutzer so durch einen etablierten Interaktionsmechanismus deutlich schneller finden.
3. Mehrfachauswahl mit bewusst reduziertem Funktionsumfang
Was sich geändert hat
Wie in der Web-Version erlaubt auch die Mobile-Liste die Mehrfachauswahl über Checkboxen am Zeilenanfang. Mobil beschränkt sich die Mehrfach-Aktion jedoch auf das gemeinsame Entfernen mehrerer Mitglieder. Änderungen an Berechtigungen sind mobil nur für einzelne Nutzer über die Detailseite möglich.
Warum das wichtig ist
Die Nutzertests zeigten, dass das gleichzeitige Ändern von Berechtigungen für mehrere Nutzer als typische Desktop-Aufgabe wahrgenommen wurde, während das schnelle Entfernen oder Hinzufügen von Zugriffen auch mobil relevant ist. Die Reduktion vereinfacht die Oberfläche, ohne einen Kern-Use-Case zu beschneiden.
4. Plattformspezifische Unterschiede zwischen iOS und Android
Was sich geändert hat
Beim Einstieg in den Hinzufügen-Flow folgen die Apps den Konventionen ihrer jeweiligen Plattform:
Android: Einstieg über den Floating Action Button (FAB) in der rechten unteren Ecke, erkennbar am Plus-Icon
iOS: Einstieg über einen „Edit"-Button in der Toolbar oben rechts, da der FAB dort unüblich ist
Auch beim Aufbau der Bestätigungsdialoge wurden plattformspezifische Muster berücksichtigt: Auf iOS stehen die beiden Optionen in der Regel untereinander, auf Android nebeneinander.
Warum das wichtig ist
Die App soll sich auf beiden Plattformen nativ anfühlen, ohne dass Nutzer erst ein idgard-spezifisches Interaktionsmuster erlernen müssen.
5. Vereinheitlichung zwischen iOS und Android nach Nutzerfeedback
Was sich geändert hat
In einer frühen Variante für iOS befand sich die Checkbox bei der Mehrfachauswahl rechts neben dem Namen, zudem wurden auf der Detailseite eines Nutzers iOS-typische Toggles für die Berechtigungen verwendet. Im Nutzertest zeigte sich, dass der plattformübergreifende Wechsel zwischen iOS und Android dadurch anstrengend war, insbesondere für Administratoren, die beide Betriebssysteme parallel nutzen.
Daraufhin wurde die Checkbox-Position in iOS auf die linke Seite verlagert und auch auf der Detailseite einheitlich mit Checkboxen (statt Toggles) gearbeitet.
Warum das wichtig ist
Die Entscheidung ist ein bewusster Trade-off: In Nuancen Abstand zu iOS-Konventionen zu nehmen, um im Gegenzug eine konsistente Bedienung über beide Plattformen hinweg zu ermöglichen, was für den konkreten Enterprise-Kontext den größeren Nutzwert hatte.
Die Mitglieder-Verwaltung wurde in beiden Mobile-Apps erfolgreich ausgeliefert. Bestandskunden nahmen die Funktion positiv auf, insbesondere die Möglichkeit, unterwegs schnell Zugriffe zu erteilen oder zu entziehen, ohne dafür einen Computer aufsuchen zu müssen.
Eine unmittelbar isolierbare Verbesserung der Nutzerzufriedenheit allein auf dieses Feature zurückzuführen, war nicht möglich, da parallel weitere Funktionen in die Mobile-Apps einflossen. Die stetig steigenden Download-Zahlen der Apps im Anschluss legen jedoch nahe, dass der Ausbau der mobilen Funktionalität insgesamt gut angenommen wurde.
Das Projekt war eine konzentrierte Auseinandersetzung mit den Unterschieden zwischen iOS und Android. Besonders deutlich wurden die teils subtilen Abweichungen in Interaktionsmustern (Floating Action Button auf Android vs. Edit-Button in der iOS-Toolbar, horizontale vs. vertikale Dialog-Buttons, unterschiedliche Konventionen für Steuerungselemente wie Toggles oder Checkboxen). Die parallele Arbeit mit den Figma-Templates beider Design-Systeme hat mein Verständnis für plattformkonforme Gestaltung spürbar vertieft.
Gleichzeitig wurde für mich deutlich, dass plattformkonforme Gestaltung kein Selbstzweck ist. Die Entscheidung, bei Checkbox-Position und Steuerungselementen zugunsten plattformübergreifender Konsistenz zu vereinheitlichen, war das Ergebnis einer konkreten Nutzerbeobachtung, nicht einer allgemeinen Regel. Diese Abwägung zwischen Plattformtreue und produktinterner Konsistenz nehme ich seitdem als wiederkehrendes Thema in Multi-Plattform-Projekten wahr.
Da dies zudem eines meiner ersten größeren Projekte als UX-Designer war, habe ich auch den Umgang mit JIRA und GitLab sowie das Zusammenspiel mit Product Owner und Entwicklungsteam im agilen Kontext vertieft: Mock-ups und Klick-Dummys so früh wie möglich bereitzustellen, damit der Entwicklungsfortschritt nicht durch fehlende Designvorlagen ausgebremst wird.
