Eine eigene Kategorie wert? Kann sein.
Die hier unten ist aus WordPress und gehört eigentlich in die Rubrik „Humor“. đ
Monat: August 2007
Gute Beispiele ..
Beinahe hĂ€tte ich vergessen, eine Kategorie fĂŒr „Gute Beispiele“ vorzusehen.
Die findet man leider schwer, weil man sie gar nicht wahrnimmt. Usability ist ein Hygienefaktor: das fÀllt erst auf, wenn es fehlt.
Also hier ein Beispiel aus einer meiner Vorlesungen: (ich weiĂ nicht mehr von welcher Website) – ein gutes Beispiel, weil hier fĂŒr einen Ablauf ein Fortschrittsanzeiger verwendet wird, der dem User zeigt:
- Woher komme ich?
- Wo bin ich?
- Was kann ich hier tun?
- Wie komme ich hier wieder weg?
Impressumspflicht
Witzig: Wie das Oberlandesgericht MĂŒnchen darauf achtet, dass das Impressum gefunden wird: http://www.web-blog.net/index/C0_8_1/
(Das ist jetzt möglicherweise ein „Trackback“, die Blogger-Sprache ist mir leider noch nicht ganz klar.)
FeldlÀnge
Man beachte die LĂ€nge des Feldes fĂŒr das Wunschgehalt in diesem Online-Bewerbungsformular. Die GehĂ€lter in diesem Unternehmen dĂŒrften ja nicht schlecht sein!
Schlechte Beispiele – Web
Wahrscheinlich braucht man dafĂŒr eine eigene Rubrik. Ich sehe ja ein, dass Grafiker und Webdesigner spektakulĂ€res Design brauchen, um sich verkaufen zu können, aber wenn ich auf der Seite keine einzige Kontaktmöglichkeit, nicht mal eine Telefonnummer finde?: http://www.ie-net.at/
Softwareentwicklungsprozesse sind immer anders ..
In der Theorie gibt es schöne Vorstellungen von Softwareentwicklungsprozessen, in der Praxis werden diese sehr abwechslungsreich gelebt.
Z.B. versteht unter einem Pflichtenheft jeder etwas anderes. In manchen Projekten gibt es ein Lastenheft und ein Pflichtenheft, in manchen nur eines davon, manchmal sind im Pflichtenheft schon fertige Screens drin, manchmal nicht.
Unter einem User Requirements Dokument versteht auch wieder jeder etwas anderes. Usability Fachleute wĂŒrden darin hauptsĂ€chlich die âEnduserâ Anforderungen finden wollen, wĂ€hrend in der reinen Softwareentwicklung der User hier eher als âKundeâ ĂŒbersetzt wird. Das macht aber einen ziemlichen Unterschied, vor allem was die Benutzerfreundlichkeit des Endergebnisses betrifft.
Oft fehlt schon bei der Erstellung des Pflichtenhefts ein klarer Prozess, der z.B. dazu fĂŒhren sollte, dass nicht nur Wunschlisten gesammelt werden, sondern auch PrioritĂ€ten festgelegt werden.
Aber das sind eben so Traumvorstellungen. Ich erlebe es ja auch selbst, dass Vorgangsweisen in der Softwareentwicklung ĂŒberall anders sind.
Gerade war ich in einem Projekt, in dem ein ehemaliger Enduser und ich gemeinsam das Pflichtenheft erstellt haben und wir hatten tatsĂ€chlich die Möglichkeit, auch andere Enduser einzubeziehen und mit Prototyp-Screens ganz frĂŒhe Usability Tests zu machen. Und weil Usability in dem Projekt groĂ geschrieben wird, wird der Abnahme-Test ebenfalls Usability Tests beinhalten. Klar, es war nicht alles so optimal, weil eigentlich sollte man ja mit MEHR Usern testen und das möglichst direkt am Arbeitsplatz – aber immerhin – besser als garnichts. Und so ist es ja oft, getreu dem alten Motto âbesser wenig Usability als garkeineâ. Und wenn man frĂŒh im Entwicklungsprozess mit Usability beginnt zĂ€hlt die Investition ja auch doppelt und dreifach als wenn man zum SchluĂ noch versucht, Feuerwehr zu spielen.
In einem anderen Projekt wiederum wurde ĂŒberlegt, wie man im Unternehmen Usability Engineering etablieren und in den vorhandenen EntwicklungsprozeĂ integrieren kann. Das sehe ich dann eher in den gröĂeren Unternehmen, die sich die BeschĂ€ftigung mit Prozessoptimierungen auch leisten können und wo nicht jeder im TagesgeschĂ€ft untergeht. Bleibt dort nur zu hoffen, dass der neue EntwicklungsprozeĂ nicht als Papiertiger im Schrank verstaubt, sondern auch wirklich gelebt wird.
Beide Projekte waren aber wieder mal ein sehr positiver Hinweis darauf, dass sich Usability Engineering weiter etabliert und tatsÀchlich passiert.
User Interface eines Parkplatzes
Dieses User Interface sieht man öfter, wenn man einen privaten Parkplatz benutzen möchte. Vor dem Auto ist der Schranken, man fĂ€hrt hin und ĂŒberlegt dann, wo man hier drĂŒcken könnte.
Wieder mal als unfreiwillige Testperson unterwegs sah ich hier eigentlich gar nichts, wo ich drĂŒcken kann und habe wieder zurĂŒckgeschoben und bin zur zweiten Einfahrt gefahren. Ich glaube, es liegt daran, dass der Knopf zu klein ist und die Ăffnungen fĂŒr das Mikrophon aussehen wie ein Pfeil, der auf das kleine KĂ€stchen mit den LĂ€mpchen zeigt, von dem ich nicht weiĂ, wofĂŒr es gut ist.
An der zweiten Einfahrt sah der Automat so ĂHNLICH aus, aber nicht genauso:
Jedenfalls wurde mir HIER dann klar, dass man auf den kleinen Knopf, der fast aussieht wie eine Schraube, auch drĂŒcken kann und dass man oben reinsprechen kann. Hurra! Diese Variante scheint ETWAS besser zu funktionieren als die erste.
Herzlich Willkommen!
Norbert und ich dachten, das ist ein guter Platz, um sich ĂŒber Usability auszutauschen. Viel SpaĂ!