Markus und ich waren letzte Woche an der FH Salzburg, um dort einen 2-Tages-Workshop zum Thema Usability und user-zentriertes Design für Web-Anwendungen durchzuführen. Wir durften eine 11-köpfige Gruppe von Studierenden unterrichten, die kurz vor dem Abschluss ihres Bakkalaureats im Studiengang MultiMediaTechnology stehen.
Es gab gleich mehrere Besonderheiten an diesem Unterricht. Erstens war es das erste Mal, dass wir nicht an unserer FH – der FH Joanneum – unterrichteten, zweitens waren die Studenten keine Designer sondern Programmierer und drittens hatte wir zwei volle Tage zu gestalten, was uns vor die bislang unbekannte Aufgabe stellte, den Unterricht im Vorfeld planen zu müssen.
Ein Plan? Wohl eher eine Vision!
Jedes Mal, wenn wir vor einer Unterrichtseinheit darüber sprechen, was wir ca. machen werden, erkennen wir recht schnell, dass sich diese Einheiten nicht planen lassen. Natürlich, viele Lehrer und Professoren planen ihren Unterricht bis ins kleinste Detail – nur waren die meisten der Unterrichtseinheiten, an die ich mich noch als Schüler zurückerinnere leider langweilig und völlig sinnbefreit und deshalb kein brauchbares Vorbild für unseren Unterricht.
Statt einen minutiösen Plan zu entwickeln, entwerfen wir deshalb eine grobe Vision für unseren Unterricht. Bei unserem aller ersten Unterricht an der FH Joanneum lautete diese Vision z.B.: „Wenn nur ein einziger Student das Thema Usability am Ende unseres Unterrichts nicht mehr langweilig und sinnlos findet, dann haben wir einen guten Job gemacht.“ Klar, allzu anspruchsvoll war diese Vision noch nicht. Für unseren 2-Tages-Workshop in Salzburg lautete die Vision in etwa so: „Die Leute müssen checken, dass Usability und user-zentriertes Design keine theoretischen Wissenschaften sind, sondern ihnen dabei helfen, ihre Arbeit besser zu machen und dabei mehr Spaß zu haben.“ Das war schon eine etwas ambitioniertere Vision, aber dafür hatten wir ja auch 2 Tage Zeit.
Für jeden, der sich dafür interessiert bzw. selbst einmal vor der Aufgabe steht, einen Workshop zu planen, stellen wir hier 2 Dokumente zum Download bereit, die wir erstellt haben, um den Workshop vorzubereiten:
Ablauf des Workshops
In der Mittagspause des ersten Tages hatten wir eine kurze Unterhaltung mit einem Studenten, der von einem Usability-Workshop berichtete, den die Gruppe zu Beginn des Semesters hatte. Dieser (und auch die anderen) Studenten hatten nicht gerade eine hohe Meinung vom erwähnten Workshop. Der Grund dafür war, dass der Vortragende, den größten Fehler beging, den man beim Unterrichten machen kann: Er kam in die Klasse und begann zu unterrichten. Es gibt nichts Tödlicheres für einen Unterricht als ein Lehrer der zu unterrichten beginnt.
Ethos, Pathos, Logos – in dieser Reihenfolge
Jeder Unterricht, jeder Vortrag, jede Präsentation – einfach jede Situation, in der jemand zu einer Gruppe von Menschen spricht (oder auch schreibt) beginnt damit, dass die Zuhörer bzw. die Leser, den Eindruck bekommen, der Vortragende bzw. der Autor wäre jemand, der es wert ist, ernst genommen zu werden. Wir neigen dazu, Menschen zu glauben, die wir respektieren. Als Erstes müssen wir uns also um unsere Glaubwürdigkeit kümmern. Wir haben das gemacht, in dem Markus (kurz) von unserem Werdegang berichtet hat und innerhalb weniger Minuten, drei oder vier aussagekräftige Projekte vorstellte, an denen wir in letzter Zeit gearbeitet haben bzw. gerade arbeiten. (=Ethos)
Gleich danach habe ich damit begonnen, Geschichten aus unserem Arbeitsalltag der letzten 2 bis 3 Jahre zu erzählen. Es fällt mir gerade schwer, mich daran zu erinnern, welche Geschichten ich genau erzählt habe, weil das bei mir meist sehr spontan geschieht und ich mich nicht darauf vorbereite, wichtig ist aber ohnehin nur ein Wort: Geschichten. In der zweiten Phase lautet das Ziel eines Autors oder Vortragenden, eine emotionale Beziehung mit seinem Publikum aufzubauen. Das Publikum muss sich mit dem Vortragenden identifizieren können und fühlen, was er fühlt. Und am besten gelingt das mit Erzählungen, die abstrakte Begriffe, wie user-zentriertes Design, Interface-Design und Usability in etwas Greifbares und Nachvollziehbares verwandeln. (=Pathos)
Bis hierhin dauerte unser Unterricht ca. eineinhalb Stunden. Das waren 90 Minuten in denen wir nur von uns erzählten und maximal unabsichtlich etwas Lehrreiches berichteten. Im Nachhinein könnte man denken, was für eine vergeudete Zeit. Die Wahrheit ist aber, dass ohne dieses „Vorspiel“ die restlichen 1 ½ Tage niemals zu dem geworden wären, was sie schließlich wurden. Und zu was wurden diese 1 ½ Tage? Zu einem Selbstläufer. Wenn es um Design geht, dann wissen wir, wovon wir sprechen und sind von unserer Arbeitsweise überzeugt – was jeder einzelne Student auch gemerkt haben dürfte. Das Einzige was wir tun müssen, damit unser Unterricht funktioniert, ist die Studenten ebenso für unser Thema zu begeistern. Nachdem uns das gelungen war, konnten wir langsam aber sicher damit beginnen zu unterrichten. (=Logos)
Zum Mitnehmen
Wir haben bereits am Ende des zweiten Tages, die Frage gestellt, was die Studenten zu unserem Unterricht zu sagen haben. Dafür gilt es erst einmal danke zu sagen, für eure Offenheit (ich spreche jetzt direkt zu den Studenten, falls sie das hier lesen) und natürlich auch danke zu sagen dafür, dass ihr mit so viel Begeisterung mitgearbeitet habt, sodass die 2 Tage für uns zu einem unvergesslichen Erlebnis wurden. Danke.
Natürlich haben wir über eure Kritik gesprochen und versuchen mit diesem Artikel gleich eine Bitte zu erfüllen. Ein Student hat gemeint, dass es schön wäre, eine Art Zusammenfassung oder etwas Ähnliches zu bekommen, um etwas zu haben, das man sich in ein paar Monaten oder Jahren noch einmal ansehen kann, wenn man sich den Unterricht zurück ins Gedächtnis rufen möchte. Machen wir natürlich gerne :)
Zunächst der Vollständigkeit halber:
Unser neues Buch: Wir erklären dir in klarer und verständlicher Weise, wie User Testing in der Praxis wirklich funktioniert » Zum Buch
Und jetzt zur kurzen Zusammenfassung. Zusätzlich zum Szenario und der Präsentation haben wir uns noch 7 Grundsätze für Web-Entwicklung überlegt, die kurz unsere 2 Tage zusammenfassen sollen und euch hoffentlich in Erinnerung bleiben:
1. Designer und Programmierer sollten miteinander arbeiten, nicht nacheinander.
Wenn es nur eine einzige Sache gibt, die ihr aus unseren gemeinsamen 2 Tagen mitnehmen könnt, dann sollte das die Tatsache sein, dass Designer und Programmierer nicht zwei unterschiedlichen Abteilungen angehören dürfen, die sich nur gelegentlich treffen. Design und Programmierung gehören zusammen und wer beide Bereiche voneinander trennt, hat keine Chance, web-basierte Software zu entwickeln, die wirklich gut ist. Der Artikel From Idea to Implementation aus Getting Real zeigt noch einmal warum.
2. Wir müssen mit den Menschen reden, bevor wir eine Lösung für ihre Probleme entwickeln können.
Es gibt zwei grundsätzlich verschiedene Methoden um eine Software zu entwickeln. Entweder ihr macht Software für euch selbst oder ihr entwickelt etwas für andere Menschen. Sobald ihr Software für andere Menschen macht, solltet ihr euch die Zeit nehmen, mit diesen Menschen zu reden, bevor ihr anfangt eine Lösung für ihre Probleme zu entwickeln. Wenn ihr sehen wollt, wie das geht, lest euch einfach diesen Artikel über Benutzer-Interviews durch, den ich vor einigen Wochen geschrieben habe.
3. Anforderungen sind mehr als eine Todo-Liste.
Erinnert ihr euch an die Geschichte, als wir eine Website für ein Dienstleistungsunternehmen entwickeln sollten und eine Liste von Anforderungen hatten, die ca. drei A4-Seiten lang war? Oder könnt ihr euch vielleicht an ein eigenes Projekt erinnern, wo eure Anforderungen nichts weiter waren, als eine Todo-Liste? Jetzt denkt an das Werkstatt-Szenario und ihr merkt wie wichtig die Geschichten sind, um den Kontext und die Ziele eurer Benutzer zu verstehen. Nur wenn ihr ein Problem wirklich versteht, könnt ihr auch eine Lösung dafür entwickeln. Eine Todo-Liste hilft euch dabei nur, um sicherzustellen, dass ihr nichts vergessen habt.
4. Szenarios sind für Software-Entwickler wie Drehbücher für Filmemacher.
Bei der Entwicklung von Software, sind Szenarios unsere Drehbücher. Beim Lesen der Geschichte, entsteht sofort ein Bild im Kopf und ihr beginnt fast automatisch und intuitiv mit dem Design-Prozess. Wenn ein Regisseur ein Drehbuch liest, dann kann er den Film bereits in seinem Kopf ablaufen lassen. Wenn ihr ein Szenario lest, dann könnt ihr euch bereits vor eurem inneren Auge ausmalen, wie ein Interface aussehen könnte, das euren Benutzern dabei hilft, ihre Ziele auf einfache und angenehme Weise zu erreichen.
5. Lasst euch nicht von eurem Verstand sabotieren – es gibt mehr als die eine Lösung.
„Ihr habt 5 Minuten Zeit, um mindestens 8 verschiedene Lösungen zu zeichnen.“ Einige haben wirklich so viele Lösungen geschafft, andere konnten nur einen einzigen Entwurf machen – das waren die 5er-Kandidaten. Aber Spaß beiseite … lasst euch nicht von eurem Verstand sabotieren. Der menschliche Verstand ist darauf ausgerichtet zu glauben, er wüsste was richtig und was falsch ist. Folglich liefert er euch nur eine einzige Lösung. Hätte er mehrere Lösungen, würde das ja bedeuten, dass einige der Lösungen falsch sind, und dieser Gedanke ist für unseren Verstand nur schwer zu ertragen. Wenn ihr nicht weiter wisst, dann hört auf die innere Stille. Verliert euch nicht in Gedanken. Gedanken können keine kreativen Lösungen bringen. Versucht nicht zu denken und seid einfach still. Innerlich. Inspiration kommt zu euch, ihr müsst nur aufmerksam sein und sie wahrnehmen, wenn sie kommt und nicht damit beschäftigt sein, dem inneren Sprecher zuzuhören, der euch nichts weiter erzählen wird, als dass die aktuelle Lösung schon perfekt ist, wie sie ist.
6. Die erste Idee ist meistens schlecht.
Das ist der Grund, warum ihr viele verschiedene Lösungen ausprobieren solltet: Die erste Idee ist meistens schlecht. Es kann natürlich auch sein, dass eure erste Idee absolut genial ist – kann sein. Wissen könnt ihr das aber erst nach eurer 5. oder 8. oder eurer 100. Lösung. Und wer will schon die restliche Zeit damit verbringen, an einer unausgereiften Idee zu arbeiten? Natürlich ihr könnt die erste Idee nehmen und nur noch daran arbeiten, diese Lösung zu verbessern. Aber merkt euch, wer Lippenstift auf ein Schwein aufträgt, bekommt im besten Fall ein schönes Schwein.
7. Wir testen nicht, um unsere Ideen zu bestätigen, sondern um Fehler zu entdecken.
Wir konnten teilweise die Enttäuschung in euren Gesichtern erkennen, als das Feedback bei den Guerilla-Tests eurer Prototypen nicht nur positiv war. Vor allem konnten wir uns aber daran zurückerinnern, wie schwer es uns selbst oft gefallen ist, negative Kritik anzunehmen. Wir sagen euch jetzt dasselbe, was wir uns früher auch gesagt haben: Wir testen, weil wir herausfinden wollen, was noch scheiße ist. Mit diesem Vorsatz im Kopf werden Usability-Tests zu einem angenehmen Ereignis, in dem uns nichts mehr freut, als negatives Feedback. Deshalb machen wir diese Tests in Wahrheit. Das Schlimmste was passieren kann, wäre kein negatives Feedback zu bekommen, denn das würde bedeuten, wir haben entweder umsonst getestet oder – was wahrscheinlicher ist –, wir haben falsch getestet.
Zum Abschluss
Wir hoffen ihr könnt mit diesem Artikel etwas anfangen und empfindet ihn ähnlich hilfreich wie unsere gemeinsamen Tage in Salzburg. Natürlich freuen wir uns über jeden, der sich noch kurz die Zeit nimmt, uns in einigen Worten zu sagen, wie er den Unterricht gefunden hat. Was war gut? Was war schlecht? Konnten wir die Inhalte verständlich rüberbringen?
Wie öfters erwähnt, war es für uns das erste Mal, dass wir 2 komplette Tag unterrichten durften und wir sind für jede Form von Feedback dankbar, das uns dabei hilft, in Zukunft besser zu werden.
Nächster Artikel: Woran wir glauben: Die 5 Simplease-Werte
Dominik Guzei — 23. Mai 2012
Hey Stefan und Markus!
Danke für die tolle Zusammenfassung der zwei Tage :-) War echt der Hammer und die Erfahrung werden wir in alle zukünftigen Projekte mitnehmen!
Kritik ist nur noch schwer anzubringen, da wir selten so guten Unterricht genießen und mir auch keine konkreten Dinge einfallen die man vielleicht besser hätte machen können. Wie schon angesprochen, Geschichten erzählen scheint oft „Zeitverschwendung“ für Lehrende zu sein, obwohl es genau das war was euren Unterricht so genial gemacht hat! Man könnte jetzt hergehen und sagen „na, wissen die Studierenden die 500 Gebote von Usability auswending?“ und danach beurteilen, damit würde man allerdings nur zeigen wie eingeschränkt man ist :-D
Alles Liebe aus dem regnerischen Salzburg!
Markus — 23. Mai 2012
Hallo Dominik, vielen lieben Dank für dein tolles Feedback, auf das wir natürlich sehr stolz sind :) Ich freu mich auf ein Wiedersehen,
liebe Grüße Markus
Pingback Organisiert lesen, anmerken und wiederfinden mit Kindle und Evernote | Simplease Blog — 24. Mai 2013
[…] (typeof(addthis_share) == "undefined"){ addthis_share = [];}Um Inhalte für unsere Lehrveranstaltungen zu erarbeiten (und um nicht ganz zu verblöden) lese ich recht viel Literatur rund um Usability, UX […]
Pingback Testing early and often with Userbrain | Simplease Blog — 27. Oktober 2014
[…] of testing early and often. We write about it on our blog, talk about it in presentations and teach students the importance of getting into the feedback loop as soon as possible. Yet we ourselves regularly experience how hard it is, to not just talk the […]