Bei Consumer-Apps ist gute Bedienbarkeit selbstverständlich — wer eine App nicht versteht, löscht sie. Bei interner Business-Software fehlt dieser Korrekturmechanismus: Die Mitarbeitenden müssen mit dem arbeiten, was da ist. Genau deshalb wird Usability dort oft vernachlässigt, obwohl die wirtschaftliche Wirkung erheblich ist. Dieser Beitrag zeigt, wie sich UX in Fachanwendungen systematisch verbessern lässt — mit Methoden, die sich in unseren Entwicklungsprojekten bewährt haben.
Was schlechte Bedienbarkeit tatsächlich kostet
Die Kosten schlechter UX verstecken sich in kleinen Beträgen mit großem Multiplikator. Ein Beispiel aus einem Projekt: In der Auftragserfassung eines Großhändlers benötigte ein geübter Sachbearbeiter pro Vorgang 14 Klicks und zwei Systemwechsel — bei rund 90 Vorgängen pro Tag und acht Mitarbeitenden. Nach der Überarbeitung der Maske waren es sechs Klicks ohne Systemwechsel; die eingesparte Zeit entsprach etwa einer halben Vollzeitstelle. Dazu kommen indirekte Kosten: höhere Fehlerquoten durch missverständliche Formulare, längere Einarbeitung neuer Kolleginnen und Kollegen, Schattenlösungen in Excel, weil die offizielle Anwendung als zu umständlich gilt. Wer diese Effekte einmal beziffert — Minuten pro Vorgang mal Vorgänge pro Jahr mal Stundensatz — hat in der Regel ein überzeugendes Budget-Argument für die Überarbeitung.
Warum Fachanwendungen so oft schwer bedienbar sind
Die Ursache ist selten mangelndes Können, sondern der Entstehungsprozess: Anforderungen werden von Fachverantwortlichen formuliert, die das System bereits kennen, und in Feldlisten übersetzt, die niemand am realen Arbeitsablauf überprüft. So entstehen Masken, die die Datenbankstruktur abbilden statt die Reihenfolge, in der Menschen tatsächlich arbeiten. Ein zweiter Faktor: Fachanwendungen wachsen über Jahre. Jede Erweiterung ergänzt ein Feld, einen Reiter, einen Sonderfall — und nach fünf Jahren erschließt sich die Oberfläche nur noch Eingeweihten. Dazu kommt ein struktureller Punkt: Wer die Software beauftragt und abnimmt, arbeitet meist nicht täglich damit. Die Entscheidung über die Oberfläche trifft die Projektleitung, den Preis für Umwege zahlt die Sachbearbeitung — jeden Tag aufs Neue.
Drei Methoden, die sich in der Praxis bewähren
Für Business-Software braucht es kein aufwendiges Design-Programm, sondern drei konsequent angewendete Methoden. Erstens Kontextbeobachtung: zwei bis drei Stunden neben den Anwendern sitzen und mitschreiben, wo sie zögern, klicken, umkopieren. Das liefert mehr Erkenntnisse als jeder Workshop. Zweitens aufgabenbasierte Prototypen: Vor der Entwicklung werden zentrale Abläufe als klickbarer Entwurf gebaut und mit fünf Anwendern getestet — fünf Personen decken erfahrungsgemäß den Großteil der Verständnisprobleme auf. Drittens messbare Kriterien: Für jede Kernaufgabe werden Zielwerte definiert, etwa „Angebot anlegen in unter zwei Minuten ohne Handbuch“. Damit wird Bedienbarkeit überprüfbar statt Geschmackssache. Alle drei Methoden zusammen kosten in einem typischen Projekt wenige Personentage — und verhindern Fehlentwicklungen, deren Korrektur nach dem Go-live ein Vielfaches kostet.
UX in den Entwicklungsprozess integrieren
Wirksam wird UX erst, wenn sie fester Bestandteil des Vorgehens ist — nicht eine Schleife am Ende. In unseren Projekten heißt das: Jede Anforderung wird als Arbeitsablauf beschrieben, nicht als Feldliste. Jedes größere Feature durchläuft vor der Umsetzung einen Prototypen-Test mit echten Anwendern. Und nach dem Go-live werden Nutzungsdaten ausgewertet: Welche Funktionen werden nie verwendet? Wo brechen Vorgänge ab? Diese Rückkopplung fließt in die nächste Iteration ein. Auch bei der Einführung von Standardsoftware lohnt derselbe Blick: Konfiguration, Rollenzuschnitt und das Ausblenden nicht benötigter Felder entscheiden dort maßgeblich über die Akzeptanz. Wie wir Individualentwicklung von der Anforderungsaufnahme bis zum Betrieb strukturieren, lesen Sie auf unserer Seite Dienstleistungen.
Fazit: Bedienbarkeit ist planbar
Gute UX in Business-Software ist kein Zufallsprodukt und kein Luxus, sondern das Ergebnis eines disziplinierten Vorgehens: Anwender beobachten, Abläufe vor der Entwicklung testen, Bedienbarkeit messbar machen. Der Aufwand dafür liegt typischerweise bei fünf bis zehn Prozent des Projektbudgets — und amortisiert sich über eingesparte Arbeitszeit, geringere Fehlerquoten und schnellere Einarbeitung meist innerhalb des ersten Jahres. Wenn Sie wissen möchten, wo Ihre Fachanwendungen Zeit kosten, sprechen Sie uns an — wir beraten Sie gern.
