Usability – die Gebrauchstauglichkeit einer Anwendung – wird oft als Komfortfrage behandelt. Tatsächlich ist sie eine Frage von Durchlaufzeit, Fehlerquote und Datenqualität.

Der Unterschied zeigt sich bei internen Systemen besonders deutlich. Bei einer Kundenanwendung ist schlechte Bedienbarkeit sofort spürbar: Nutzer springen ab. Bei einer internen Anwendung gibt es diese Rückmeldung nicht. Die Mitarbeitenden können nicht ausweichen – sie arbeiten sich durch, bauen Umwege oder führen nebenher eigene Listen. Das System gilt weiter als eingeführt, während die eigentliche Arbeit teilweise daneben stattfindet.

Genau deshalb bleiben Usability-Probleme in Unternehmen oft jahrelang unbemerkt. Sie erzeugen keine Beschwerden, sondern Gewöhnung.

Dieser Artikel zeigt, woran sich Bedienprobleme konkret erkennen lassen, welche Muster immer wiederkehren und wie sich bestehende Systeme mit überschaubarem Aufwand spürbar verbessern lassen.

• Was Usability konkret bedeutet
• Warum Probleme in internen Systemen unentdeckt bleiben
• Typische Problemmuster
• Wie Sie Probleme sichtbar machen
• Verbesserungen mit überschaubarem Aufwand
• Besonderheiten von Unternehmenssoftware
• Usability dauerhaft verankern
• Fazit
• FAQ zur Usability

Usability beschreibt, wie gut sich eine Aufgabe mit einem System erledigen lässt. Die ISO 9241-11 beschreibt Usability anhand von drei zentralen Ergebnissen der Nutzung: Effektivität, Effizienz und Zufriedenheit – jeweils bezogen auf bestimmte Nutzer, Ziele und einen konkreten Nutzungskontext.

Für die Praxis lässt sich das in eine einfachere Frage übersetzen: Kann jemand, der die Aufgabe kennt, aber das System nicht, sie ohne fremde Hilfe abschließen?

Für die konkrete Gestaltung lassen sich zusätzlich bewährte Interaktionsprinzipien heranziehen. Im Unternehmensalltag sind insbesondere folgende Prüffragen hilfreich:

Für Unternehmenssoftware ist die Aufgabenangemessenheit besonders relevant. Ein System kann in jeder Einzelmaske sauber gestaltet sein und trotzdem im Alltag schwer nutzbar bleiben, wenn der vorgegebene Ablauf nicht zur tatsächlichen Arbeit passt.

Die strategische Perspektive – warum sich Investitionen in Bedienbarkeit rechnen und wo sie sich am schnellsten lohnen – behandelt der Beitrag zum UX Design. Dieser Artikel bleibt bei der konkreten Verbesserung bestehender Anwendungen.

Bei internen Anwendungen fehlen die Rückmeldemechanismen, die an anderer Stelle selbstverständlich sind. Vier Gründe wirken zusammen:

• Keine Ausweichmöglichkeit. Wer mit der Anwendung arbeiten muss, arbeitet mit ihr – unabhängig davon, wie mühsam das ist. Es gibt keine Abbruchquote, die jemandem auffällt.
• Gewöhnung. Nach einigen Wochen erscheinen Umwege normal. Auf die Frage, ob es Probleme gibt, lautet die ehrliche Antwort dann „nein" – obwohl bei der Beobachtung derselben Person vier vermeidbare Schritte sichtbar würden.
• Falsche Zuschreibung. Bedienprobleme werden häufig als Schulungsbedarf oder als individuelle Ungeschicklichkeit gedeutet. Dass wiederholt derselbe Fehler an derselben Stelle passiert, ist aber ein Hinweis auf die Gestaltung, nicht auf die Person.
• Trennung von Entscheidung und Nutzung. Über die Anschaffung entscheiden Personen, die selten täglich damit arbeiten. In der Auswahl zählen dann Funktionslisten – und die enthalten keine Angabe darüber, wie viele Schritte ein Standardvorgang braucht.

Die Folge ist eine unsichtbare Dauerbelastung. Sie taucht in keiner Auswertung auf, weil sie sich über viele kleine Verzögerungen und gelegentliche Korrekturen verteilt.

Bestimmte Muster wiederholen sich über Branchen und Systeme hinweg.

Das erste Muster verdient besondere Aufmerksamkeit, weil es die Datenqualität direkt beschädigt. Pflichtfelder werden meist mit guter Absicht eingerichtet – um Vollständigkeit zu sichern. Ist die Angabe zum Zeitpunkt der Eingabe aber nicht verfügbar, wird sie erfunden. Ein Feld mit „xxx" oder „wird nachgereicht" ist schlechter als ein leeres Feld, weil es Vollständigkeit vortäuscht.

Das dritte Muster ist das folgenreichste. Verlangt das System eine Reihenfolge, die es im realen Ablauf nicht gibt, entstehen die typischen Nebenlisten. Diese Listen sind kein Disziplinproblem – sie sind die genaueste vorhandene Beschreibung dessen, was das System nicht abbildet, und damit der beste Ausgangspunkt für Verbesserungen.

Es braucht keine aufwendige Untersuchung, um die gravierendsten Probleme zu finden. Drei Zugänge liefern schnell belastbare Hinweise.

Zusehen statt fragen. Setzen Sie sich für eine halbe Stunde neben eine Person, die einen typischen Vorgang bearbeitet. Bitten Sie darum, laut mitzudenken. Greifen Sie nicht ein, auch wenn Sie den kürzeren Weg kennen – genau an den Stellen, an denen Sie eingreifen möchten, liegt das Problem.

Ein Usability Test geht einen Schritt weiter als eine allgemeine Befragung. Anwender erhalten eine konkrete, realistische Aufgabe und bearbeiten sie möglichst selbstständig im System. Beobachtet wird nicht, ob ihnen die Oberfläche „gefällt“, sondern ob sie ihr Ziel erreichen, wo sie stocken, welche Fehler auftreten und welche Unterstützung sie benötigen.

Für eine erste interne Prüfung reichen häufig wenige kritische Standardvorgänge:

• einen neuen Vorgang anlegen
• Informationen suchen oder ändern
• einen Fehler korrigieren
• einen Vorgang freigeben oder abschließen

Wichtig ist, während der Aufgabe nicht zu helfen. Gerade die Stellen, an denen Unterstützung notwendig wäre, liefern die wertvollsten Hinweise für Verbesserungen.

Neue Mitarbeitende beobachten. In den ersten zwei Wochen ist noch keine Gewöhnung eingetreten. Was in dieser Zeit an Fragen auftaucht, ist eine präzise Liste der nicht selbsterklärenden Stellen. Diese Fragen sollten festgehalten statt nur beantwortet werden.

Vorhandene Spuren auswerten. Supportanfragen, Korrekturbuchungen, wiederholte Stornierungen und Auswertungen mit auffällig vielen Platzhaltern zeigen, wo es klemmt. Diese Daten liegen bereits vor und kosten nichts.

Ergänzend lohnt der Blick auf die Nebenlösungen: Jede Tabelle, jede Notiz und jede Vorlage, die neben dem System entstanden ist, markiert eine Lücke.

Die DIPS GmbH unterstützt Unternehmen dabei, solche Beobachtungen strukturiert auszuwerten und in konkrete, umsetzbare Änderungen zu übersetzen – auch bei Systemen, die nicht selbst entwickelt wurden.

Nicht jede Verbesserung erfordert ein Entwicklungsprojekt. Erfahrungsgemäß lässt sich ein erheblicher Teil der Reibung mit Mitteln beseitigen, die in der Konfiguration oder Organisation liegen:

• Pflichtfelder überprüfen: Welche Angaben sind zum Zeitpunkt der Eingabe wirklich verfügbar? Alles andere wird später ergänzt oder entfällt.
• Standardwerte setzen: Was in neun von zehn Fällen gleich ist, sollte vorbelegt sein.
• Begriffe angleichen: Feldbezeichnungen an die Sprache des Fachbereichs anpassen, nicht an die Datenbankstruktur.
• Ansichten aufräumen: Selten genutzte Felder ausblenden oder in einen zweiten Bereich verschieben.
• Reihenfolge anpassen: Masken so sortieren, dass sie dem tatsächlichen Arbeitsablauf folgen.
• Fehlermeldungen umformulieren: nicht nur benennen, was falsch ist, sondern was zu tun ist.
• Häufige Vorgänge als Vorlage anlegen: Wiederkehrendes muss nicht jedes Mal neu erfasst werden.

Diese Maßnahmen kosten meist Stunden statt Wochen und wirken sofort spürbar. Sie eignen sich deshalb besonders gut als Einstieg, weil sie zeigen, dass Rückmeldungen etwas bewirken – die Voraussetzung dafür, dass beim nächsten Mal überhaupt wieder jemand etwas meldet.

Vorgehen in vier Schritten:

1. Sammeln: Beobachtungen, Rückfragen, Nebenlisten zusammentragen
2. Priorisieren: nach Häufigkeit des Vorgangs und Schwere der Folgen
3. Umsetzen: mit den einfachsten Maßnahmen beginnen
4. Rückmelden: den Beteiligten zeigen, was sich aufgrund ihrer Hinweise geändert hat

Schritt vier wird regelmäßig ausgelassen und entscheidet über alles Weitere.

Bleiben nach diesen Maßnahmen wesentliche Probleme bestehen, liegt die Ursache meist nicht in der Oberfläche, sondern im zugrundeliegenden Ablauf. Dann ist der Blick auf den Prozess der richtige nächste Schritt – oder auf die Automatisierung jener Erfassungsschritte, die sich ganz vermeiden lassen.

Interne Fachanwendungen unterscheiden sich in mehreren Punkten von Anwendungen für Endkunden – mit Folgen für die Verbesserungsarbeit:

• Anwender sind Fachleute, keine Gelegenheitsnutzer. Sie arbeiten täglich mit dem System. Deshalb zählt Effizienz mehr als Einfachheit: Tastaturbedienung, Massenbearbeitung und Wiederholbarkeit sind hier wichtiger als eine besonders reduzierte Oberfläche.
• Der Funktionsumfang ist groß. Anders als bei einer Kundenanwendung lässt sich nicht alles weglassen. Die Aufgabe besteht darin, Selten- von Häufiggenutztem zu trennen und Letzteres in den Vordergrund zu stellen.
• Rollen unterscheiden sich stark. Was für die Buchhaltung sinnvoll ist, behindert den Vertrieb. Rollenspezifische Ansichten sind deshalb oft wirksamer als ein Kompromiss für alle.
• Der Handlungsspielraum ist begrenzt. Bei Standardsoftware lässt sich die Oberfläche nicht frei ändern. Umso wichtiger sind Konfiguration, Vorlagen, Standardwerte und – wo nötig – organisatorische Anpassungen des Ablaufs.

Ein weiterer Punkt betrifft die Auswahl neuer Systeme: Verlangen Sie in Anbieterpräsentationen, dass ein typischer Vorgang von Anfang bis Ende gezeigt wird – idealerweise von einer Person aus dem eigenen Fachbereich selbst durchgeklickt. Eine Funktionsliste sagt nichts darüber aus, wie viele Schritte der häufigste Vorgang braucht.

Ein verwandtes Thema ist die digitale Barrierefreiheit. Sie verfolgt teils dieselben Ziele – klare Struktur, verständliche Sprache, erkennbare Bedienelemente – unterliegt aber eigenen rechtlichen Anforderungen und wird deshalb in einem eigenen Beitrag behandelt.

Ohne feste Zuständigkeit verläuft jede Verbesserung im Sand. Drei Elemente genügen für den Anfang:

• Ein benannter Ansprechpartner je System. Eine Person, an die Rückmeldungen gehen und die entscheidet, was umgesetzt wird. Ohne diese Rolle versanden Hinweise zwischen Fachbereich und IT.
• Ein einfacher Meldeweg. Niederschwellig und ohne Formular. Wichtig ist nicht das Werkzeug, sondern dass jede Meldung eine Antwort bekommt – auch wenn sie „nicht umsetzbar, weil…" lautet.
• Ein fester Termin. Zweimal im Jahr eine Stunde, in der gesammelte Rückmeldungen gesichtet und priorisiert werden. Ohne Termin passiert es nicht, weil es nie dringend ist.

Zusätzlich sollte Bedienbarkeit bereits in der Anforderungsphase vorkommen. Eine Anforderung wie „Der Standardvorgang ist in höchstens fünf Schritten abschließbar" ist prüfbar und verhindert mehr als jede spätere Korrektur. Wie sich solche Anforderungen sauber fassen lassen, behandelt der Beitrag zum Requirements Engineering.

Usability ist in Unternehmenssoftware kein Komfortthema. Schlechte Bedienbarkeit erzeugt Zeitverlust bei jedem Vorgang, Fehler mit Folgeaufwand, Rückfragen an Kolleginnen und Kollegen sowie Nebenlisten, die Daten aus dem System herausziehen.

Der Grund, warum diese Probleme lange unbemerkt bleiben, liegt in der Struktur interner Systeme: Es gibt keine Abbruchquote und keine Beschwerden, sondern Gewöhnung. Wer nicht hinschaut, erfährt nichts.

Der Einstieg ist unspektakulär und wirksam: eine halbe Stunde neben einer Person am Arbeitsplatz, die Fragen neuer Mitarbeitender festhalten und die Nebenlisten ernst nehmen, die neben dem System entstanden sind. Daraus ergibt sich fast immer eine Liste von Verbesserungen, die in Stunden statt Wochen umsetzbar sind.

Entscheidend für die Dauerhaftigkeit ist die Rückmeldung: Wer sieht, dass sein Hinweis etwas bewirkt hat, meldet auch beim nächsten Mal.

Die DIPS GmbH unterstützt Unternehmen dabei, bestehende Anwendungen aus Nutzer-, Prozess- und Umsetzungssicht zu analysieren. Dabei werden Bedienprobleme sichtbar gemacht, Ursachen eingeordnet und Verbesserungen nach Wirkung und Umsetzbarkeit priorisiert. Je nach Ausgangslage reicht das von einfachen Anpassungen an Masken, Begriffen und Standardwerten bis zu Veränderungen an Prozessen, Anforderungen oder Systemlogiken.

So entsteht keine isolierte Oberflächenoptimierung, sondern eine Lösung, die im Arbeitsalltag tatsächlich funktioniert und sich nachhaltig in bestehende Abläufe integrieren lässt.

Usability beschreibt, wie gut sich eine Aufgabe mit einem System erledigen lässt. Die ISO 9241-11 beschreibt Usability anhand von Effektivität, Effizienz und Zufriedenheit im jeweiligen Nutzungskontext. Praktisch bedeutet das: Kann eine Person ihre Aufgabe vollständig, mit angemessenem Aufwand und ohne unnötige Unterstützung erledigen?

Usability betrifft die Ausführbarkeit einzelner Schritte, UX die gesamte Erfahrung mit dem System einschließlich der Frage, ob ein Schritt überhaupt nötig ist. Usability ist damit der engere, konkret messbare Teil innerhalb der übergeordneten Nutzererfahrung.

Weil Mitarbeitende nicht ausweichen können und es deshalb keine Abbruchquote gibt. Nach einigen Wochen erscheinen Umwege normal und werden nicht mehr berichtet. Zusätzlich werden Bedienprobleme oft als Schulungsbedarf oder individuelle Ungeschicklichkeit gedeutet.

Zu viele Pflichtfelder, technische statt fachlicher Begriffe, Abläufe die nicht zur realen Arbeit passen, fehlende Rückgängig-Funktion, Fehlermeldungen ohne Handlungshinweis und Oberflächen, auf denen alles gleich wichtig dargestellt wird.

Eine halbe Stunde neben einer Person zusehen, während sie einen typischen Vorgang bearbeitet, ohne einzugreifen. Ergänzend die Fragen neuer Mitarbeitender in den ersten zwei Wochen festhalten und vorhandene Spuren auswerten: Supportanfragen, Korrekturbuchungen, Felder mit Platzhaltern.

Pflichtfelder überprüfen, Standardwerte vorbelegen, Feldbezeichnungen an die Fachsprache anpassen, selten genutzte Felder ausblenden, Masken in der Reihenfolge des Arbeitsablaufs sortieren und Fehlermeldungen mit Handlungshinweis versehen. Solche Maßnahmen kosten meist Stunden statt Wochen.

Anwender sind Fachleute mit täglicher Nutzung, deshalb zählt Effizienz mehr als Einfachheit. Der Funktionsumfang lässt sich nicht reduzieren, wohl aber nach Häufigkeit ordnen. Rollenspezifische Ansichten wirken meist besser als ein Kompromiss für alle Gruppen.