Case Study 04neoHR · München · Public Sector Enablement2022–2023

UX-Wissen, das
im Team bleibt.

Das Ziel war nicht, dauerhaft externe UX-Hilfe zu brauchen. Das Ziel war eine Arbeitsweise, mit der Teams selbst bessere und barriereärmere Entscheidungen treffen können.

HerausforderungGroße Organisation. Unterschiedliche UX-Reife. Barrierefreiheit als Pflicht und Qualitätsanspruch.
Meine RolleSenior UX/UI Consultant · UX Lead
Mein BeitragMethodenbaukasten, MVP-Rahmen und Accessibility-Praxis gemeinsam aufgebaut.
Ergebnis & EvidenzWiederholbarere UX-Entscheidungen im Team.Organisatorische Veränderung beobachtet

Gemessen heißt: die Zahl stammt aus einer dokumentierten Erhebung im Projekt. Beobachtet heißt: die Veränderung war im Alltag sichtbar, aber nicht sauber erhoben.

neoHR Case-Study mit Methodenkarten, barrierefreien Interfaces und Workshop-Artefakten
Schaubild 04 — Kontext, System und Wirkung

01 — Die Ausgangslage

Ein Workshop ist noch keine UX-Fähigkeit.

In einer Verwaltung mit 45.148 Beschäftigten zum Stichtag 31. Dezember 2025 müssen Methoden sehr unterschiedliche Kontexte aushalten. Sie müssen verständlich, zugänglich und ohne Spezialwissen anwendbar sein.

Der Kontext:Öffentlicher Sektor, viele Rollen und Prozesse, hohe Anforderungen an Nachvollziehbarkeit und Barrierefreiheit.

Die eigentliche Aufgabe:Nicht Wissen abladen. Sondern ein Set an Methoden und Entscheidungswegen bauen, das im Alltag wirklich benutzt werden kann.

02 — Die Wirkung

Weniger Abhängigkeit. Besser begründete Entscheidungen.

45.148Beschäftigte im Organisationskontext (Stichtag 31.12.2025)
FrühBarrierefreiheit in Research, Konzept und Komponente
MVPentscheidungsreif gerahmt

Teams konnten Methoden wiederholt einsetzen, Entscheidungen nachvollziehbarer begründen und Barrierefreiheit früher in die Produktarbeit holen. Die Beschäftigtenzahl beschreibt die Organisation, nicht die Zahl der erreichten Nutzer:innen.

Öffentliche Einblicke sind im Verwaltungskontext eng gesteckt. Den Methodenbaukasten und einzelne Entscheidungswege erkläre ich gern anonymisiert im Gespräch.

Schema: vier Projektphasen mit einem durchgehenden Band für Barrierefreiheit und einem Entscheidungspunkt für den MVP-Zuschnitt.
Barrierefreiheit als durchgehendes Band, nicht als Abnahme am Ende

03 — Der Lösungsansatz

Methoden müssen selbsterklärend genug sein, um ohne uns zu funktionieren.

01

Sprache vereinfachen

Methoden aus dem UX-Jargon holen und so erklären, dass Fachseite und Produktteam direkt damit arbeiten können.

02

An echten Fällen testen

Den Baukasten nicht theoretisch perfektionieren, sondern mit laufenden Entscheidungen schärfen.

03

Accessibility einbauen

Barrierefreiheit nicht als Abnahme behandeln, sondern als Frage in Research, Konzept und Komponente.

„Enablement ist gelungen, wenn das Team die Methode nimmt und uns dafür nicht mehr anrufen muss.“Mein Maßstab für gelungenes Enablement

04 — Erkenntnisse

Was daraus hängen geblieben ist.

Einfach heißt nicht oberflächlich.

Eine klare Methode kann komplexe Entscheidungen tragen. Sie muss nur die richtige Komplexität zeigen.

Barrierefreiheit beginnt früh.

Je später sie auftaucht, desto mehr wirkt sie wie Einschränkung. Früh wird sie zum besseren Produktmodell.

Ähnlich komplexes Produkt?

Lass uns sprechen ↗