Systemeinführung | Software-Entwicklung

Die drei Schlüsselaspekte von guter Usability

Die Usability von Planungsapplikationen kann man anhand von drei Aspekten beurteilen: Funktionsumfang, Bedienungskonzept sowie Reaktionszeit. Was ist damit genau gemeint? Dieser Artikel ist ein einfacher Leitfaden, um etwas Struktur ins Thema zu bringen und die Usability von Software-Applikationen einordnen zu können.

In diesem Artikel widmen wir uns einem oft kontrovers diskutierten Thema: Wann ist eine Software-Applikation gut? Oder anders gefragt: Was macht eine gute Software aus? Etwas salopp formuliert würde man wohl sagen, eine Applikation "sei dann gut, wenn sie nützlich ist und das gut kann, wofür sie gemacht wurde". Etwas formeller ausgedrückt: Die Applikation soll eine hohe Bedienungsfreundlichkeit oder Gebrauchstauglichkeit aufweisen. Zur Diskussion dieser Konzepte verwenden wir hier der Einfachheit halber den auch in deutschsprachigen Gebieten geläufigen englischen Begriff Usability.

Hmm, was genau ist Usability?

Der Begriff Usability ist nicht immer klar definiert und wird von verschiedenen Leuten mit Sicherheit auch verschieden interpretiert. Eine einfache Suche im Internet liefert eine Vielzahl von nicht immer kongruenten Definitionen. Usability kann natürlich auf beliebige von Menschen geschaffene Objekte angewendet werden (nicht nur auf Software), aber das interessiert uns hier nicht. Oft stösst man auch auf den Begriff Software-Ergonomie. Was sicher ist: Usability ist nicht auf einer absoluten Skala messbar und genau deshalb oft auch Opfer von subjektiven Wahrnehmungen. Dies führt dann zu Diskussionen, wer nun Recht hat mit seiner Beurteilung der Software.

Wir versuchen in diesem Artikel, dem Begriff Usability etwas auf den Grund zu gehen und insbesondere die Messbarkeit etwas genauer anzuschauen. Wir versuchen es mal auf eine ganz einfache Weise und unterscheiden dabei nur folgende drei Aspekte im Bezug auf die Usability einer Software-Applikation:

  • Funktionsumfang (Was kann der Anwender mit der Applikation tun?)
  • Bedienungskonzept (Wie kann der Anwender etwas tun?)
  • Reaktionszeit (Wie schnell reagiert die Applikation auf eine Anwendereingabe?)

Beleuchten wir diese Begriffe im Folgenden etwas und schauen uns jeden einzelnen genauer an.

Der Funktionsumfang: Was kann meine Applikation denn überhaupt?

Der Funktionsumfang einer Applikation ist oftmals überladen und deckt nicht wirklich das ab, was der Anwender eigentlich benötigt. Was nützt mir eine Applikation, wenn ich 80% der angebotenen Funktionen für meine Tätigkeit nicht brauche? Dieser Ballast ist in aller Regel nicht einfach nur irgendwo im Hintergrund und hat mich im Einkauf viel gekostet – nein, er behindert mich unter Umständen sogar bei der Nutzung der wirklich brauchbaren 20% der Funktionen. Gerüchten zufolge sollen bekannte Anwendungen wie Office-Produkte an dieser Krankheit leiden. Konkrete, erhärtete Statistiken findet man nicht so leicht. Und jene, die man findet, sind sicherlich mit Vorsicht zu geniessen. Jedoch lassen sich leicht Dutzende von Blog Posts im Web finden ("Die 50 Hammertipps zu Word", "Versteckte Einstellungen in Microsoft Office", "10 praktische Tipps for Word" etc.), welche darauf schliessen lassen, dass der typische Office-Anwender offensichtlich nur mit einem kleinen Teil der vorhandenen Features arbeitet und den Rest gar nicht kennt.

Eine gute Applikation hat somit möglichst genau die Funktionen, die der Anwender erwartet und täglich einsetzt. Der Ausdruck "genau diese Funktionen" ist je nach Anwender natürlich etwas anders definiert. Wenn wir uns aber eine Geschäftsapplikation vorstellen, die von einer Vielzahl von Anwendern in derselben Unternehmung oder sogar innerhalb einer Wirtschaftsbranche eingesetzt wird, dann kann man durchaus über diese Anwender hinweg einen gemeinsamen Nenner finden. Eine solche Geschäftsapplikation muss jene Funktionen anbieten, welche die typischen Geschäftsprozesse optimal unterstützt. Und wenn der Preis stimmt, ist so manche Organisation auch bereit, ihre Prozesse bei den wenigen Abweichungen von der Wunsch-Applikation auf ein Standard-Produkt anzupassen.

Das Bedienungskonzept: Wie mache ich jetzt schon wieder...?

Das Bedienungskonzept einer Applikation bestimmt, wie schnell ein Anwender jene Funktion findet und einsetzen kann, die er gerade für eine Aufgabe benötigt. Häufig spricht man von der Intuition des Anwenders bzw. davon, dass die "Applikation intuitiv zu bedienen" sei. Auch hier gilt natürlich das Prinzip der Subjektivität: Was für den Einen intuitiv ist, ist für den Anderen kompliziert und unverständlich. Hier gibt es immerhin Messmöglichkeiten. Über eine grössere Gruppe von Anwendern hinweg kann die Einfachheit in der Bedienung gemessen und ausgewertet werden. Man gibt den Probanden einfach eine Aufgabe vor, die sie mit der Applikation zu lösen haben, und misst, wie rasch sie diese auch tatsächlich hinkriegen. So kann man verschiedene, aber für denselben Zweck gebaute Applikationen einander sogar quantitativ gegenüber stellen und einigermassen objektiv (da statistisch) vergleichen. In der Praxis müssen sich verschiedene Wettbewerbsprodukte einfach dem Markt stellen. Ein rasch aufsetzbarer und genügend langer Pilotbetrieb kann da auf jeden Fall helfen.

Ein gutes Bedienungskonzept ist immer durchgängig, d.h. möglichst konsistent über alle Funktionen hinweg: Dieselben Aktionen werden auf dieselbe Art und Weise ausgeführt. Das Suchen von Objekten, das Einstellen von Darstellungen, das Öffnen und Editieren von Datenelementen, das Löschen von Objekten,... Alles funktioniert immer nach einem einheitlichen Prinzip. Gerade bei der Beurteilung des Bedienungskonzepts stellt sich heraus, ob die Entwickler der Applikation von Beginn weg einen generisch einsetztbaren Ansatz verfolgt haben, oder ob die Anwendung halt mit der Zeit immer etwas grösser geworden ist und Funktionalitäten immer wieder anders aufgerufen werden müssen, weil einfach ein roter Faden durch die Applikation hindurch fehlt.

Die Reaktionszeit: Wie lange dauert das denn nochmals!?

Zu guter Letzt ist da noch die Reaktionszeit. Die passendste (Funktionsumfang!) und intuitivste (Bedienung!) Applikation verliert enorm viel an Wert und Benutzerakzeptanz, wenn sie langsam ist. Und es braucht nicht viel, um als langsam zu gelten. Zumindest aus Sicht der oftmals sehr anspruchsvollen Anwender. Zeit ist Geld. Und niemand hat Lust, täglich viel Zeit wartend vor dem Bildschirm zu verbringen, bis die erwarteten Daten endlich vor mir auftauchen. Einige Sekunden sind bereits zu lange, wenn es um eine Funktion geht, die der Anwender alle paar Augenblicke aufruft. Die nicht vorhandene Leistungsfähigkeit einer Applikation ist im Verkauf oftmals der Tod. "Zum Glück," kann man sich vielleicht noch sagen, "ist das Konkurrenzprodukt auch nicht schneller." Aber in der heutigen Zeit, in der sich neue Technologien fast schon im Jahresrhythmus ablösen, Bandbreiten in den Netzwerken und insbesondere im Internet immer besser werden und die Leistungsfähigkeit von Computern gemäss Moore sich auch ca. alle zwei Jahre verdoppelt, in solchen Zeiten gibt es für schlechte Performance keine Ausreden mehr.

Wie erreicht eine Software-Applikation eine hohe Usability?

Man spricht häufig von User-Centered Design oder auch User-Driven Design. Damit meinen wir den Einbezug des zukünftigen Anwenders in den ganzen Entwicklungsprozess. Dies beginnt idealerweise bei der ersten Beschreibung der zukünftigen Applikation, d.h. im Requirements Engineering: Was soll die Applikation überhaupt können (Funktionsumfang)? Aus unserer Erfahrung nützt da eine rein textuelle Beschreibung dieser Anforderungen wenig. Im Bezug auf die Prosa-Formulierungen sind sich die Projektbeteiligten rasch mal einig. Der Kern der Sache liegt aber im Screen Design. Dort also wo der Anwender dann später auch tatsächlich vor dem Bildschirm sitzt und tun soll, wofür die Applikation gebaut wurde. Am besten fängt man da zu Beginn ganz einfach an, nämlich mit einfachen Skizzen am Whiteboard oder in einem geeigneten Zeichnungsprogramm. Zur Not tuts auch PowerPoint. Später müssen diese Screen Designs dann in klickbare Mock-ups gegossen werden. Damit die Anwender schon mal damit spielen können und ein Gefühl dafür entwickeln, wie denn die Usability so ist. Erst in einer späteren Projektphase kann dann mit dem Bau eines Prototypen begonnen werden. Hier kommt die Performance sprich die Reaktionszeit der Applikation das erste Mal ins Spiel. Natürlich zeigt sich diese erst so richtig (oder eben auch nicht), wenn das endgültige Mengengerüst (grössere Anzahl Anwender, realitätsnaher Datenbestand, tatsächliches Netzwerklatenz etc.) simuliert wird.

Über den Entwicklungsprozess einer Software-Applikation und den Einbezug der Anwender gibt es genügend Literatur. Wir verzichten hier darauf, auch nur mit einer Referenzliste zu beginnen. Gerne werden wir aber in einem zukünftigen Artikel auf mögliche und gute Entwicklungsmethodiken und -prozesse zurückkommen. Bleiben Sie einfach dran.

Über den Autor


Managing Director INTRASOFT AG

Dr. Daniel Hösli ist Managing Director und Lead Consultant bei der INTRASOFT AG, deren SaaS-Lösung PQFORCE die führende Plattform für agile, projekt-orientierte Unternehmensführung ist. Er ist seit 15 Jahren täglich mit dem Aufbau von Projektmanagementsystemen in beratender und projektleitender Funktion tätig - organisatorisch wie technisch - und hat so die Erfahrung aus unzähligen Kontakten und Aufgabenstellungen aus den unterschiedlichsten Unternehmungen und verschiedenen Managementebenen.

Nicht verpassen

Mit PQFORCE Insights bekommen Sie unsere neuesten Nachrichten, Best Practices, Tipps und Angebote direkt in Ihre Mailbox geliefert.
Wir werden Ihnen nur relevante, spamfreie E-Mails senden.
Sie können sich jederzeit mit einem Klick wieder abmelden.
Jetzt ausprobieren