Folge #104 – Usability-Engineering

Thema heute: Usability. Und so viel vorweg: Wenn ihr meint, dass Usability etwas mit schönen Farben und gutem Aussehen und Icons zu tun haben sollte, dann bleibt unbedingt dran, denn Usability ist vielmehr. 

Also, ich starte in meiner Vorlesung immer mit dem Bild, ich zeige drei Kameras. Links so eine Kinder-Fisher-Price-Kamera, klickibunti, die auch runterfallen kann und nicht kaputtgeht. In der Mitte danneine Point-and-Shoot-Kamera, so heißen die Dinger glaube ich — also die Kameras, mit denen man vor 15 Jahren im Urlaub war, also irgendwo draufzeigen, draufdrücken und gut ist. Und ganz rechtsdann so eine Spiegelreflexkamera, eine digitale, in der man alles einstellen kann, manuellen Weißabgleich und was weiß ich was alles. Und dann frage ich die Studierenden immer, was denn jetzt die Kamera mit der besten Usability sei. Und wenn ich dann Glück habe und manche sich melden, dann sagen die … oder was würdet ihr sagen? Denkt kurz nach: drei, zwei, eins. 

Also, die meisten würden sagen, die Fisher-Price-Kamera, weil viele Leute einfach verwechseln: Usability hat was mit eingeschränkter Auswahlmöglichkeit oder auch maximaler Einfachheit oder sowas in der Richtung zu tun. Aber so ist es nicht. Sondern — und das ist, glaube ich, wenn man das Bild gut verstanden hat, dann hat man schon ganz viel von Usability verstanden — es kommt immer auf den Kontext an. Für ein kleines Kind von vier Jahren ist natürlich die Fisher-Price-Kamera die, die am besten geeignet ist, Fotos zu machen. Für einen Fotografen, der Porträtfotos macht, natürlich die Spiegelreflexkamera. Ihr seht schon, Usability kann man nicht nur vom Produkt selbst ableiten, sondern man muss wissen, welche Benutzer welches Ziel mit diesem Produkt erreichen wollen. Und erst dann kann man sagen, ja, in diesem Kontext hat das Produkt eine gute Usability. Also Usability ist nicht schöne Farben, schöne Icons oder sonst irgendwas, sondern das ist viel mehr. 

Vielleicht noch eine Anregung, das ist auch das, was in der Wirtschaft nach meiner Beobachtung gerade immer wichtiger wird. Zumindest in unserem Bereich, also bei den aktuellen KIS-Systemen, bei den Arztpraxis-Systemen, aber auch bei anderen medizinischen Systemen, ist das ein Punkt, auf den immer mehr Augenmerk gelegt wird, weil die Produkte sich von der Funktion gar nicht mehr so wahnsinnigunterscheiden und die Hersteller einfach zu viel Prügel haben einstecken müssen. Das ist einfach nicht mehr in Ordnung, wenn der Arzt da dreimal klicken muss und die Ärztin, wenn sie eine Diagnose eingibt, in vier unterschiedliche Masken springen muss, sondern das Ganze muss jetzt wirklich zielgerichtet zum tatsächlichen Ziel führen. Nicht umsonst sind Google und Apple genau damit großgeworden: Also du möchtest was suchen in der Suchmaschine, ja, dann packt der nicht sieben Checkboxen hin, macht ein Suchfeld hin und einen Button, und gut ist’s. Und für diese ganze Usability gibt es auch eine eigene Norm, das ist die ISO 9241. In der wird eben beschrieben, wie Hardware zu sein hat, wie Software zu sein hat, die eine gute Usability haben sollen, dort wird auch beschrieben, was es für Dialog-Kriterien gibt, und auf das wollen wir heute ein bisschen eingehen. 

Dann holen wir noch mal kurz aus und gehen nochmal einen Schritt zurück, um zu sagen: Was ist denn überhaupt Usability? Du hast schon ein bisschen angedeutet, es ist mehr als nur die grafischeBenutzeroberfläche und irgendwie coole Icons und Farben. Sondern das ist eigentlich nur die Spitze des Eisbergs, das, was man als User natürlich als allererstes sieht. Aber hinter der Benutzeroberflächestecken ja andere Elemente, da steckt ja auch noch das dahinter, was ich überhaupt darstellen kann. Also welche Informationen habe ich in meinem System abgebildet? In welcher Struktur, in welcherForm sind die abgebildet, und welche Funktionen habe ich überhaupt in meinem System zur Verfügung? Das wiederum hängt sehr stark davon ab, was habe ich denn überhaupt für Prozesse imHintergrund? Welche Abläufe sind in meinem System sozusagen modelliert? Welche Ziele sind dahinterlegt, und wie soll, aufbauend auf diesen Zielen, meine Anwendung gestaltet werden? 

Genau, also wenn man die Benutzung und das Ziel und den Kontext nicht kennt, kann man auch kein Produkt bauen, das eine gute Usability hat. Versuchen wir das mal ganz konkret zu machen an einemBeispiel. Ich möchte irgendwie ein Dokumentationssystem bauen. Und ich sehe mir die Benutzeroberfläche an und sage: Wow, die Items sind alle wunderbar schön hinterlegt, da kann ich als User das wunderbar eingeben. Das ist die Oberfläche, der erste Punkt, der sollte natürlich auf jeden Fall erfüllt sein. Aber dann kommt eben auch die Struktur: Habe ich überhaupt alle Informationen auch hinterlegt, die ich für diesen Prozess brauche? Und habe ich die auch in der richtigen Form hinterlegt? Oder sind das alles nur Freitextfelder, keine Zahlenfelder, keine Datumsfelder? Der dritte Schritt wäre dann ebendie Analyse der Prozesse: Habe ich dabei vielleicht auch berücksichtigt, dass diese einzelnen Items in meinem Formular vielleicht von unterschiedlichen Personen zu unterschiedlichen Zeiten in unterschiedlichen Rollen eingegeben werden? Nur wenn ich all diese drei Komponenten, also den Prozess, die strukturierten Informationen und das Ganze in einer schönen Oberfläche gemeinsamberücksichtige, dann kann irgendwie eine gute Usability gelingen. 

Gut, und jetzt haben wir vorhin schon gesagt — ich weiß, ISO-Normen sind immer unglaublich sexy, die ziehen wahnsinnig — aber wenn es schon eine eigene ISO-Norm gibt zu diesem Bereich, dannmöchte ich da auch vielleicht eine Sache kurz vorstellen. Es gibt ein ganz nettes Bild oder eine Skizze, die beschreibt, wie Gebrauchstauglichkeit angewendet werden soll. Das Wichtigste ist das Ziel, das der Benutzer erreicht. Das wird dort dargestellt, und das Produkt muss passen zu diesem Benutzer, zu seiner Aufgabe, zu seiner Umgebung und zu seinem Arbeitsmittel. Vielleicht da auch ein Beispiel: Eine Software im Trauma-Raum von einem Krankenhaus muss natürlich durchaus anders aufgebaut sein als jetzt vielleicht eine Software mit ähnlichen Funktionen, die in einem Pflegeheim läuft, wo weniger häufig hektische Situationen herrschen, wo man vielleicht weniger mit visuell markanten Elementen arbeiten muss. Dort haben wir eine ganz andere Umgebung, wir haben vielleicht andereArbeitsmittel, viel weniger IT-Durchdringung im Pflegeheim als hier zum Beispiel auf einer Intensivstation. Wir haben anders ausgebildete Benutzer, das heißt, all das muss man wissen, damit der Benutzereben mit diesem Produkt auch das Ziel erreichen kann. 

Und wenn er das Ziel erreichen kann, dann wäre es total super — jetzt kommen die Begriffe, die wir hier in Konstanz den Studierenden immer um die Ohren hauen. Es ist wichtig, dass Effektivität, Effizienzund Zufriedenstellung auch gut sind. Effektivität heißt, der Benutzer kann das Ziel überhaupt erreichen, also er kann das, was er machen möchte, auch machen. Effizienz heißt, dass er das mit möglichstwenig Ressourcen machen kann, also ohne jetzt zum Beispiel viel Zeit dafür aufzubringen. Und Zufriedenstellung heißt, dass er dabei … ja, zufrieden ist. Und all das kann man natürlich auch messen, da können uns zum Beispiel Fragebögen hilfreich sein, da kommen wir vielleicht später gleich nochmal dazu. 

Das ist ein Bereich, den die ISO 9241 abdeckt, aber die kann noch mehr, nämlich: In der 9241 gibt es einen eigenen Teil mit den Grundlagen der Dialoggestaltung, und das Schöne an diesen Grundlagenist, dass diese sehr übergreifend formuliert sind. Das ist nicht für einen ganz speziellen Kontext, für irgendwie eine Maschinensoftware in einem Industriewerk oder für irgendwie Krankenhaussoftware ganzspeziell, sondern sehr allgemein. Und da gibt es eben sieben Kriterien. Das ist die Aufgabenangemessenheit, die beschreibt im Prinzip, wie wird der Anwender bei der Erledigung seiner Arbeitsaufgabenunterstützt. Die Selbstbeschreibungsfähigkeit, da geht es darum, sind die einzelnen Dialog-Elemente auch direkt verständlich für den Benutzer, also was passiert, wenn ich auf diesen Button drücke, ist das Icon entsprechend gewählt, beispielsweise. Ein weiterer Punkt ist die Steuerbarkeit: Kann ich meinen eigenen Ablauf so verändern, wie ich das brauche? Stichwort Anfänger oder Experten — kann ich alsExperte vielleicht ein paar Schritte überspringen oder als Anfänger nochmal einen Schritt zurückgehen? 

Nächster Punkt, Erwartungskonformität, also entspricht ein Dialog der Erwartung und Erfahrung des Benutzers. Genau, wenn du da zum Beispiel einen Bilder-Viewer für ein Handy programmierst und die Geste „mit zwei Fingern auseinanderziehen“ nutzt, um ein Bild unwiderbringlich zu löschen, dann ist das nicht erwartungskonform, sondern die Leute würden erwarten, dass du dann ins Bild reinzoomst. Wenn du die aber zum Löschen nutzt, dann hast du diese Vorgabe richtig gerissen, und dann wirst du wahrscheinlich eine Ein-Sterne-Bewertung bekommen. Ein weiterer Punkt eben die Fehlertoleranz, also wie geht ein System mit entsprechenden fehlerhaften Eingaben um? Wir kennen das alle von Google, wir tippen da die Suche ein, und dann kommt häufig — gerade wenn man das schnell eintippt — „Meintest du eigentlich …“, und häufig steht dann genau die Form, eben ohne Rechtschreib-Vertipper, mit drin. Das ist ein Beispiel für eine gute Fehlertoleranz, da werden die Treffer angezeigt für das, was man tatsächlich gesucht hat. 

Zwei Punkte noch: die Individualisierbarkeit, also kann ich meinen Dialog an meine Arbeitsaufgabe und meine individuellen Fähigkeiten anpassen. Und das dritte, Lernförderlichkeit: Werde ich dahintrainiert? Ein Beispiel, ob das jetzt positiv oder negativ ist, könnt ihr selber entscheiden, ist diese schöne Büroklammer in Word. Das ist eine, die manche von Word vielleicht kennen, aber keine Bewertunghat — dazu sind wir zu alt. Hast du ein aktuelleres Beispiel? Ja, habe ich. Und zwar beim Spielen, da gibt es ja am Anfang immer dieses … Ein Tutorial. Ein Tutorial, genau. Das ist, wenn man ein Spiel wirklich das erste Mal spielt, gut, aber wenn du es dann schon kennst und nach zwei Jahren erst mal wieder installierst, dann nervt es dich, wenn du das auch nicht abbrechen kannst. Das heißt, da habenwir dann Lernförderlichkeit super, Individualisierbarkeit — wenn man es nicht abbrechen kann — mies. 

Genau, aber von unseren Spielen zurück zu den Dialogkriterien. Die haben wir jetzt durch, diese sieben Stück, und gleich werden wir eben noch mit dem ISONORM-Fragebogen darauf kommen, wie man das Ganze messen kann. 

Messen ist eine hervorragende Überleitung, vielen Dank, Werner. Also, wenn ihr verantwortlich seid für Software, dann macht ihr das sowieso hoffentlich schon so, dass ihr eine saubereAnforderungsermittlung macht — darüber haben wir ja schon mal gesprochen, Requirements Engineering —, dass ihr das vielleicht bewerten lasst nach der Kano-Methode. Ja, also wir haben euch ja schon wirklich richtig praktische Hilfsmittel an die Hand gegeben, um das ingenieurmäßig und nicht zufällig zu erheben. Das wollen wir jetzt bei Usability Engineering nämlich auch machen. Und zwar gibtes da hervorragende Messmethoden, und zwar solche, die auch nicht nur für Software relevant sind. 

Eine Technik, die dann überall genutzt wird, ist das Eye-Tracking. Das gibt es für Software, das gibt es aber auch sonst, zum Beispiel für einen Supermarkt, da wird es häufig genutzt. Da bekommen also Menschen eine Brille aufgesetzt, die einmal nach vorne filmt, also quasi filmt, wo der Mensch, der die Brille aufhat, gerade hinguckt, aber die Kamera filmt auch die Pupillen und weiß dann, auf welchenBereich genau der Mensch schaut. Und so kann man dann natürlich feststellen, ob der jetzt eher oben oder unten hinguckt, auf die teure oder die günstige Ware. Und das wird auch genutzt, wenn ihr zumBeispiel Software habt und gucken wollt, ob der Benutzer damit klarkommt. 

Wie sollte das praktisch aussehen? Also, idealerweise habt ihr dafür einen Testaufbau, der dem entspricht, wie der Benutzer später auch arbeitet. Also dass ihr vielleicht ein bisschen Stress sogar erzeugt: Wenn ihr einen Benutzer habt, der dann später in der Trauma-Station arbeitet, dann ist es so, dass ihr dem normalerweise eine Aufgabe gebt. Also, er erfasst jetzt mal bitte ein Medikament mit folgendenAngaben. Dann sitzt ihr daneben und schaut einfach nur zu, was der Mensch macht. Wo der Mensch hinguckt, wo der Mensch hinklickt, wird aufgezeichnet, also wo er hinschaut, als auch wo er sich mitder Maus hinbewegt, und er sollte idealerweise noch ein Mikrofon dabei haben, in dem er erzählt, was er denn gerade macht. Also, dann hört man, was passiert, wie: Also, wenn ich ein Medikamentverordnen will, dann würde ich jetzt hier vielleicht auf Medikamente klicken. Ach nee, da sehe ich nur, was er schon hat. Ach, da ist ein Button „Neues Medikament verordnen“, dann klick ich mal darauf. Da lernt man super viel. Warum? Die Methode des lauten Denkens, oder „Thinking Aloud“. Das ist also das, wo man wirklich viel lernt, haben wir damals in der Industrie auch gemacht. 

Das ist interessant, wenn man dann Entwickler mit dazunimmt. Wenn man als Mensch daneben sitzt, der dafür verantwortlich ist für das Produkt, darf man nichts sagen. Es sei denn, der Benutzer fragtirgendwas und kommt überhaupt nicht weiter, dann kann man einen kleinen Tipp geben. Aber ansonsten muss man daneben sitzen und das Ganze über sich ergehen lassen. Und das ist schon interessant, wenn dann Entwickler, die vielleicht längere Zeit an dem Produkt gearbeitet haben, dann erst mal sehen, wie das ein Benutzer benutzt — da gibt es unglaublich riesige Erkenntnisgewinne. Also, kann ich nur empfehlen. 

Ganz kurz, nachdem wir Professoren sind, ein Beispiel: Ich habe mal eine hervorragende Bachelorarbeit betreut. Da haben die genau das gemacht, die haben sich angeschaut, in dem Usability-Review, wie Software bedient wird unter unterschiedlichen Stressleveln. Und zwar haben sie einen Studenten genommen, der sollte was machen, auch in einem KIS. Eine Aufgabe, da hatte er dann eineViertelstunde Zeit dafür und konnte ganz alleine da sitzen. Dann gab es zwei Wochen Pause, und dann wurde ihm — ich glaube Death Metal — laut über Kopfhörer reingespielt, zwischendurch kam einAnruf, er war schwer unter Zeitnot und musste zwischendurch noch irgendwelche Matheformeln berechnen. Und dann war es erstaunlich, wie viele Fehler dann auf einmal passieren. Also man kann das nicht nur nutzen, um nachher eine schönere Oberfläche zu bauen sozusagen, sondern man kann das auch nutzen, um potenzielle Fehlerquellen zu verhindern. Das grob zum Thema Usability-Review und ein bisschen zur Technik Eye-Tracking. 

Magst du dann noch kurz den Fragebogen erzählen, weil Fragebogen ist ja so gar nicht meins. Klar, kann ich gerne machen. Also, das Eye-Tracking hat den großen Vorteil, dass ich objektive Datenbekomme, dass ich im Prinzip die einzelnen Messungen vornehmen kann. Meine Pupillenmodulation, die kann ich jetzt nicht so einfach selbst kontrollieren, sondern das passiert oder passiert eben nicht, und das kann dann eben aufgezeichnet werden. Aber genauso ist es in vielen Fällen geschickt, diese objektiven Daten auch mit subjektiven Einschätzungen zu korrelieren und zu bewerten. Das heißt, das geht in der Regel ganz gut mit einem Fragebogen, und da gibt es im Bereich der Usability verschiedene Bögen, die man nutzen kann. 

Ein ganz einfacher ist die SUS, die System Usability Scale. Die gibt es in Deutsch, Englisch, in einigen weiteren Sprachen. Der besteht eigentlich nur aus zehn kleinen Fragen. Da geht es beispielsweisedarum, dass ich sage, ich kann mir sehr gut vorstellen, das System regelmäßig zu benutzen, oder ich finde, dass es im System viele Inkonsistenzen gibt, oder ich finde, die Bedienung ist sehr umständlich. Der große Vorteil ist, dass die sehr unabhängig von dem einzelnen Produkt ist und sehr einfach und sehr schnell auszufüllen und damit leicht zu vergleichen ist. Ich kann über ganze Bereiche hinweg mir so einen Score ermitteln und sagen, ich habe einen SUS-Score von 95 oder 100, und bei mir sind es leider nur 20 oder so was, und sehe sofort, okay, der subjektive Eindruck des Users ist bei Produkt A vielleicht ein bisschen besser als bei Produkt B. 

Neben dem System-Usability-Scale-Fragebogen gibt es auch weitere Fragebögen, beispielsweise der ISONORM-Fragebogen orientiert sich genau an diesen Dialogkriterien, die wir gerade vorgestellthaben, und bietet zu jedem Kriterium, also Aufgabenangemessenheit, Erwartungskonformität und so weiter, Fragen an, die ich dann auf so einer Rating-Skala von — bis +++, also der Experte sagt, eine 7-stufige Likert-Skala, bewerten kann, also die Software zu beurteilen. „Die Software erzwingt eine unnötig starre Einhaltung von Bearbeitungsschritten“ oder „erzwingt eben keine Einhaltung von Bearbeitungsschritten“ — und dann kann ich eben das Ganze ankreuzen und kriege damit einen Wert, der sich eben an diesen Dialogkriterien orientiert. 

Und ein dritter Fragebogen, auch nur ganz kurz erwähnt, ist der NASA-TLX. Das ist ein Fragebogen, da geht es um den Workload, also wie hoch sind die physischen und psychischen Anforderungen und auch der Frustrationslevel beim Ausfüllen eines bestimmten Tasks. Das kann man auch wunderbar mit entsprechenden Eye-Tracking-Sachen kombinieren, also man sagt, ich lasse mir die objektivenDaten, Pupillenweite, mal anschauen, und alle 10 Minuten lasse ich mal wieder so einen NASA-TLX-Bogen ausfüllen, um dann das Ganze abzugleichen. Also Subjektivität und Objektivität: Wie wird das Ganze denn wahrgenommen? Also, finde ich das Stresslevel, was vielleicht ein Eye-Tracking anzeigt, auch in meinem Fragebogen in Form von Frustration und Performance und physischer Belastungwieder? Ich glaube, das mal so in Kürze, drei Fragebögen. Und ich gehe nochmal zurück an dich, weil du, glaube ich, was zum Thema GOMS sagen willst. 

Genau. GOMS klingt wie so ein bayerischer Begriff für ein … Jetzt werde ich gespannt. Nee, kennst du nicht den Gamsbart? Nee. So. Jetzt können sich die Zuhörer das auf jeden Fall merken: GOMS, G-O-M-S, und Keystroke-Level. Vorneweg, das ist eine Methode, die gar nicht so richtig gut ist, die in ganz vielen Punkten angegriffen werden kann. Ich stelle sie euch trotzdem vor, und zwar, weil dieseMethode dazu führen kann, dass man sich tatsächlich mit der Interaktion beschäftigt und dann darüber nachdenkt. Was bedeutet GOMS? Bedeutet Goals, Operators, Methods und Selection Rules. Da gibtes eine ganz praktische Methode, wie man quasi errechnen kann, wie lange denn jetzt so eine Mensch-Computer-Interaktion dauert, und das heißt Keystroke-Level-Model. 

Ich glaube, am einfachsten ist immer ein Beispiel. Da haben sich irgendwelche Leute überlegt, es gibt unterschiedliche Aktionen, die stattfinden, und jede Aktion kostet einfach eine gewisse Zeit. Also zumBeispiel, wenn man von der Tastatur zur Maus wechseln muss, dann dauert das 0,4 Sekunden. Wenn man die Maus nimmt und jetzt irgendwo einen bestimmten Bereich auf dem Bildschirm anklickenmuss, dann dauert das 1,1 Sekunden, das ist das Pointing. Eine Taste zu drücken dauert 0,2. Und so gibt es dann eben unterschiedliche Sachen. So, und jetzt kommt schon direkt die erste Kritik: Natürlichist das überhaupt nicht individuell. Es gibt Leute, die sind viel schneller. Ich brauche, glaube ich, meistens nicht 1,1 Sekunden, um etwas zu treffen. Natürlich hängt es davon ab, wie weit das entfernt ist und wie groß. Und ich wechsle auch schneller zwischen Tastatur und Maus als 0,4 Sekunden. So, aber es gibt eine Liste, wo einfach drinsteht, wie lange etwas dauert, und natürlich ist das nicht besonders gut und nicht allgemeingültig. 

Wenn man jetzt aber diese Methode nutzt und eine Aktion runterbricht in diese Aktionen und dann einfach eine Zeit berechnet, dann macht man sich dazu Gedanken. Also wenn man sich überlegt, wiekann ich denn jetzt zum Beispiel Medikamente eingeben? Normalerweise sind wir gerade im Kontext, wo der Benutzer vermutlich die Maus in der Hand hat, weil er damit in der Patientenakte rumscrollt. Dann muss er also diesen einen Button treffen, dann klickt er da drauf, muss er vielleicht nochmal in das Feld klicken, wo er dann den Präparatnamen suchen kann. Das muss nicht sein, sondern da könntezum Beispiel der Cursor direkt in diesem Suchfeld sein, also der Fokus könnte in diesem Feld sein. Dann würde man sich einfach die Zeit sparen, indem man wieder die Maus in die Hand nimmt und in dieses Feld klickt. Da hat man wieder 1,2 Sekunden gespart. Ihr seht schon, mit diesen konkreten Zahlen zu rechnen ist natürlich Quatsch. Aber wenn man so jede Aktion durchrechnet, dann macht man sich Gedanken, und dafür ist das hilfreich. 

Ganz konkret, falls ihr Software entwickelt und immer wieder von Kunden hört „Ich brauche zu viele Klicks“: Schaut euch das mal an, wir werden da auch ein kleines Video verlinken, wo ein Mensch das durchrechnet an dem Fahrenheit-und-Grad-Celsius-Rechner. Und wenn ihr das einfach mal ein, zwei Monate einsetzt bei euch, dann glaube ich … Was heißt nochmal ein gutes Wort für Awareness? Gott, Business-English. Ich sag auch immer Awareness. Also um eure Awareness zu steigern für Usability, kann man das Keystroke-Level-Model und GOMS ganz gut einsetzen. Wie schon gesagt, es geht mehrdarum, auf einem generellen Level zu merken, ich wechsle unnötig häufig von Tastatur und Maus hin und her, anstatt jetzt genau festzustellen, hier kann ich nochmal nur 1,3 Sekunden sparen, sondern: Hier sind ganz viele Klicks, obwohl ich eigentlich nur in ein Suchfeld springen will. Aber ich kann es bestätigen, es schafft Awareness und kann damit allein schon helfen, Dinge zu verbessern. 

Wenn ihr ein gutes Wort für Awareness habt, dann schreibt uns auf Twitter, und lacht uns so ein bisschen aus, können wir mit leben. Das ist völlig okay. Wir bauen es dann in der nächsten Folge unauffälligein. Das ist dann der Gag für euch, ganz genau. 

So, sind wir durch, haben wir noch was? Ich glaube, vielleicht ganz am Ende noch mal sagen, was wir jetzt, glaube ich, vergessen haben, was aber unterschwellig damit reinkommt: dass das ganze Thema ein hochinterdisziplinäres Thema ist, wo im Prinzip ganz, ganz viele Personengruppen oder besser Berufsgruppen daran beteiligt sind. Das Thema Oberfläche ist natürlich eher so ein Thema für Grafik, Designer, Layouter, GUI-Experten und so weiter. Das Thema Prozesse eben für Prozessmenschen, Prozesswissenschaftler, vielleicht auch Ökonomen. Dann das Thema Arbeitsbelastung, mentaleBelastung auch, eher was für Arbeitswissenschaftler und Psychologen. Und schließlich sind Informatiker beteiligt, die das Ganze irgendwann vielleicht nochmal programmieren und bauen müssen. Wenn man das irgendwie vernünftig hinkriegen will, dann gehört dazu eine ganz große Portion Interdisziplinarität, die einzelnen Gruppen müssen miteinander reden. Ich muss den Prozess kennen, muss ihnstrukturiert abbilden und das Ganze am besten mit einer schönen Oberfläche kombinieren, um erfolgreich zu sein. 

Ganz genau. Stichwort Kamera: Wenn man nicht weiß, welche Benutzer damit arbeiten, was die erreichen wollen — keine Chance, gute Usability hinzubekommen. In dem Sinne. Schönes Schlusswort. Wir sagen Ciao.