Das ist eine sehr analytische Perspektive. Und wenn ich mir jetzt überlege,
wie funktioniert das in der Praxis, ist es eher untauglich,
weil ich ja in der Praxis selten schaffe,
wirklich Laborbedingungen so sauber herzustellen,
dass ich auch tatsächlich Dinge messen kann.
Und Validität in meinen Daten erhalte. Und deswegen gibt es
außerhalb dieser eher akademischen Ansicht, gibt es eben zwei Schlagworte,
die das eine eher amerikanisch, das andere eher skandinavisch geprägt sind.
Das eine ist das Human Centered Design oder User Centered Design
Da wird der Benutzer, also aus diesem Bild raus,
könnte man sagen, ins Zentrum gestellt.
Also da geht es darum, dass dann ein Mensch,
ein Anwender, nee, sechs Beine hören nicht,
ein Anwender mit verschiedenen Systemen zu tun hat und auch wieder
mit unterschiedlichen Personen oder Personengruppen vielleicht.
Könnte man sagen, Organisationen. Das könnt ihr sagen,
das ist meine Firma, das ist mein Kunde,
sind die verschiedenen Systeme, mit denen ich zu tun habe.
Das ist im Prinzip so was ähnliches wie hier.
Hier habe ich halt die verschiedenen Systeme da drin und
die anderen sind alle irgendwo draußen rum. Aber dadurch,
dass ich das jetzt so aufzeichne, kann ich eben sagen,
es geht wirklich nur um diesen einen Anwender.
Und ich versuche jetzt alles für den Arbeitsplatz dieses Anwenders zu gestalten.
Und das ist was, wo ich denke,
das ist schon ganz gut in dieser Vorlesung auch vorgekommen.
Also alles, was um Arbeitsplatzgestaltung und Expertenarbeitsplätze gehst,
das ist schon ganz nah dran an dieser Sichtweise,
dass ich also
einen Anwender im Zentrum meines Entwurfs
haben sollte
Das, was dann noch ein Stückchen darüber hinausgeht,
ist das Participatorial Design oder Partizipative Design. Und da sagt man,
also bei dem User-Center-Design hat man halt die Wahl,
wie mache ich das jetzt eigentlich,
dass ich diesen Menschen da ins Zentrum stelle?
Ich kann ihn fragen, was er gerne haben möchte.
Ich kann ihm was vorschlagen, ich kann Dinge mit ihm diskutieren.
Ich kann vielleicht auch jetzt diese wissenschaftlichen Messungen,
die es da irgendwo gab, verwenden,
um irgendwas zu bauen, was für ihn besser ist.
Aber im Prinzip ist es so,
ich bin derjenige,
der was entwirft
Und derjenige, der da im Zentrum steht, ist derjenige,
der dann guckt, ob er damit gut zurechtkommt.
Bei dem Particide wird Holly Design ist derjenige, der entwirft der Nutzer.
Also da ist die Idee und das kommt so ein bisschen aus der Gewerkschaftsbewegung,
dass jegliche Einführung von Software immer auch eine Umgestaltung von Arbeit
ist und eine Umgestaltung von Arbeit sollten die Arbeiter beteiligt werden.
Also in der Fabrik heißt das,
dass die Fabrikarbeiter praktisch selbst gestalten,
wie sie zusammenschrauben,
ein Auto
Irgendwas anderes. Am Arbeitsplatz bedeutet das,
dass die Bildschirmarbeiter eben auch selbst entwerfen und selbst sagen,
so und so soll mein System funktionieren und sogar so und so soll es aussehen.
Und das ist also nochmal eine radikal andere Sichtweise.
Weil ich hier immer noch den Experten eigentlich außen habe,
der sagt, wie soll das gestaltet werden?
Und da ist der Experte der wichtigste, tatsächlich der Anwender selbst.
Und das ist dann schon wieder, das ist dann
schon wieder, das hätte mir auch jemand sagen können.
Das ist dann schon wieder so weit in diese User Ascentered-Richtung getrieben,
das ist auch schon wieder nicht praktisch ist.
Also das macht auch schon wieder keinen Erwärmen. Oder wenige. Was praktisch ist,
ist der Versuch aus Usability etwas zu machen,
wie Software-Engineering ja auch bietet, nämlich eine Ingenieursmäßiges Vorgehen.
Ein ingenieursmäßiges Vorgehen ist ja dadurch ausgezeichnet,
dass man einen Plan hat, dass man Methoden hat,
die man jederzeit einsetzen kann, dass man auch weiß,
wann,
welche Ergebnisse da rauskommen und dass man am Ende ein
überprüfbar gutes Produkt hergestellt hat
Und der Versuch bei Usability-Engineering ist eben eigentlich nur zu sagen,
wir können nun mal nicht anders,
wir müssen tatsächlich Software entwickeln oder entwerfen oder produzieren.
Das ist bei vielen anderen Teilen von HCI, könnte man sagen,
die sind halt Forschung. Also geht es nicht so darum,
wirklich dieses Produkt zu erzeugen. Hier geht es darum,
ein Produkt zu haben und deswegen findet man da auch ganz ähnlich wie im Software-Engineering-Prozessmodelle,
also wie soll gearbeitet werden, welche Dinge soll dann nacheinander gemacht werden.
Und da findet man im Groben auch immer wieder diese zwei Blöcke. Also es gibt verschiedene Methoden,
die dienen dem Design und es gibt verschiedene Methoden,
die dienen der Qualitätssicherung und dazwischen passiert halt die Implementierung und die
ist so ein bisschen magisch, weil das ist ja etwas,
womit sich eben Usability-Engineering nicht beschäftigt.
Also wenn man das zusammennimmt, könnte man sagen, die Methoden,
die jetzt da irgendwie eingeordnet werden in diesem Usability-Engineering,
die können sehr, sehr unterschiedlich sein.
Das wird jetzt ein, zwei Beispiele für Design-Methoden hier anbringen,
aber das ist bei weitem nicht alles, was es gibt.
Also es gibt, was jeder dieser Sichtweisen,
gibt es eben mit denen man sagt, so entwerfe ich.
Und es gibt Methoden, mit denen man sagt,
so sichere ich dann auch die Qualität. Und das ist,
je nachdem, wo ich stehe in diesem Feld, ist das ganz anders.
Und man kann also solche Methoden dann versuchen einzuordnen.
Eine Möglichkeit, sie einzuordnen, ist eben,
indem man sagt, wie stark sind Nutzer beteiligt?
Sind sie subjekt? Sind sie Objekt? Eine andere Frage,
die man stellen könnte, was ist eigentlich das,
was ich versuche zu designen oder zu evaluieren?
Es ist eher die Aufgabe und die Leistung,
die da gebracht wird, das ist sehr stark so dieser Gedanke,
ich habe eben eine Aufgabe, die ich mit meinem Rechner wirklich vollbringen muss.
Und deswegen kann man auch sehr gut messen,
wie viel ich von dieser Aufgabe schaffe und wie schnell es geht und wie richtig es ist.
Oder ist es eher so, dass ich eben messen möchte,
den Eindruck und die Emotionen, die etwas hervorruft. Also eine Seite,
die für die Fußballmesserschaft, finde ich immer ein bisschen schwierig,
aber sagen wir mal eine Seite,
die für Coca-Cola wirbt, die kann sehr schlecht,
gut oder schlecht sein im Hinblick auf Aufgabenangemessenheit,
dass da eben keine vorgegebene Aufgabe ist.
Oder auch YouTube wäre wahrscheinlich relativ schwer der Art und Weise
Was man dann noch sagen kann, ist, man kann eben sagen, wo,
hier oder da, wird die Methode eingesetzt, ganz am Anfang,
formativ heißt das dann, oder ganz hinten, summativ.
Oder ist es so, dass ich eben eher eine Methode habe,
die dem Design dient, wobei Design zusammenfasst, das,
was man in der Softwaretechnik als Worte auch hat, nämlich Analyse und Modellierung?
Oder ist es eher eine Methode, die in der Evaluation verortet ist? So,
jetzt nochmal, das,
was ich am Anfang so ein bisschen aus dem Kopf gemacht habe,
deswegen ist vielleicht etwas schneller, also bitte bremsen,
wenn ich zu schnell bin, da sind es nur nochmal ein Überblick,
über was sind alles so Felder, in denen ja,
human computer, Interaction oder Software-Agonomie verortet ist oder wo Leute herkommen,
die da drin arbeiten.
Das ist eben zum einen die Arbeitswissenschaften, zum anderen Psychologie,
Physiologie, Pädagogik. Dann gibt es die Organisationstheorien,
also eher, könnte man sagen, Volkswirtschaftslehre als Betriebswirtschaftslehre dabei.
Und dann gibt es eben diese ganzen Dinge,
die wahrscheinlich schon in Nikon 2
vorgekommen sind
Wissen über Wahrnehmung, Gedächtnis, Denken und Handeln, Handhabung lernen.
Das liegt so ein bisschen zwischen Psychologie, Linguistik und eben KI,
wo es jetzt an der Informatik dann verortet ist.
Was tut die Forschung? Sie versucht, Methoden bereitzustellen,
zum einen eben für diese drei Arbeitsbereiche, also analysieren,
modellieren, das ist das Design und evaluieren, das ist die Qualitätssicherung.
Sie versucht, Hilfsmittel bereitzustellen,
das ist nicht das Gleiche jetzt an dieser Stelle,
sondern mit Hilfsmitteln ist gemeint, dass man eben sowas macht wie eine Regel,
viel kann ich gleichzeitig im Kopf behalten,
wie viel sollte gleichzeitig auf dem Bildschirm da sein,
wie viele Farben sollte man vielleicht gleichzeitig verwenden.
Sie versucht Normen zu definieren. Also es gibt in Deutschland,
ich glaube, es ist eines der wenigen Länder,
in denen es das gibt, gibt es eine Bildschirm-Arbeitsplatz-Verordnung.
Das heißt, es ist in Deutschland vorgeschrieben,
dass Software, die an einem Arbeitsplatz läuft,
auf eine bestimmte Art und Weise benutzbar ist,
auch wenn das sehr schwer nachzuprüfen ist.
Versucht, die Forschung versucht Musterlösungen bereitzustellen,
also wie löst man ein Problem auf eine gute Art und Weise
und dazu, sagen wir mal, Techniken und Werkzeuge.
Da geht es dann eher um, wenn man versucht halt auch immer,
sowas mit Software zu unterstützen, als Wissenschaft,
die viel mit Software zu tun hat.
Was auch versucht wird, ist, dass man sagt,
wie schaffe ich eigentlich die Softwareentwicklung so zu organisieren,
also Organisationsformen entwickeln heißt jetzt nicht für den Anwender,
eine Organisationsform entwickeln, sondern eben für die Softwareentwicklung und Organisationsform zu entwickeln.
Wie schaffe ich es, Software mit mehreren Menschen erstmal so
zu entwickeln, dass dabei eben ergonomische Resultate herauskommen.
Und das ist genau diese Frage, wer ist eigentlich zuständig dafür,
dass dieses System von Mensch und Maschine gut funktioniert.
Und damit das eigentlich optimal funktionieren kann, muss man ja
sehr unterschiedliche Dinge zusammenbringen. Also man muss zusammenbringen den Anwender,
der wahrscheinlich sehr hohes Wissen darüber hat, will eigentlich seine Arbeit abläuft.
Man muss zusammenbringen, diejenigen,
die das System geschaffen haben oder die Prozesse geschaffen haben,
mit denen er jetzt zu tun hat,
weil die sehr viel darüber wissen,
was ist da eigentlich im Hintergrund an Vorausbedingungen
Mit denen der Anwender vielleicht gar nichts mehr zu tun hat,
weil er durch Software davon abgeschirmt ist,
die aber trotzdem wichtig sind für die Arbeit.
Und es gibt dann eben auch unterschiedliche Experten. Es gibt die Experten,
die wissen, welche begrenzen oder Möglichkeiten durch Software geschaffen werden.
Es gibt die Experten, die wissen,
wie ich hübsche oder angenehme Oberflächen gestalte.
Es gibt Experten für Informationsgestaltung, es gibt Experten für,
sogar für das Schreiben von Texten gibt es Experten.
Also je nachdem, was für ein Produkt man baut,
ist ja ganz unterschiedlich wichtig,
wie seine Teile gestaltet sind
Das Wesentliche an so einer Organisationsform oder an so einem Entwicklungsprozess ist,
dass man es schafft,
alle diese Experten zusammenzubringen und eben ihre Stärken oder ihr Wissen auszunutzen.
Und das ist nicht ganz einfach. Das,
was ich jetzt hier an Methoden für das Design vorstellen möchte,
ist eine etwas längere und eine etwas kürzere Methode,
beziehungsweise eine etwas länger vorgestellt, eine etwas kürzer vorgestellte,
die länger vorgestellte.
Da geht es um das Design im Kontext, könnte man sagen.
Das heißt, die ist sehr stark so, dass man sagt,
ich habe hier einen Anwender im Zentrum von irgendwas.
Und es geht darum, für den etwas zu bauen.
Und ich muss erst mal wissen,
was ist eigentlich der Kontext, in dem er das tut.
Und die andere Methode, die arbeitet ganz anders.
Deswegen habe ich den mal mitgebracht. Die heißt Szenario Base Design.
Und die ist nicht nach dem, was sie untersucht,
benannt, sondern nach dem, womit das repräsentiert wird,
was da untersucht wurde. Nämlich, da geht es darum,
immer wieder Szenarien oder kleine Geschichten zu schreiben.
Fange ich mit der Kontext zur Design-Methode an?
Fünf Schritte, Kontextserkundung als Lehrling, Kontextmodellierung, Konsolidierung,
Redesign der Arbeitsprozesse und dann Environment, User Environment Design und Storyboarding.
Als erstes, die Kontexterkundung als Lehrling oder wie die das
genannt haben, auf Englisch, Contextural Enquiry.
Also das sind jetzt beides Ansätze,
die sind schon in der Praxis auch tatsächlich eingesetzt worden.
Dieses hier ist eher von jemandem gekommen,
das ist ein Unternehmensberaterin, könnte man sagen.
Die machen das halt für Firmen. Das andere ist jemand,
der eher an der Uni arbeitet.
Aber auch das ist schon in Firmen viel verwendet worden.
Das Wichtigste in dem ersten Schritt von diesem Kontextur Design ist,
dass man eben so viel wie möglich
an Informationen aus dem Kontext holt
Das heißt, man geht als derjenige,
der später für die Entwicklung der Software zuständig ist,
in den Kontext hinein, sagt, hallo, liebe Anwender,
ich würde gerne diese Woche mit dir verbringen.
Ich setze mich einfach mal neben dich, guck mal,
was du so tust und ich versuche mal ein bisschen deine Arbeit zu lernen.
Also es ist ein bisschen das Leer, also das ist die Idee dahinter.
Man macht das dann meistens deutlich kürzer, aber die Idee ist eben ganz wichtig,
man kommt nicht in den Arbeitskontext hinein und sagt,
hallo Meister, wir machen das demnächst ganz anders.
Und ich sage mal, wie ungefähr das dann aussehen wird,
sondern man geht erstmal hin und lässt sich beibringen,
Das, was da an Wissen vorhanden ist.
Das heißt, man sieht, was wichtig ist,
man entdeckt ganz viele Details und man findet eben auch dadurch,
dass man dann längere Zeit in diesem Arbeitskontext sich befindet,
findet man auch, was wiederholt sich eigentlich immer wieder und ist vielleicht redundant und man findet auch raus, wir hängen die Dinge zusammen.
Also wir sind die Strukturen eigentlich aufgebaut, mit denen da gearbeitet wird.
Und dann gibt es vier Prinzipien, die da wichtig sind. Das eine ist,
dass man eben sagt, man möchte wirklich im Arbeitskontext sein,
also es hilft nichts, wenn man einen Anwender hat,
der halt in einem Wir lebten einen Callcenter arbeitet,
zu sagen, der ist mir viel zu laut,
wir machen das am besten in meinem Büro,
der kann ja zu mir kommen,
dann können wir da ein bisschen telefonieren,
sondern muss man wirklich hingehen und gucken,
wie ist das da, wo der Anwender arbeitet.
Es geht um Partnerschaft, das heißt, das ist ein gemeinsamer Lernprozess.
Es ist ja so, dass jemand, der täglich irgendwas tut,
nicht so häufig darüber nachdenkt, wie macht er das eigentlich?
Das heißt, wenn man da hingeht und sich erzählen lässt,
was er da eigentlich macht, dann lernen beide dabei.
Also es geht um partnerschaftliches Lernen und es geht dann um Interpretation,
um Interpretieren, weil das passiert auf jeden Fall.
Also es ist so, dass man sich immer mitnimmt,
Was hat man da eigentlich jetzt gerade geglaubt, gelernt zu haben?
Dass man das dann irgendwie aufschreibt,
aber dass das eben nicht fertig sein kann an der Stelle,
sondern dass man das nochmal wieder in den Kontext bringen muss
und dass man sich sagen lassen muss, ja,
das könnte schon stimmen oder eben auch nicht.
Das ist falsch, das ist anders.
Also die Überprüfung ist wichtig. Und es ist wichtig,
dass man nicht alles schaffen kann.
Deswegen sollte man sich auf bestimmte Teile konzentrieren.
Das ist jetzt schon mal ziemlich anders als jede softwaretechnische Methode
wahrscheinlich.
Die kommt aus der Ethnografie
Es ist so ähnlich wie Diätnologie, also ethnografische Methoden sind im Prinzip Methoden,
die nicht wirklich wie eine Ethnologie, da überlegt man sich,
warum denke ich jetzt gerade, was, ich denke über die Angeborenen,
also da geht es auch sehr stark um Selbstreflexion,
das passiert hier nicht, es ist nicht ganz so kompliziert,
sondern es geht einfach darum,
dass man in eine fremde Welt geht, erlebt,
was da gemacht wird und das irgendwie gut mit nach Hause nimmt,
um dann fehlt da für diese Welt was zu schaffen.
Was man dann tut, ist, man macht jede Menge Modelle,
also man macht zum Beispiel ein Austauschmodell,
da ist es so, dass es verschiedene Rollen gibt,
also es gibt ja immer viele Leute,
die miteinander zu tun haben und es dann Dinge gibt,
die diese Menschen austauschen.
Die telefonieren miteinander, die geben sich Dokumente,
die tauschen Notizen, E-Mails, was auch immer aus.
Und alles, was jetzt wichtig ist für einen bestimmten Kontext
, modelliert man hier. Das heißt,
man malt die ganzen Anwender auf und dann malt man Pfeile,
wo etwas ausgetauscht wird und an die Pfeile malt man Kästchen,
was ausgetauscht wird. Was man dann auch macht,
ist für Dinge, die einem wichtig erscheinen,
schreibt man auf, in welcher Reihenfolge sind sie passiert.
Also wie passiert zum Beispiel ein Anruf bei einem Kunden?
Also wenn da zwischendurch was hier geguckt wird und dann das Star geguckt wird,
dann habe ich eine Sequenz von Dingen,
die nacheinander geschehen sind und die kann ich auch aufschreiben.
Dann kann ich das, was ich da so an,
ja, Waffen der Eingeborenen finde, könnte man sagen,
kann ich eben auch aufschreiben bzw. dokumentieren.
Ich kann sagen, was haben die für Arbeitsmittel,
die sie jetzt benutzen? Und ich kann auch versuchen zu dokumentieren,
warum bestimmte Dinge auf eine bestimmte Art und Weise gemacht werden.
Das nennt sich dann Kulturmodell. Also es gibt dann verschiedene Gruppen,
also zum Beispiel die Entwickler sind das hier, das Marketing,
die Mitbewerber, Und die haben alle Einfluss aufeinander,
weil sie bestimmte Überzeugungen haben und diese Überzeugungen, andere Gruppen beeinflussen.
Und deshalb könnte man sagen, ist es vielleicht auch wichtig,
das hat jetzt gar nichts mehr direkt mit der Arbeit zu tun,
aber es hat mit der Art zu tun, wie die Arbeit ausgeführt wird,
dass man sich eben auch da ein Bild von macht.
Und dann kann man sich sogar noch ein Bild davon machen,
wie sieht eigentlich der Arbeitsplatz physikalisch aus?
Also wie ist das Ganze angeordnet, damit man sich das hinterher vorstellen kann? Was dann passiert ist,
das hat jetzt nicht nur einer gemacht,
sondern das haben eben viele Leute gemacht,
die sind unterschiedliche vor einem Urwald gegangen,
haben da unterschiedliche Arbeitsweisen und Herstellungsformen von irgendwelchen Waffen herausgefunden und kommen jetzt zusammen und erzählen sich,
was sie da gesehen haben und stellen fest, die Sachen unterscheiden sich.
Und das ist eigentlich immer so. Also wenn man sich
nur einen Anwender anschaut, wird man nie herausfinden,
wie arbeitet eigentlich eine bestimmte Abteilung oder wie arbeitet eine Organisation,
um das herauszufinden, muss man immer unterschiedliche Menschen gleichzeitig sich anschauen.
Weil jeder seine Eigenheiten irgendwie herausarbeitet und es mal bessere,
mal schlechtere Lösungen eben auch gibt,
um bestimmte Probleme zu begegnen
Das heißt, ich versuche jetzt, die Erfahrungen zusammenzutragen und zu konsolidieren.
Und das kann ich für alle diese Diagramme machen, wenn ich möchte.
Also ich kann immer meine gezeichneten Diagramme nehmen, nebeneinander legen,
schauen, was sind die Gemeinsamkeiten, was sind die Unterschiede.
Wie scheint es wohl möglich zu sein? Das kann ich für diese,
ich kann das sogar für Artefaktmodelle, könnte man sagen, machen.
Was ich dann in einem nächsten Schritt tun kann, ist,
ich habe jetzt diese verschiedenen Modelle, die konsolidiert sind.
Das heißt, die sind überprüft worden mit den Einzelnen
und dann sind sie zusammengeführt worden.
Und insofern sind sie jetzt eigentlich eine ganz gute Beschreibung
davon,
wie arbeiten
Die Menschen jetzt und darauf auf dieser Basis kann ich eben jetzt anfangen,
jetzt überlegen, was kann man daran ändern,
um die Arbeit besser zu gestalten.
Und das ist erstmal komplett wertneutral. Das ist eben
die Frage, was für einen Auftrag habe ich?
Soll ich versuchen, die Arbeit so besser zu gestalten,
dass sich alle Leute besser fühlen und nicht mehr vorm Dach springen?
Oder soll ich die Arbeit effizienter gestalten, damit die Firma insgesamt mehr Geld verdient?
Das ist dann eben abhängig von demjenigen, der einen bezahlt wahrscheinlich.
Aber was man dann eben tun kann, ist,
man kann sich überlegen, zum Beispiel bei diesem Austauschdiagramm,
was ist da umständlich, was kann man da vielleicht verbessern
Wie sollte das Ganze aussehen? Was man dann sich oder
was daraus dann resultiert ist eben, dass man sich überlegt,
wie kann eigentlich die Lösung aussehen?
Da kann man dann zum Beispiel auch jetzt, was bisher
noch nicht eingezeichnet war, da kann man dann eben Systemteile aufzeichnen.
Kann man sagen, bestimmte Aufgaben, die bisher von der
Abteilung ausgeführt wurden, da aber eigentlich nicht hingehören.
Die kann jetzt eben auch System eins oder zwei besser ohne Anwender vielleicht durchführen.
Oder ist es so, dass ich eben bestimmte Aufgaben,
die besonders arbeitsaufwendig oder zeitaufwendig oder kostspielig waren,
dass ich die eben jetzt gezielt verbessern möchte?
Da kann ich also genau raussuchen,
wo in diesem Arbeitsprozess möchte ich
eine Unterstützung machen
Und eben auch wie. Und um das dann besser vorstellbar
zu machen, in dieser Methode ist es dann so,
dass ich dann so eine Art Comic zeichne.
Das heißt, hier habe ich dann wieder,
das ist eigentlich so ähnlich, wie eben das Sequenzdiagramm,
das ich jetzt Schritte habe, die nacheinander abfolgen.
Bloß, dass ich eben die Schritte male,
damit ich mehr reinbekomme. Also da steht dann nicht nur,
ich drücke jetzt auf den Helpknopf, sondern ich sehe eben auch gleich,
was passiert, wenn ich da drauf gerückt habe.
Das heißt, das ist so eine Mischung zwischen,
ich kann den Anwender mal ein bisschen zeichnen,
ich kann das machen, zeichnen, was er macht,
was nicht mit der Software zu tun hat,
aber ich kann auch die Software, wie sie in dem Moment aussieht,
zeichnen.
Und das ist dann so ein bisschen der Versuch,
eine Vorgabe des Ganzen
zu machen
Und dann habe ich zum Schluss noch einen Überblick über die verschiedenen Fälle,
die ich insgesamt modelliert habe, wo ich gesagt habe,
die könnte man verbessern und kann da dann eben aussuchen,
welche von diesen hängen wie zusammen.
Und wenn ich jetzt Software umsetze, die eben die Arbeit neu gestalten soll,
welche Teile der Arbeit soll sie neu gestalten.
Und was dann in dieser Methode passiert ist,
ich nehme das Ganze, verpacke es schön,
stecke es in deinen Umschlag und übergebe es der Entwicklungsabteilung.
Das liegt so ein bisschen daran,
dass es eben eine Beratungsfirma ist,
die die Methode entwickelt hat und die Beratungsfirma ist dann eigentlich
nicht fertig an der Stelle,
die können
keine Software entwickeln
Ganz andere Methode und da nur ein Beispiel zu,
ist das Szenario-Based-Design. Da ist es so, dass ich eigentlich
so ähnliche Sachen mache wie eben meine Kontext zu Design.
Also ich versuche auch irgendwie rauszukriegen,
was machen Menschen jetzt mit den Problemen, die sie haben.
Und dann schreibe ich einen Text, in dem ich das beschreibe.
Und dann überlege ich mir, wie könnten sie das denn anders machen?
Und dann schreibe ich einen Text, nehme ich das beschreibe.
Dann überlege ich mir, Dieses, was ich mir überlegt habe,
wie sie das anders machen könnten, wie würde das denn funktionieren,
wenn ich da jetzt ein Computersystem bei hätte und was würden die Menschen davon machen und was würde die Computer dabei machen?
Dann schreibe ich einen Text, indem ich das beschreibe.
Also was ich immer wieder tue,
ist, ich schreibe eigentlich ein Szenario,
was man jetzt hier nicht lesen kann, aber ich glaube,
auf dem Ausdruck der Folie durchaus noch zu lesen ist.
Und der Hintergrund des Ganzen ist,
dass man glaubt oder glauben kann und zu einem gewissen Grad ist das auch richtig,
dass wenn ich einen Text schreibe,
dass den dann der Anwender auch verstehen kann,
dass er mir dann sagen kann,
was daran falsch ist
Also das ist ein grundsätzliches Problem von Softwareentwicklung, könnte man sagen.
Die Art und Weise in der Software entwickelt wird,
und das ist im extremen Fall der programmierte Code,
ist eigentlich nicht verständlich für denjenigen, der hinterher das Programm verwenden soll.
Und ich versuche eben möglichst verständliche Repräsentationsformen zu finden davon,
wie das System einmal aussehen soll, um das diskutieren zu können,
damit ich eben eine gewisse Art von Gemeinsamkeit bei der Entwicklung habe.
Also es ist nicht wie bei den Participatory Design,
der Gedanke dabei, ich lasse mir den Text schreiben vom Anwender,
das wäre auch eine Möglichkeit, Aber es geht eben darum,
dass man auf gleicher Augenhöhe eigentlich einen Austausch schafft.
Soweit zu den Design-Methoden. Die Evaluation,
auch nochmals bei Motivationssprüche dazu. Das eine ist,
Feedback ist die Breakfast of the Champions und am Testing
ist... Dinner of the Gods, eigentlich relativ sinnfrei.
So einfach nur heißen,
testen ist relativ wichtig dabei
Durchtesten von Software kann man herausfinden, was daran nicht funktioniert.
Das gilt genauso für technische Aspekte, wie eben auch für
die Qualität Gebrauchstauglichkeit. Und man könnte auch sagen,
angefangen hat eigentlich Software-Ergonomie in der Praxis mit zu dem Testen.
Also man hat irgendwas gebaut, hat das jemandem gegeben,
der mal gucken sollte, ob das auch in Ordnung ist,
bevor man ist, released hat.
Und dann hat man vielleicht noch drei, vier,
fünf,
20 Fehler gefunden
Und dann schnell noch so viele wie möglich davon behoben.
Und es ist durchaus eben möglich, durch einen Test
die Qualität deutlich zu erhöhen, damit das aber funktioniert.
Muss es so sein, dass man dann auch noch was tun kann.
Ja, es kommt gleich noch ein bisschen in dem Ablauf
von dem Ganzen. Also die Valuation ist,
ist historisch gesehen oder die Qualitätssicherung ist historisch gesehen ein sehr wichtiger Teil von Software-Agonomie,
weil das etwas ist,
was man auch wirklich systematisch durchführen kann und was in der Praxis auch eigentlich ganz gut gemacht gemacht werden kann.
Das Problem, das Praktische, ist eben häufig,
dass man dann nicht mehr genug Zeit hat,
um die Ergebnisse, die dabei rauskommen, auch einzuarbeiten.
Deswegen, man kann auch unterschiedliche Dinge testen. Also es
ist nicht so, dass man notwendigerweise einen Prozess haben,
man muss irgendwie in das Testen ganz hinten steht.
Man kann solche Sachen testen wie Skizzen. Also man kann zum Beispiel,
wenn man aus dem Kontext to Design diese Storyboards erzeugt hat,
kann man auch sagen, Storyboards sind etwas,
was man eigentlich sehr gut testen kann.
Das wird ja auch für Filme durchaus gemacht,
dass man also Public Viewing oder Screening von Storyboards für irgendwelche Filme durchführt,
um eben rauszukriegen, welche Variante dramatischer ist oder besser beim Publikum ankommt.
Ähnlich kann man das, denke ich,
auch für Dialogdesign machen, dass man sagt,
welche von den beiden Varianten ist eigentlich besser für deine Arbeit.
Man kann das auch ein bisschen höherwertig machen, könnte man sagen.
Also man kann auch ein Mock-up machen,
ein Mock-up ist ein nicht funktionaler Prototyp,
der schon mal so ähnlich aussieht wie das spätere Programm,
aber hinterher weggeworfen werden kann.
Das heißt, ich kann ihn zum Beispiel in Photoshop oder PowerPoint
malen. Es gibt auch extra Programme inzwischen dafür,
wo ich sagen kann, ich male mal schnell meine Webseite hier.
Und dann gucken wir mal, ob das so aussehen soll später auch.
Und hinterher programmiere ich die dann nochmal komplett.
Das ist so die praktische Variante. Ich könnte auch sagen,
ich kann eine formale Spezifikation oder ein formales Modell, kann ich auch durchaus evaluieren.
Was ich auch evaluieren kann, ist dann ein Prototyp,
das wäre das nächste Richtung Software. Das heißt,
ich kann so arbeiten, dass ich eine noch nicht vollständige Software habe,
nicht erst zwei Wochen vor Release-Termin meinen ersten Test mache,
sondern schon vier Wochen nach Entwicklungsbeginn,
wenn ich das allererste Feature fertig habe.
Und ich kann natürlich eben auch lauffähige Versionen testen
Ja. Beim Testen wichtig, das ist in diesem Diagramm so ein bisschen zu sehen,
sind eigentlich, dass ich mir vorher überlege,
was sind eigentlich meine Kriterien und was sind eigentlich die Ziele des Tests.
Wenn ich das nicht mache, ist es sehr schwierig zu testen,
weil ich dann nicht weiß, worauf ich eigentlich dabei achte.
Und Kriterien kann eben sein, dass ich mir überlege,
ich möchte jetzt, ich glaube,
ein paar Sachen dazu habe ich auch noch,
aber da kann es eben so sein, dass ich eben mir überlege,
ich will bestimmte Messungen durchführen und dann eben sagen,
Qualität ist dann die Qualität, die ich haben möchte,
ist dann gegeben, wenn ich eben bestimmte Werte in diesen Messungen habe.
Ich kann mir überlegen, dass es eben Norman oder Richtlinien
gibt, die ich erfüllen möchte.
Und bei den Zielen kann ich eben genauso sagen,
wo möchte ich eigentlich liegen mit meinem Zielsystem?
Was ist das, was es erfüllen soll? Es gibt
sehr unterschiedliche Evaluationsverfahren, genauso wie es unterschiedliche Designverfahren gibt, die kann man einteilen.
Man kann sie versuchen einzuteilen in hart und weich.
Das kommt so ein bisschen aus dem Wissenschaftlichen am Anfang,
aus dem Human Fact, das harte Evaluationsmethoden, sind alle die,
die ja, sagen wir mal, richtige Daten liefern.
Die sind quantitativ, die sind repräsentativ und reproduzierbar, quantitativ heißt,
ich habe also wirklich einen Messwert, den ich als Zahl wiederkriege.
Repräsentativ heißt, ich habe nicht nur eine Person gefragt,
sondern ich habe eine so große Anzahl von Personen gefragt,
dass ich, dass die statistische Wahrscheinlichkeit,
dass ich das jetzt verallgemeinern kann,
auf meine Gesamtnutzerzahl sehr hoch ist oder umgekehrt,
die statistische Wahrscheinlichkeit sehr niedrig ist, dass ich falsche Schlüsse ziehe.
Das ist so ähnlich wie bei einer Meinungsumfrage.
Ich muss ein paar Leute fragen,
damit ich hinterher eine Vorhersage machen kann
Und sie muss reproduzierbar sein. Reproduzierbar heißt,
wenn ich einen Versuch durchführe, und das heißt in dem Moment,
dann eben auch tatsächlich einen Versuch,
dann sollte der die gleichen Ergebnisse liefern,
wenn ich hier nächste Woche oder in einem halben Jahr nochmal durchführe.
Und das ist gar nicht so einfach, so was herzustellen.
Weiche Methoden dagegen sind genau das Gegenteil.
Die sind qualitativ exemplarisch und expertisebasiert. Qualitativ heißt, nicht,
dass die jetzt besser sind, sondern qualitativ heißt einfach,
die Art der Daten, die ich wiederbekomme,
sind eben keine Zahlen, sondern es sind Umschreibungen,
könnte man sagen.
Zum Beispiel ist eben ein Interview,
das ist eine ganz
Klassische, qualitative Methode. Exemplarisch sind sie deswegen, weil das,
was ich einsammle an Daten, nicht verallgemeinbar bei ist.
Ich habe im Einzelfälle, die ich darstelle und Expertise basiert,
könnte man sagen, sind qualitative Methoden dann,
wenn ich mich auf das Wissen von Einzelnen verlasse.
Und dann gibt es noch eine dritte Kategorie, die ist
irgendwann mal eingeführt worden oder bekannt gemacht worden von Nielsen.
Das ist ein sogenannter Selbsternannter und inzwischen auch relativ anerkannter Usability Guru.
Die hat gesagt, wir brauchen Discount-Usability-Methoden
Die sind so ähnlich wie Discounter,
sind die vor allen Dingen eins, nämlich billig.
Die kosten wenig Geld. Wir sind häufig so ähnlich
wie harte Methoden, aber eben mit viel weniger Nutzern.
Das heißt, die sind dadurch nicht repräsentativ. Was man dann bekommt,
ist, man kriegt eigentlich nur schwere Fehler raus.
Nicht alle Fehler, nicht wie wichtig die Fehler untereinander sind,
sondern eben nur das, was wirklich fast jedem auffällt.
Aber dadurch, dass sie so furchtbar günstig sind,
kann ich sie eben eigentlich immer machen.
Und ich kriege das Wichtigste raus, nämlich eben diese
schweren Fehler
Ich kann Evaluationsverfahren auch so einen Teil, dass ich sage,
es gibt Objektive und Subjektive, also welche, die versuchen,
möglichst neutrale Daten zu bekommen, welche, die versuchen,
explizit eben Daten aus Sicht von jemandem zu kriegen.
Es gibt empirische und heuristische, das heißt empirisch bedeutet,
ich habe tatsächlich ein Experiment oder ich habe eine Erhebung,
die Daten kommen,
von einer größeren Menge von Quellen oder ich habe heuristische,
wo ich eben entweder mir das nur selbst angucke,
wo ich wenige Leute beobachte oder wo ich Interviews mache.
Und was ich auch tun kann, ist, ich kann
einer analytisch evaluieren. Das heißt, ich kann evaluieren,
ohne dass ich überhaupt einen Anwender darf habe.
Oder überhaupt Menschen eigentlich haben. Und das funktioniert nur dann,
wenn ich eine Theorie habe, wie diese Menschen arbeiten.
So, und dafür jetzt noch kurz ein Beispiel,
also für das Letzte als erstes. Es gibt sowas wie
Goms, also was macht man eigentlich heutzutage nicht mehr?
Ich erwähne das aber trotzdem, weil man es immer wieder noch liest.
Das heißt, Goals, Operators, Methods, Selection-Rules.
Das ist im Prinzip eine formale Spezifikation davon,
wie Menschen arbeiten
Und wie lange sie für bestimmte Dinge brauchen.
Und dann kann man eben ausrechnen für eine Oberfläche,
wie welchen Gomswert die hat und einen Gomswert verbessern.
Und hinterher kann man hoffen, dass die Oberfläche dann besser funktioniert.
So ähnlich auch, aber viel einfacher. Und deswegen eben irgendwie auch,
sagen wir mal, erfolgsversprechender Fitzlaw. Fitzlaw berechnet einfach,
wenn ich eine Maus habe oder ein Zeigeinstrument, irgendeine Art,
wie lange brauche ich, um ein Zielfeld zu treffen,
wenn es eine bestimmte Größe hat.
Wie man sich vorstellen kann, geht es schneller,
ein großes Feld zu treffen,
als ein kleines Feld
Das kann durchaus wichtig sein. Also es kann sein,
dass ich eine Anwendung habe,
wo ich 100 verschiedene Dinge anklicken muss hintereinander,
dann sollte ich mir schon überlegen oder sehr viel oder immer wieder klicken.
Soll ich mir überlegen, wie groß sollten meine Ziele sein?
Das kann ich machen, ohne dass ich das überhaupt ausprobiere.
Und Fitzlord ist eben mal so hergeführt worden, dass man Leute auf,
weiß ich nicht, Hunderttausende von Rechtecken hat klicken lassen,
die Zeit gemessen hat und dann mathematisches Modell dahinter gestärkt hat.
Deswegen brauche ich jetzt nicht mehr Leute,
auch Rechte klicken lassen, wenn ich wissen will,
wie lange werden sie
dafür wahrscheinlich brauchen
Sondern ich kann einfach die Formel verwenden, die damals gebaut wurde.
Dass aber praktisch viel relevanter ist, ist eben,
wie kann ich eigentlich ein echtes System testen und einen Gutachten,
eine Möglichkeit, einen Gutachtenmann ist, einen Experten zu fragen.
Der kann viel Wissen haben, und zwar entweder über,
oder auf der einen Seite, könnte man sagen,
über, was macht gute Software aus?
Theorien, Kriterien, Methoden. Auf der anderen Seite,
was wird der Anwender brauchen?
Das kann also auch Kontextwissen sein. Erfahrungen können. Das
ist immer noch
heuristische Evaluation
Das heißt, der entscheidet ja eigentlich selbst,
was jetzt gut oder was er schlecht findet.
Das können nur relativ wenige Grundregeln sein und es ist häufig eine Konsistenzprüfung.
Das heißt, man kann da drin sehr gut rausfinden,
wenn man jetzt so eine Software gebaut hat,
mit der einem Expertens und Gutachten gibt,
was ist da dran inkonsistent, was darin gebaut wurde.
Also sind Sachen völlig unterschiedlich in Bereichen und das ist
die Verwendung unterschiedlich, haben verschiedene Teams nicht vernünftig zusammengearbeitet.
Ganz häufig ist es auch so, dass wenn man über die Zeitsoftware baut,
dass man da Verletzungen macht, wenn man feststellt,
eigentlich wäre eine andere Saat und Weise das zu lösen, doch besser.
Also da kann schon viel an Ergebnissen bei rauskommen,
was der auch machen kann, ist, er kann sich
Man muss ja dann vielleicht jemanden vorher fragen,
was machen die Anwender denn so? Er kann sich überlegen,
was würde ich denn tun, wenn ich ein Anwender wäre?
Das nennt sich dann Cognitive Walks und dann eben sagen, was sind die Fehler?
Und was man da rausbekommt aus so einem Expertengutachten,
und das ist das, weswegen das relativ beliebt ist,
die Leute, die das machen, sind ja Experten,
sind vor allen Dingen eben auch Experten dafür,
solche Berichte zu schreiben.
Das heißt, die können sehr schön sagen,
die und die und die und die Dinge habe ich gefunden,
die sind so und so wichtig und so und so kann man sie beheben.
Das heißt, was man rauskriegt,
ist ein gewichteter Katalog von Maßnahmen und dann kann man
einige davon umsetzen
Was es auch gibt, sind Usability-Tests. Das heißt,
man nimmt tatsächlich Anwender, setzt sie vor das,
was man gebaut hat und guckt, wie gut kommen sie damit zurecht.
Das Problem dabei ist häufig, dass man sich sehr viel
Gedanken darüber machen muss, was eigentlich die Aufgaben sind,
die die Anwender in diesen Tests durchführen sollen.
Weil die realistisch sein müssen, wenn sie das nicht sind,
dann hat man sehr stark verfälschte Testergebnisse.
Was man dann testet, ist eben häufig,
wie schnell sind sie,
haben sie
es geschafft
Wie lange haben Sie Geld gebraucht, um bestimmte Dinge zu erwähnen?
Haben Sie dabei Sachen gelernt? Während Sie den Test gemacht haben,
wie viele Fehler haben Sie gemacht? Und man kann auch
sagen, bestimmte Dinge sind uns vielleicht besonders wichtig.
Also dieses Icon hier, was wir neu gemalt haben,
erkennt das überhaupt jemand? Sowas kriegt man im Musability-Test eigentlich
sehr gut raus. Was man auch machen kann,
ist, man kann Belastungsmessungen machen,
also man kann im Prinzip so einen Usability-Test machen,
den Leuten Elektroden an die Stirn kleben und gucken,
wie viel Stress wird erzeugt und fangen Sie an zu schwitzen.
Wie ist Ihr Fulsfrequenz, wie ist der Blutdruck?
Dadurch kriegt man zusätzliche Ergebnisse, aber es ist
nicht immer ganz einfach rauszukriegen,
was die bedeuten
Stress, ja, sehr unterschiedliche Ursachen haben kann und
höherer Blutdruck, genauso, glaube ich.
Wie man Usability-Tests durchführt, das ist häufig immer noch sehr klassisch.
Das ist auch ein Bild aus den 70ern.
Also man hat, wie beim Polizeiverhör, einen Raum,
in dem findet das statt mit dem Verhör.
Also der Anwender benutzt die Software und den anderen Raum,
da sitzen diejenigen, die sich das angucken sollen und schauen durch so ein Spiegelglasscheibe durch.
Der Anwender kann das überhaupt nicht erkennen. Das hört sich erstmal
ein bisschen albern an. Was da dran aber wirklich toll ist und was also gut funktioniert ist,
wenn man Softwareentwickler, die partout nicht glauben,
dass das, was sie gebaut haben,
vielleicht nicht so toll ist,
weil sie es ja schon seit 20 Jahren
so machen
Und selbst auch sehr gut verwenden können,
wenn man die eben mitnimmt zu so einem Test und ihnen zeigt,
was für Schwierigkeiten anwenden mit der Software haben,
die sie gebaut haben.
Also das ist ganz häufig das Wesentliche eigentlich,
was bei Usability-Tests rauskommt, dass man dadurch,
dass man das sehr gut aufnehmen auf Video oder eben auch direkt beobachten lassen kann,
dass man da eben ganz viel Aha-Erlebnisse hat.
Das ist eben so ein bisschen das Problem,
das ist eigentlich nur dadurch entstanden, könnte man sagen,
das hier,
also den Anwender und die Software
zusammen sieht ja kaum
ein Entwickler
Wir sehen eigentlich immer nur die Software. Und dann gibt
es noch heuristische Methoden. Es gibt eben die Möglichkeit,
durch Beobachtung im Feld beurteilen zu lassen,
wie gut etwas funktioniert. Das hat Vor- und Nachteile,
also man kann das ja sehr gezielt machen,
aber es ist eben auch immer wieder eine Interpretation,
die Glaubwürdigkeit dabei herzustellen, ist relativ schwierig.
Eine andere Form von heuristischen Methoden ist eigentlich verbreiteter,
nämlich das laute Denken und die Wizard of Oz Experimente.
Lautes Denken ist einfach, es gibt ja Anwendungen,
die sicherheitskritisch sind, könnte man sagen. Also zum Beispiel,
wenn man jetzt Software bauen möchte, um Flugtowerarbeit zu unterstützen.
Also Fluglotsen bei ihrer Arbeit. Und es ist relativ schwierig,
jetzt zum Hamburger Flughafen zu gehen, zu sagen,
ich habe hier eine neue Software mitgebracht,
lass uns die mal ausprobieren und zwischendurch dann zu sagen,
nu, warten wir kurz.
Also ich glaube, hier ist gerade ein Fehler aufgetaucht,
wir müssen jetzt mal drüber reden. Sondern in dem Moment ist es ja so,
dass das, was sie da tun,
eben wirklich Auswirkungen hat und man in die dem Moment,
wo man jetzt einen Test durchführt, wo man so sagt,
wir wollen jetzt mal gucken, wie gut ein neues System funktioniert.
Die Leute ja nicht bei ihrer Arbeit stören darf.
Was man dann so machen kann, ist,
man kann einfach aufzeichnen, dass was da passiert. Und hinterher,
wenn sie Feierabend haben,
kann man sich nochmal mit ihnen zusammensetzen und kann sie nochmal fragen,
was ist das eigentlich, was in dem Moment,
wo du jetzt hier den roten Kopf gekriegt hast und dann hektisch da hinten hingelaufen bist,
was ist da dir durch den Kopf gegangen?
Und was ist das, was das Problem war an der Stelle?
Also wie kann man das beheben? Dann kann man hinterher
im Nachhinein mit Hilfe dieses Videos oder der Aufzeichnung
kann man eben dann nochmal über die Erwartung, Überlegung,
Erklärung,
Vermutung und Gefühle
Man kriegt dadurch eigentlich auch ein sehr realistisches Bild. Das andere,
was man machen kann, ist, man kann sagen,
man wacht das Ganze noch komplett ohne, dass ein System tatsächlich da ist.
Und man simuliert den Rechner. Also es gibt überhaupt nicht
das System, sondern es gibt nur einen Menschen.
Das ist zum Beispiel mal gemacht worden, dass dieser Dialogschnittstellen gab,
da war das immer noch sehr einfach.
Also da hat man gesagt,
Computer berechne mir die Antwort auf die Frage nach allem und dann
hat der Computer halt eben nach sehr kurzer Zeit die Antwort zurückgeschrieben,
die hat er aber gar nicht selbst ausgerechnet,
sondern die hatte halt irgendein Mensch sich überlegt in dem Moment,
muss sie zurückgeben
Also wenn ich solche Systeme habe,
dann kann ich eben auch sehr komplexes Verhalten testen,
ohne dass ich das System selbst umgesetzt haben muss.
Was ich auch machen kann, ist,
ich kann Benutzer befragen, am liebsten per E-Mail-Fragebogen oder Web-Fragebogen.
Das ist eine sehr, sehr günstige Art und Weise.
Also im Prinzip ist das so auf jeder Shopping-Seite,
die man besucht, wird man auch ab und zu mal gefragt,
ob man denn nicht an der Bettfragen teilnehmen möchte.
Und dann kann man dann bestimmte Dinge beurteilen.
Das dient häufig dazu, ein Meinungsbild zu bekommen.
Also man kann sich bestimmte Punkte raussuchen,
die einen interessieren und dann kann man
sehr viele Leute erreichen
Häufig kriegt man eben raus, wie gut irgendwas gefunden wird.
Relativ selten kriegt man raus, warum das so ist.
Und es ist eben auch so,
dass es eine Wissenschaft für sich ist, könnte man sagen,
einen guten Fragebogen zu entwickeln, also den Bias rausgerechnet,
also die Vorurteile, die da drin stecken.
Was ich heute, glaube ich,
gerne überspringen würde oder beziehungsweise nur ganz kurz überfliegen würde,
ist, dass man das Ganze auch noch kombinieren kann.
Also es gibt unterschiedliche Ansätze,
das eine ist mal 92 entwickelt worden,
das andere ist
mal 2001 entwickelt worden
Wo man also gesagt hat,
ich muss das Ganze wirklich planmäßig machen, diese Evaluation.
Ich muss das aus bestimmten unterschiedlichen Gesichtspunkten heraus machen.
Und ich will, nee, Evaluationsmethode haben, die eigentlich alles abdeckt.
Und das sind zwei Beispiele. Der einen versucht man abzudenken,
verschiedene Kriterien. Also klar definiert, was ist das eigentlich?
Einige treffen die für Funktionalität, andere Benutzbarkeit, die Orientierung, die Beeinflussbarkeit.
Und dann eben Methoden miteinander kombiniert, eine Befragung,
eine Arbeitsanalyse und ein Expertenurteil. Das andere ist das,
was vielleicht noch aufwendiger, aber jetzt auch interessanter dabei ist.
Das ist, es gibt eine internationale Norm,
die ISO 92, 41, die Teile 10 und 11 davon.
Das ist auch so was ähnliches wie die Bildschirmarbeitsverordnung,
die ist tatsächlich entstanden aus der deutschen Industrienorm, der entsprechenden.
Und da steht drin, was gebrauchstaugliche Software ausmacht.
Also ich meine, du brauchst taugliche Software bauen möchte,
muss man nur da nachlesen und sagen,
die Qualitäten muss eben meine Software haben.
Es ist bloß wahnsinnig schwer, nachzuprüfen, was da drin steht.
Da steht dann sowas drin wie Software sollte Aufgaben
angemessen sein
Weil es eben so schwer nachzuprüfen ist, haben sie
bei der GMD mal einen Falsifikationsansatz entwickelt. Das bedeutet,
eine Methode, die, wenn man sie durchführt, einem erlaubt,
zu sagen, Software X ist nicht 92, 41 konform.
Das heißt, man kann nicht sagen, dass etwas tatsächlich gebrauchstauglich ist.
Irgendwann kann eine sehr klare Aussage darüber treffen, wann etwas nicht gebrauchstauglich ist.
Und was da eben gemacht wird, ist auch,
kombiniert einen Fragebogen, man kombiniert eine Aufgabenanalyse Mittelszenarios,
Und man kombiniert die Tätigkeit von Experten.
Die gehen in den Kontext, nehmen teilnehmend, beobachten,
teilnehmend, fragen Benutzer, inspizieren,
was da vorhanden ist und analysieren die Dokumente.
Und hinterher kommt dann raus, da ist eine Normabweichung vorhanden.
Was ist dann so als letzten Evaluationsansatz noch gibt,
den ich vorstellen möchte, hier,
das Ganze nennt sich attraktiv, das ist mal aus einer Dissertation von
Im Psychologen entstanden, könnte man sagen. Und der hat
sich darauf konzentriert, dass es ja auch hedonische Produktmerkmale gibt.
Das heißt im Prinzip, das,
was ich ganz am Anfang mal besprochen hatte,
ist es irgendwie auch wichtig, wie viel Spaß eine Software bringt.
Also das Quadrat, was jetzt hier zu sehen ist,
das kann man, glaube ich, nicht ganz erkennen,
ich muss mal ein bisschen größer.
So, vielleicht hilft das.
Das hilft nicht
Etwas kann, man kann es nicht wirklich erkennen.
Also ich zumindest nicht. Etwas kannten links unten überflüssig sein,
in der Mitte neutral, recht oben begehrt.
Und nach links oben selbstorientiert, zu selbstorientiert,
nach rechts unten, handlungsorientiert, zu handlungsorientiert sein.
Das, was nach rechts geht, ist die pragmatische Qualität.
Pragmatische Qualität ist das, was wir bisher eigentlich hatten.
Das Ding tut tatsächlich was. Das lacht oben, ist die hedonische Qualität.
Das ist angenehm. Und die sind voneinander abhängig. Also es gibt Untersuchungen,
auf die gründet der seine ganze Arbeit von Oberflächen für Geldautomaten,
die in Deutschland und in Japan gemacht wurden.
Und man könnte sich jetzt ja überlegen,
die Oberfläche für den Geldautomaten ist wahrscheinlich so mit das Einfachste, was man überhaupt bauen kann.
Aber das ist auch gar nicht so einfach. Es gab,
ich weiß nicht, ob das noch bekannt ist vor,
es muss jetzt, glaube ich,
vier Jahre her sein oder drei Jahre her,
gab es eine große Änderung bei der Bedienung von Geldautomaten.
Also früher war es so, dass man als allererstes Eingegebenheit,
wie viel Geld man haben möchte, Und da hat man gesagt, ja bitte,
dann musste man in einer gewissen Zeit irgendwann seine Geheimnummer eingeben.
Und dann hat einem der Automat gesagt, tut mir leid,
ist nicht mehr genug Geld auf dem Konto oder die Geheimnummer war falsch und man kann wieder weggehen.
Und insgesamt hat es auch sehr lange gedauert.
Und das Ganze ist wesentlich effizienter geworden und in gewisser Weise auch europäisch angepasster,
dadurch, dass man jetzt als erstes nach der geheimen Nummer gefragt wird und im Hintergrund das System schon mal guckt,
hat er denn auch genug Geld und war die geheime Nummer dann richtig,
bevor man dann überhaupt gefragt wird,
wie viel Geld man denn haben möchte.
Das heißt, Da ist, also sagen wir mal,
sehr viel Benutzerfrustration vorweggenommen worden. Und man hat also
eine Oberfläche für Geldautomaten in Japan und hier getestet.
Und diese sehr pragmatische Oberfläche ist hier halt sehr gut angekommen
und in Japan ganz schlecht. Und umgekehrt war es aber auch so,
dass wenn man sich japanische Geldautomaten anguckt, das sind also Blumen,
die aufgehen, das sind Lampen, die leuchten.
Das sind Töne, die gespielt werden. Das kommt hier
total schlecht an. Also wenn man zur Bank geht,
möchte man nicht irgendwelche Blumen sehen
Das ist aber einfach eine kulturell deutlich unterschiedliche Erwartungshaltung.
Und es ist eben auch so ein bisschen das,
was da als schön empfunden würde. Und es ist so,
dass man nachmessen kann, das, was,
also so ein japanisches Bankprogramm gebraucht hat, um einem Geld auszuzahlen,
waren irgendwie, sagen wir mal, zweieinhalb Minuten.
Das Deutsche schafft es in 50 Sekunden. Trotzdem war es so,
dass wenn man ihr Mann dann gefragt hat,
welches Programm ist denn schneller, dass sie gesagt haben,
ja, das Japanische hat ja auch viel mehr geschafft in der Zeit.
Und auch, also das ist ein Prinzip, das kann man
komplett verallgemeinern. Software, die als schön empfunden wird,
wird gleichzeitig auch immer als gut empfunden.
Sie kann noch so schlecht sein
Objektiv betrachtet. Und deswegen ist es eben auch wichtig,
diese hier nicht lesbare, hedonische Qualität zu messen.
Das heißt also, welchen Schönheitswert, welche Stimulation hat eigentlich,
oder welche Attraktivität hat eigentlich jetzt eine Software außerhalb von ihren reinen pragmatischen Qualitäten.
Und da hat er es jetzt nochmal unterteilt,
in eben Stimulation, das hat er dann bezeichnet als Menschen,
haben das Bedürfnis, sich weiterzuentwickeln, die Dimension bildet ab,
inwieweit ein Produkt diese Entwicklung unterstützen kann,
indem es neuartige, interessante und anregende Funktionalitäten, Inhalte,
Interaktions- und Präsentationsstile bietet.
Es gibt die Identität. Sie beschreibt inwieweit ein Produkt
seinem Nutzer ermöglicht, sich mit dem Produkt zu identifizieren.
Ich habe zum Beispiel heute diesen Adapter beinahe nicht bekommen,
weil die ganze Zeit die Telefon-Hotline vom Apple-Händler besetzt ist,
weil die Leute ein iPhone kaufen möchten.
Und es gibt die Attraktivität. Sie beschreibt eine globale Bewertung
des Produktes auf Basis der wahrgenommenen Qualität. Und das sind alles Dinge,
die kann man auch als Qualitäten von Software befassen.
Und dann hat man eben Aber mal noch ein deutlich breiteres Spektrum,
als diese eine Gebrauchsqualität, die schon mal vorgekommen ist.
Was ich jetzt gern noch mal zum Schluss fragen würde und vielleicht,
wo wir jetzt noch ein wenig privaterer Kreis geworden sind,
gibt es jetzt noch ein, zwei mehr Antworten.
Es gibt ja diese Worte, Design- und Qualitätssicherung,
die gibt es auch in der Softwaretechnik.
Also es gibt ja sowohl Design als auch Qualitätssicherung,
zum Beispiel in agilen Methoden, könnte man sagen,
wenn ich sowas mache
Dann habe ich da auch Design als Softwareentwickler. Dann habe ich
da auch Qualitätssicherung. Aber wie unterscheidet sich das eigentlich?
Also das, was ich jetzt hier vorgestellt habe,
als Design und als Qualitätssicherung von dem,
was man da macht, ist das das Gleiche?
Oder sind die Worte ganz unterschiedlich von der Bedeutung her?
Je nachdem,
wo ich sie verwende
Es wird alles auf Video aufgezeichnet. Das ist wahrscheinlich schädlich
dafür. Oder es ist Freitag oder ich stelle unverständliche Fragen
. Ich weiß es nicht genau, aber Design,
also wenn ich Design mir angucke im Zusammenhang mit Software,
was designe ich denn da
Nö, nö, das ist schon,
also bei Autos würde ich aber fast ja sagen,
ist die Situation noch deutlich besser als bei Software.
Also wenn ich Auto baue, ein Auto baue,
dann ist ja der Teil, den man tatsächlich designen,
also den man beim Autodesign nennt,
der hat ja schon ganz viele eigentlich mit dieser hedorischen,
gefühlsmäßigen Qualität zu tun.
Auto ist ja auch Technik,
aber eben gar nicht so viel Technik,
wenn man sehr versteckt und das,
was man tatsächlich designt und was entworfen wird beim Auto,
hat ja auch
ganz viel mit der Oberfläche
zu tun
Aber wenn ich mir überlege, was ist das,
was ich mache, wenn ich Design mache, in der Softwareentwicklung,
dann hat das doch ganz viel häufig zu tun.
Also ich muss ja nun mal objektorientiert davor setzen,
weil ich häufig objektorientiert Software entwickle.
Also wenn ich objektorientiertes Design mir angucke,
was ist das
Ne, wir seien in Softwareentwicklung,
also ich lasse mir da auch gerne widersprechen,
heißt häufig, dass ich mir Gedanken darüber mache,
wie sieht meine Software eigentlich aus.
Und das wiederum heißt häufig nicht, ist sie grün oder
ist sie blau, sondern was für Klassen habe ich.
Und ne, ne, wir reden jetzt darüber,
was bedeutet Design? Auf der einen Seite für die Softwaretechnik
? Was bedeutet Design auf der anderen Seite für die Softwareergonomie
Und ich habe dasselbe Wort, Design.
Und es heißt aber eben sehr unterschiedliche Dinge.
Auf der einen Seite kann es eben damit zu tun haben,
wenn ich mir nur die Software angucke,
ist sie blau oder grün, ist sie mit großer oder kleiner Schrift.
Wie sieht sie aus? Ich kann mir aber auch
designen überlegen, was eben die ganze Arbeitsgestaltung einbezieht.
Ich kann mir auch ein Design überlegen, was nur die Interaktion betrifft.
Oder ich kann sagen, ich habe ja schon das Wort
Design und Design heißt ja eigentlich nur, dass ich softwaretechnisches Modell.
Ich gehe gleich wieder ins Bild, dass ich ein softwaretechnisches Modell baue.
Und also so wie ich klassisch softwaretechnisch diese einen gelernt habe,
ist es ja so, dass ich bei der Software eigentlich nur darauf achten muss,
dass die wichtigen Dinge, die im Anwendungskontext vorkommen,
dass ich die als Klassen einmal darstellen muss,
in eine Hirchie bringen muss und dann müssen die noch
ein Verhalten bekommen und hinterher habe ich Software,
die in ihre Arbeitsweise sehr stark die Arbeitsweise im Anwendungskontext widerspiegele
Und das, worauf ich jetzt nochmal hinaus möchte,
das kann so sein, dass dem tatsächlich so ist.
Also für mich ist es immer noch zum Teil
noch nicht komplett bewiesene Annahme. Aber das hat eigentlich nichts
damit zu tun, worüber ich heute geredet habe erstmal.
Das ist ja das, wie die Software im Inneren zusammenhängt.
Und es hilft einem dabei, Fehler zu finden.
Also es macht die Software verständlicher. Es macht es verständlicher,
darüber zu reden, was in der Software an Funktionalität
vielleicht nicht richtig verordnet ist oder noch nicht richtig funktioniert.
Aber es hilft einem nicht unbedingt,
das Ganze gegenüber einem Anwender darzustellen
Und es kann dazu führen, dass man dann eben Systeme baut,
die, wenn sie das, was sie als Klassen und Objekte haben,
direkt dem Anwender zeigen, die dem gar nicht verständlich sind.
Es kann auch sein, dass das so ist,
dass er das versteht, aber das ist das,
wenn man ganz früher, und ich hatte angefangen mit Zerox Park,
ich werde es auch ein bisschen aufhören mit Zerox Park,
wie man ganz früher eben gesagt hat,
wie man eigentlich Software schreiben sollte,
man moduliert Software so,
dass sie objektorientiert den Anwendungsbereich widerspiegelt und dann gibt man dem Anwender im Prinzip ein komplettes objektorientiertes Programmiersystem.
Smalltalk war das damals
In die Hand und dann kann er damit arbeiten,
weil das kann ja eigentlich alles. Was man hier eben hat,
ist, man hat sehr unterschiedliche Arten von Indirektionen noch dazwischen.
Also man hat extra Disziplin und Interaktionsdesign ist nur eine,
es gibt auch noch Informationsdesign oder Informationsarchitektur und es gibt eben das User-Experience-Design,
die versuchen eigentlich nochmal, sagen wir mal,
noch eine Schicht dazwischen zu legen.
Also sagen so und so arbeitet vielleicht die Software,
aber wir wollen, dass das,
was jetzt sichtbar wird, nochmal anders aussieht.
Das ist nochmal
eine Abstraktionsschicht obendrauf
Bei der Qualitätssicherung würde ich auch sagen, dass es da
nochmal Unterschiede gibt. Es ist nämlich zum einen so,
dass es schwieriger ist im Zusammenhang mit Menschen, Qualität zu sichern.
Also ich habe jetzt ja sehr viele Evaluationsmethoden aufgeführt und ihnen gemein war,
dass sie entweder nicht exakt und reproduzierbar sind oder dass sie teuer sind,
weil sie eben sehr aufwendig sind.
Und es gibt eigentlich keine zufriedenstellende automatisierte Qualitätssicherung. Es ist ja
was, wo man in der technischen Qualitätssicherung hin möchte.
Eigentlich jede Art von Tests, die ich in der Softwaretechnik
durchführen möchte, möchte ich eigentlich automatisieren können.
Ich will Unit-Tests automatisieren können, Integrationstests, möchte ich nach Möglichkeit automatisieren können.
Last-Tests möchte ich automatisieren können. Das geht bei Tests mit
Anwendern selten, weil die Anwender ja nicht automatisierbar sind.
Also ich kann zu einem begessenen Maße,
kann ich sagen, ich automatisiere den ganzen restlichen Teil.
Das Ganze nennt sich dann Remote-Usability-Testing. Also ich lasse Sibility-Tests,
die mache ich in einer kontrollierten Umgebung und gebe die Aufgaben per Text
vor und messe auch hinterher, ob die geklappt haben oder nicht.
Als Anwender suche ich mir dann Leute irgendwie in Indien raus,
weil die günstiger sind und ich denen nicht so viel Geld zahlen muss.
Deswegen hast du es dann eben remote.
Also die können von da aus dann ihre Usability-Tests machen,
aber ich muss sie immer wieder aufs Neue durchführen.
Also ich habe nicht einfach diese Regressionstestmöglichkeit,
die ich in der Softwaretechnik habe.
Testen ist eigentlich was anderes, könnte man dann auch sagen.
Es ist ein
viel manuellerer Vorgang
Und das ist eben auch ein Grund, und das ist so ein bisschen die Folie,
die ich jetzt hier noch habe, es ist relativ schwer, das Ganze zusammenzubringen.
Also Software-Engineering auf der einen Seite und Usability-Engineering auf der anderen Seite,
also obwohl Usability-Engineering genauso versucht, eine Ingenieursdisziplin zu sein und versucht,
ein Vorgehen zu definieren, dem man Schritt für Schritt folgen kann,
ist es eben so, dass bestimmte Schritte aufwendig sind,
also wenn man sich in dieses Kontext, Schulddesign zurückerinnert,
mal für eine Woche sich anzuschauen, wie Anwender in einem bestimmten Kontext arbeiten.
Das ist sehr aufwendig. Oder auch das, was ich jetzt hier mit dem Qualitätssicher,
mit dem Testen aufgeführt hatte, das sind ja auch häufig eben sehr aufwendige Tätigkeiten. Das heißt,
gerade wenn ich jetzt in die Richtung der agilen Softwareentwicklung gehen möchte,
was ja so modern ist für zurzeit und eigentlich auch sehr gut ist,
weil man ja, sagen wir mal,
auch viel testet, also eine Idee,
die der agilen Softwareentwicklung zugrunde liegt, ist ja,
dass ich versuche, weil das so schwer ist,
nach möglichst das Ganze nicht einmal zu machen,
sondern immer wieder und eben in Ininkrementen meine Software zusammenbaue und dann jedes Inkrement für sich schon mal Qualität sichern kann,
auch im Hinblick auf Gebrauchstauglichkeit.
Das Problem, was ich eben trotzdem habe, ist,
dass ich im Prinzip,
damit ich ein Design im Verständnis von Usability erstellen kann,
dass ich da ein komplettes und ein relativ komplettes Wissen über den Anwendungskontext haben muss.
Dass ich genauso für eine Qualitätssicherung eigentlich immer relativ komplettes
Wissen über das Produkt
haben muss
Andererseits, aber eben diese aufwändigen Schritte nicht immer wieder durchführen kann.
So. Was ich natürlich trotzdem sagen würde,
ist, dass es in jedem Fall wichtig ist,
sich damit zu beschäftigen mit dem Thema und auch mit den verschiedenen Teilen dieses Themas.
Und es ist auch keinesfalls hoffnungslos. Also man kann auch ganz viel machen,
indem man eben nicht, sagen wir mal,
den Anspruch an dieses wissenschaftliche, perfekte und vollständige aufgibt.
Also jedes bisschen hilft, könnte man auch sagen.
Ich habe jetzt nur zwei sozusagen Listen von Dingen,
wo man noch mal weitergucken kann. Das eine sind Bücher,
die sind auch in den Folien noch drin. Das andere sind Links,
die sind, glaube ich, in den Folienkopien noch nicht drin,
weil ich mir die heute erst rausgesucht hatte.
Da habe ich als allererstes die deutsche Usability-Konferenz aufgeführt,
also wer sich für das Thema interessiert im September diesen Jahres,
ist die in der schönen Stadt Duisburg.
Und für Studenten auch sehr erschwinglich. Und dann gibt es
da links, da muss ich noch hier den richtigen Knopf
Dann gibt es eine Webseite von der Interaction Design Association, die heißt X-Star.
Die ist relativ interessant und unterhaltsam, könnte man sagen.
Was man als Student häufig gar nicht so zu schätzen weiß,
was aber ein ganz großer Vorteil in der Informatik in Hamburg ist,
ist, dass man einen Zugriff auf die Digital Library der AC hemmt.
Ich weiß nicht, wer sich da schon mal umgeschaut hat.
Also da gibt es ganz viele interessante Artikel zu allen Bereichen,
wenn man jetzt in diesem Bereich gucken möchte,
kann man suchen nach Kai Diss, Wist, CCW,
Yubi kommt, Mobile HCI ECC, CW und Nordika.
Da sind so verschiedene Konferenzen, die in diesem Bereich stattfinden.
Ich sage kurz noch mal was dazu zu den Einzelnen.
Also Kai ist praktisch die amerikanische Dachkonferenz über das ganze Thema.
Dis heißt Designing Interactive Systems. Das ist eher designorientierte Konferenz,
wo es also auch darum geht, neue Lösungen zu präsentieren.
Wist, weiß ich gar nicht genau, wie die Abkürzung heißt.
Es geht auf jeden Fall darum, tolle neue,
schicke Oberflächen und Interaktionsmöglichkeiten zu präsentieren, also ganz viele Multi-Touchs zurzeit.
CCW heißt Corporative, nein, Computer supported, corporative work.
Das heißt, wie arbeite ich Arbeitsgruppen zusammen?
ECCCC WW ist dasselbe, bloß für europäische Verhältnisse.
Und dann gibt es noch Yubikom und Mobile HCI,
Mobile HCI ist praktisch HCI für Handys und Yubikomb ist noch ein bisschen allgemeiner.
Das heißt, Yubikotis computing, das heißt eben,
da geht es darum, dass alles im Prinzip ein Computer sein könnte.
Und Nodikai ist nochmal eine sehr schöne Konferenz,
die ist ähnlich wie die Kai, aber skandinavisch,
das geht dann eher in diese Richtung Participatory Design,
was da gezeigt wird oder einiges davon.
Es gibt ganz viele Blogs in dem Bereich,
die Leute schreiben eigentlich sehr gerne Und es gibt,
vielleicht kennt ihr das auch schon jemanden, Box, es sind Arrows.
Also das ist eher so Richtung Webdesign,
aber eben auch Interaction-Design und Usability, ganz viel an Artikeln.
Das ist sehr praxisrelevant und lesbar. Und dann gibt es
in Hamburg noch einen User-Experience-Roundtable, der ist einmal im Monat und auch ganz interessant.
Also da treffen sich dann immer unterschiedliche Leute aus unterschiedlichen,
ja, Berufen, die mit Usability zu tun haben.
Und einer erzählt was. So, dann wäre ich fertig.
Wir haben noch zwei Minuten, wir können Schluss machen,
könnt ihr mal auch noch Fragen beantworten.