Unsere Methoden und übliche Vorgangsweise
Grundsätzlich ist in unser Arbeits-Ansatz immer praktisch
ausgerichtet. Das bedeutet, dass zunächst versucht wird, bereits
Vorhandenes zu isolieren und auszunützen. |
|
Praktischer
Ansatz |
1
Was gibt es bereits, was kann übernommen werden?
Zu Beginn eines Projektes sichten wir das Material, das bereits vorhanden
ist und filtern 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. Auch
versuchen wir immer, mit vorhandenen Mitteln
zu arbeiten. 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.
|
|
Vor-handene
Mittel
|
3
Standards, Richtlinien
Standards bzw. Styleguides, das 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 schlicht weg 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
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.
|
|
Sehr
allgemein abgefasste ISO
|
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. 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.
|
|
Kompaktes
System simulieren
|
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. |
|
Dialog
mit Benutzer
|
7
Leichte Verständlichkeit - Intuitive Erfassbarkeit
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 einfach
und verständlich, so kurz als möglich
aber so lange wie nötig sein. Dabei
gibt es verschiedene Methoden einer Anwendung, sich dem Benutzer zu
nähern. Die übliche ist die, in welcher der Computer mit dem Benutzer
kommuniziert (Ich-Du-Dialog). Eine weitere Methode ist die von uns oft
bevorzugte "direkten Art" (Ich-Ich-Dialog), in der die Anwendung eins
mit dem Benutzer wird und ihm so nicht vorschreibt, was er zu tun hat,
sondern ihm das Gewünschte projiziert und "in den Mund" legt, was
er tun möchte bzw. kann. (z.B.: "Ich bestätige den Erhalt eines neuen
TAN-Briefes und schalte die darin enthaltenen TANs frei"). Diese sprachliche
Form der Schnittstelle hat sich bei unseren Projekten bisher immer sehr
gut bewährt.
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. Es hebt nicht nur die wichtigen
Passagen und Wörter schwarz und
fett hervor, sondern drängt das notwendige
sprachliche "Füllmaterial" grau und schmal in den Hintergrund. So kommt
der Benutzer sehr schnell zum Wesentlichen. Der vorliegende Text, den
Sie gerade konsumieren ist in diesem Schriftbild gehalten.
|
|
Keine
Angst vor Sprache
|
9
Performance
Bei Web- als auch bei normalen Anwendungen versuchen wir ein Modell
zu erarbeiten, welches mit einem Minimum
an Graphiken oder sonstigen ü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 Dateigröße an, um eine ungefähre Wartezeit zu
vermitteln Ein Benutzer, der weiß, worauf er sich
einlässt, ist ein gefasster Benutzer und wird nicht so leicht
unnötigen Ärger aufbauen.
|
|
Keine
Bremsen einbauen
|
10
Optik
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. Selbstverständlich soll
das Ergebnis am Ende auch ansprechend aussehen.
|
|
Erst
die Funktion, danach die Optik
|
11
Multimedia
Auch hier gelten ähnliche Vorgaben wie im vorigen Punkt, in diesem
Falle lautet sie aber: Funktionalität vor
Spiel. Übertriebene Multimedia-Effekte degradierten mach
ernsthafte Anwendung zum Kinderspielzeug, worunter letztlich sogar die
Seriosität litt. 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 MM ist der vorgelesene
Text. dass, wie in Punkt 8 schon beschrieben, Texte im Allgemeinen bestenfalls
überflogen werden, empfehlen wir gerne die "Vorlese-Funktion",
die lange Info-Texte einfach wie bei einem Hörbuch vorlesen.
|
|
Sinnvoller
Multimedia-Einsatz
|
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 - salopp formuliert - vor allem keine "Computer-Freaks"
sein. |
|
Tester
aus allen Schichten
|
Software-Ergonomie.com
/ Usability-Spezialisten für benutzerfreundliche
Software, Web-Sites & Steuerungen, Johann-Staud-Str. 72/B 20,
A-1160 Wien, Östereich, Europa, Tel. : +43-1-416 49 40, HOTLINE:
+43-664-300 86 64, E-Mail: office@software-ergonomie.com,
Web: www.software-ergonomie.com,
aktualisiert am 3.9.2007