Welche Fehler bei der Software-Entwicklung
gemacht werden können
Bis heute galt und gilt die Mensch-Maschine-Schnittstelle
(MMI für Man-Machine-Interface) bzw. das Graphical User Interface
(GUI) als vernachlässigte Komponente vieler Entwicklerfirmen. Ein
primärer Fehler ist die falsche Verteilung der Aufgaben.
Wenn Programmierer
das User Interface gestalten:
Programmierer können Anwender-Probleme meist schlecht nachvollziehen, da ihr spezialisierter Blickwinkel und ihre Priorität in der Funktion eines Programmes liegt. Sie halten sich zwar meist an Guidelines, aber deren Einhaltung allein genügen nicht für eine brauchbare Mensch-Maschine-Schnittstelle. (Siehe auch das Falsch/Richtig-Beispiel "E-Banking")
Wenn Graphic-Designer
das User Interface gestalten:
Insbesondere Werbeleute und Grafiker bringen sich bei der Gestaltung der Benutzeroberfläche immer mehr ein. Es liegt aber in deren Natur, vorrangig Wert auf Optik und Chic zu legen und weniger auf leichte Verständlichkeit. Manch optisch formvollendetes Programm erweist sich als zeitraubendes und unverständliches Ärgernis für den Anwender. (Siehe auch das Falsch/Richtig-Beispiel "Telefonverzeichnis")
Ideale Aufgaben-Verteilung bei einem Software-Projekt:
Ein Software-Projekt geht idealerweise durch folgende Hände und Stationen:
1. Schritt - Auftraggeber / Projektleiter
2. Schritt - Usabilty Labor (Architektur & MMI bzw. GUI)
3. Schritt - Texter
4. Schritt - Grafiker
5. Schritt - Usability-Tester
6. Schritt - Programmierer
ITusability
ist das Bindeglied zwischen
Benutzer, Programmierer und Graphic-Designer.
Unsere übliche Vorgangsweise
Grundsätzlich ist in unser Arbeits-Ansatz
immer praktisch ausgerichtet.
Das bedeutet, dass bei einem Software-Projekt zunächst versucht
wird, bereits Vorhandenes zu isolieren und auszunützen.
1
Was exisitiert bereits, was kann übernommen
werden?
Zu Beginn eines Projektes sichten wir das existierende Material und
Konzepte. Von diesem filtern wir heraus, was verwendbar ist und was
geändert werden muss.
2
Allgemeines, Grundsätzliches
In unseren Entwürfen versuchen wir soweit
als möglich auf Designwünsche (CI und CD) unserer Auftraggeber
einzugehen. Wir forschen zwar permanent
an neuen Bedienelementen und -methoden, setzten diese aber erst ein,
wenn wir sicher sein können, wenn sie vom Entwicklerwerkzeug des
Auftraggebers ermöglicht und umgesetzt werden können.
3
Standards, Richtlinien
Standards bzw. Styleguides sind festgelegte, meist
auch aus der Geschichte entstandene formale und logische Richtlinien,
an die sich ein Produkt oder Software halten muss. Wir halten uns immer
an Standards bzw. Styleguides, aber diese sind nicht oft noch nicht
klar definiert oder schlichtweg unbrauchbar. In diesem Fall legen wir
vorsichtig, dem Benutzer nicht auffällige neue Richtlinien fest,
ganz nach dem Motto "Das Bessere ist des Guten Feind". Als weitere Richtlinie
berücksichtigen wir die Gesetzteskonformität (z.B. Verstoß
gegen die guten Sitten etc.) sowie die ISO 9241.
4
EN ISO 9241
Die 1946 gegründete internationale Organisation
für Standards (ISO) hat auch unter ISO 9241 auch Standards für
Software-Ergonomie definiert. Diese sind jedoch sehr allgemein gehalten.
Soweit vorhanden halten wir uns an die ISO Standards, aber wir haben
diese für uns noch erweitert und genauer spezifiziert.
5
Navigation, Aufbau
Wir entwickeln bei unseren Projekten vom logischen
und formellen Aufbau eine schlichte, klare Führung, die meist auf dem
System "Sehen & Verwenden" basiert.
Dazu muß ein Usability-Experte eine Applikation vorerst selbst
ganzheitlich verstehen. Dies ist so zu verstehen, dass der Benutzer
so lange ohne Datenballast navigiert, bis er am Ziel angekommen ist,
das er zu sehen bzw. bearbeiten wünscht. Der Benutzer muss sich bei
unseren Anwendungen stets im Klaren sein, was
er warum zu tut und welchen Weg er gerade
beschreitet. Eine weitere Priorität ist, so wenig Ebenen wie möglich
anzubieten. Dies funktioniert natürlich nur zum Schein (manche unserer
Projekte vermitteln trotz erheblicher Programmtiefe nur sehr wenige
Navigationsebenen), aber es verwirrt den Benutzer nicht unnötig.
6
Der Situations-Navigator
Wird bei unseren Projekten meist in Form einer
"Ich will..." Schaltfläche dargestellt.
Es ist bei vielen Anwendungen mit sehr spezifischen Anforderungen eine
Sache, dem Benutzer zu zeigen, was er zu tun vermag, eine andere begreiflich
zu machen, wozu er es braucht. In der Regel steht der Benutzer vor einer
Situation, die er schnell zu meistern sucht. Wir versuchen von mehreren
Seiten an den Benutzer zu kommen. Anhand klassisch konstruierter Beispiele
führen wir den Benutzer zielsicher zum Ergebnis.
7
Leichte Verständlichkeit - Intuitive Erfassbarkeit - keine Übeaschungen
Jede Maske (Screen), in die der Benutzer gelangt,
muss von ihm bewusst gewollt sein, wie schon im vorigen Punkt beschrieben.
Auf einer Maske selbst muss er sich durch seinen logisch richtigen Aufbau
sowie durch wohldurchdachte Texte sofort und intuitiv zurechtfinden.
Von dort sollte er auch wieder zurück können, wenn dies nicht
ermöglicht werden kann, muss er zumindest die Möglichkeit
haben, abzubrechen.
8
Texte, Sprache, Schriftbild
Besonderes Augenmerk legen wir auf Texte. Diese
müssen kurz, einfach und verständlich
sein. Dabei gibt es verschiedene Methoden
einer Anwendung, sich dem Benutzer zu nähern.
Ein weiteres Problem unserer Zeit ist, dass Benutzer
kaum noch zu lesen bereit sind, sondern bestenfalls "scannen"
(Wir nennen es den neuen Analphabetismus). Um diesen Umstand abzufangen
haben wir ein besonderes ergonomisches Schriftbild entwickelt. Wir verwendeten
es bereits vor Jahren in unseren Handbüchern und es wird inzwischen
auch gerne von Werbeagenturen angewendet.
9
Performance
Die Performance ist ebenfalls Teil der Usability.
Bei Web- als auch bei normalen Anwendungen versuchen wir ein Modell
zu erarbeiten, welches mit einem Minimum
an überflüssigen und zeitraubenden Zusatz-Funktionen
auskommt. Warten gilt neben Unübersichtlichkeit als besonders lästig
beim Benutzer - besonders im WEB. Bei Funktionen und Links, welche doch
mit erheblicheren Ladezeiten verbunden sind, aber nicht unbedingt benötigt
werden, geben wir die an, wie lange es dauern kann. Ein Benutzer, der
weiß, worauf er sich einlässt, ist ein gefasster Benutzer und wird nicht
so leicht unnötigen Ärger aufbauen.
10
Optik
Natürlich muß eine Anwendung gut aussehen.
Aber bei unserer Entwicklung steht immer Funktionalität
vor Optik. Wie im vorigen Punkt Performance
bereits beschrieben liegt es in unserer Philosophie, mit möglichst wenig
Beiwerk auszukommen. Damit haben wir nicht nur die Performance vor Augen,
sondern wir wissen auch, dass optische Überreizung kontraproduktiv wirken
kann. Des Weiteren stellen wir die optischen Möglichkeiten ausschließlich
in den Dienst der einfachen Benutzbarkeit und weisen unsere Graphiker
an, ein weitgehend anfassbares Erscheinungsbild zu erarbeiten.
11
Multimedia
Auch hier gelten ähnliche Vorgaben wie im
vorigen Punkt, in diesem Falle lautet sie aber: Funktionalität
vor Optik. Übertriebene Multimedia-Effekte
degradierten mach ernsthafte Anwendung zum Kinderspielzeug, worunter
die Seriosität einer Applikation leiden kann. Ernstzunehmende Anwendungen
dürfen und sollen sich sehr wohl dieser Effekte bedienen, aber
diese im Sinne der leichten und schnellen Benutzbarkeit einsetzen (z.B.:
Animationen oder Videos, die besonders schwierige fachliche Zusammenhänge
erklären). Dabei dürfen sie nicht nur die Performance des
Rechners belasten sondern auch nicht die Geduld des Benutzers. (z.B.
nicht abschaltbare Animationen). Ein Beispiel sinnvoll angewendeter
Mulimedia ist der vorgelesene Text.
12
Testen
Alle unsere Entwicklungen müssen auch der
Kritik unserer Tester standhalten. Diese setzen wir allerdings nicht
erst am Ende ein, sondern regelmäßig bereits
während der Entwicklung. Unsere Tester
rekrutieren sich aus alle Benutzer-Schichten und dürfen alles,
nur nicht - salopp formuliert - "Computer-Freaks" sein.
8 gute
Gründe mit Usabilty-Spezialisten zu arbeiten
1
Keine Mehrkosten
Die Architektur, also die Abläufe sowie Benutzeroberflächen
Ihrer Anwendung sind ein fixer Bestandteil der Entwicklung - ganz gleich,
wer diese wahrnimmt. Wenn die Aufgaben von Anfang an unter den jeweiligen
Spezialisten aufgeteilt werden, bleiben die Gesamtkosten
der Entwicklung gleich. (Siehe auch "Kosten")
2
Geringere Service-Kosten
Leicht verständliche Anwendungen haben geringeren
Schulungs-, Coaching- und Dokumentationsaufwand
und reduzieren den Hotline-Aufwand.
3
Einfache Benutzbarkeit
Ihre Anwendungen werden von End-Benutzern
schnell und mit geringem Aufwand beherrschbar
sein, also ohne Gebrauchsanweisung, Hilfe-Funktionen und Schulungen.
Ihre Hotline wird nur mit wirklich wichtigen Fragen belastet.
4
Einfache Handhabe
Ermüdende Umwege, unnötige Schritte sowie
Dialoge werde vermieden. Umständliche Mauswege, sogenannte "Mauskilometer"
werden verkürzt.
5
Reputation Ihrer Anwendung am Markt
Ihre Anwendung erzeugt positive Anerkennung
bei Benutzern und Kunden, denn die Bereitschaft der End-Benutzer, Handbücher
zu studieren oder Schulungen zu besuchen, wird immer geringer. Ihr Vertrieb
wird mit wirksamen Argumenten versorgt.
(Siehe auch "Referenzen")
6
Styleguides
ISO-Normen und plattform-spezifische
Styleguides und werden eingehalten. (Siehe auch "Lexikon")
7
Performance
Teil der operativen Usability ist
auf die Performance der Anwendung zu achten. Eine Applikaton muß
schnell agieren und reagieren. Überfrachtung durch beispielsweise
Multimedia-Einlagen sollen vermieden werden.
8
Akzeptanz bei Programmierern
Unsere Konzepte werden von den Programmier-Teams
gerne angenommen, da wir deren Arbeit deutlich erleichtern.