We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Usability Testing in GIS

00:00

Formal Metadata

Title
Usability Testing in GIS
Title of Series
Number of Parts
96
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Bedien- und Benutzerfreundlichkeit in Software kann effektiv getestet werden. Welche Testmethoden es gibt und was dabei zu beachten ist, wird im Vortrag erklärt.
45
Thumbnail
25:28
UsabilityLecture/Conference
UsabilityRequirements engineeringUser interfaceSoftwareInformation systemsDatabaseWorld Wide WebPostgreSQLServer (computing)Uniformer RaumProxy serverYES <Computer>User interfaceUsabilityGistContent (media)Lösung <Mathematik>SoftwareRoute of administrationComputer animation
UsabilityYES <Computer>Lecture/ConferenceComputer animationDiagram
UsabilityHöheUsabilityComputer animation
Inverter (logic gate)Negative numberEASY <Programm>SoftwareJSONXMLComputer animationLecture/Conference
UsabilityMoment (mathematics)XMLComputer animation
UsabilityPrototypeVideo trackingHypothesisSoftwarePrototypeConcurrency (computer science)FacebookSage <Programm>WordLecture/ConferenceComputer animation
Inverter (logic gate)Video trackingJSONXMLUML
UsabilityOpen sourceTemplate (C++)PrototypeComputer animation
Sound <Multimedia>Function (mathematics)Software testingStatistikerStatisticsLecture/Conference
UsabilitySoftwareSoftwarePrototypePoint (geometry)XML
UsabilitySoftware testingPlane (geometry)Lecture/ConferenceComputer animation
StatisticsLecture/Conference
UsabilitySoftwareLink (knot theory)Route of administrationSharewareWeb browserInterface (computing)SoftwareDatabaseRoute of administrationLevel (video gaming)Computer animation
UsabilityNoten <Programm>Moment (mathematics)JSONXMLUML
UsabilitySoftware testingXMLComputer animation
Google MapsSoftware testingSoftwareMicrosoftListe <Informatik>GoogleMAPPERPrototypeFunktionalitätMach's principleInterface (computing)otto <Programmiersprache>UsabilitySimilarity (geometry)Lecture/Conference
UsabilityInferenceXMLComputer animationLecture/Conference
Transcript: German(auto-generated)
Die Lina Dillmann wird uns erzählen über Usability-Testing in GIZ. Ich bin auch sehr gespannt. Und Lina Frei. Ja, hi. Ich bin Lina. Schön, dass ihr alle da seid. Freue mich sehr.
Ja, wer bin ich? Das hatte ich gerade eben schon gesagt. Ich bin Lina und ich stelle mich mal kurz vor. Ich bin im Requirements Engineering, also in der Anforderungsanalyse bei der Bear Group tätig und habe vorher im User Interface und User Experience Design gearbeitet. Habe da selber auch so ein bisschen Software designt, als auch Konzepte
gehabt, aus denen die Inhalte rausgenommen und eben auch in Design umgewandelt. Habe dort auch ein bisschen Testing gemacht und ehrenamtlich bin ich beim Webmontag bei der FOSCIS und mache CrossFit. Jetzt habt ihr so ein kleines Bild, wer ich überhaupt bin. Zur Bear Group. Wir sind, also wir bieten Daten, Karten, Lösungen an.
Ja, die verschiedensten Sachen. Wir sind selber 40 Mann, falls jemand Interesse hat und gerne codet. Bewerbt euch gerne. Wir machen selber Lösungen wie zum Beispiel MapBender oder auch Mops. Das ist eine Mobile, ja, ein Mobile Gist mittlerweile.
Und ja, haben auch die FOS Academy, falls ihr mal zur Schulung wollt. Aber deswegen seid ihr ja nicht hier. Worum geht es jetzt? Es geht um Usability. Wem sagt Usability etwas? Es sind schon einige.
So, Usability, was ist das überhaupt? Es setzt sich aus dem englischen use zusammen und ability, der Fähigkeit. Es bedeutet, dass Benutzerfreundlichkeit gegeben wird und eben auch schnelle und optimale Wege für den Nutzer da sein sollten. Also im Sinne des Nutzers, nicht im Sinne der Anwendung.
Dann gibt es immer dieses Beispiel, was ganz gerne genommen wird, aus was brauche ich überhaupt? Was gebe ich meinem Nutzer? Was möchte er aber wirklich haben? Also eigentlich braucht er einen Baum, wo ein Ring dran ist. Ich gebe ihm aber zum Beispiel einen Baum mit drei Schaukeln und noch ein Klettergerüst und weiß ich nicht noch, sechs anderen Sachen, was er aber überhaupt nicht möchte.
Ja, Usability kennen die meisten. Das fängt schon an bei Türklinken, die einfach auf der richtigen Höhe sind, dass ich nicht andauernd mich bücken muss oder nach oben greifen muss. Oder eben auch Ticketautomaten von der Bahn, die es meistens nicht sind.
Usability-Testing, darauf wollte ich jetzt gerne mal weiter eingehen. Es gibt von Jacob Nielsen eine tolle Aussage.
Was so viel bedeutet wie Feedback, was ihr bekommt, sei es auch negatives. In jeglicher Hinsicht ist das, was eigentlich das Tolle ist. Das, was auch gute Software ausmacht, ist, wenn man negatives Feedback bekommt und damit arbeiten kann. Was ist Usability-Testing?
Usability-Testing ist in dem Bereich, dass wir intuitive Nutzbarkeit analysieren. Das können wir natürlich nur, wenn wir Nutzer haben, bei denen wir es auch testen können. Wenn wir selber rangehen und zum Beispiel schon vorbelastet sind, weil wir unsere Software kennen, dann erwarten wir von ihr ganz anderes als zum Beispiel ein Nutzer, der ein ganz anderes Know-how hat oder einen ganz anderen Background.
Gleichzeitig ist es auch die Übersichtlichkeit zu testen, Wege zu ersparen, dass der Nutzer nicht erst sechsmal klicken muss, obwohl er einmal klicken müsste und direkt am Ziel angelangt ist. Die Größe der Elemente. Da gibt es zum Beispiel ein tolles Beispiel über einen Button, der im Prinzip gar nicht gefunden wird,
weil er zum Beispiel in der falschen Farbe ist oder zum Beispiel auch so etwas wie ein Abbrechen-Button, der in grün ist. Aber was zum Beispiel in dem Moment eine ganz, ganz fiese Angelegenheit ist, weil nämlich die Nutzer grün bedeutet bestätigen für uns. Das bedeutet, die gehen alle automatisch auf den Abbrechen-Button, statt auf den Speichern-Button, der zum Beispiel grau ist.
Und ganz, ganz wichtig, die Erwartungen des Nutzers erkennen und einhalten. Dass man weiß, was will er überhaupt. Ganz häufig gehen wir mit Hypothesen rein, die sich aber gar nicht bestätigen. Was für Testmethoden gibt es? Da möchte ich euch jetzt mal einen kurzen Überblick geben.
Nämlich einmal Prototyping. Das ist mehr so in der Anfangsphase. Ihr geht rein und baut euch dann einfach Dummies, die ihr dann im Prinzip durchklicken lasst, um einfach zu gucken, ob die Wege gefunden werden. Benchmarking ist, dass ihr eine Analyse macht, was gibt es schon auf dem Markt und was brauche ich. Um zum Beispiel mit meiner Konkurrenz einfach mitziehen zu können.
Dann Personas, dass du sagst, das ist meine Zielgruppe. So soll die optimale Person im Prinzip für uns aussehen. Und ja, im Prinzip eine Art erweiterte Zielgruppe, die sich dann dementsprechend weiter entwickelt.
Interviews und Fragebürgen sind so das gängigste, gerade On-Site-Befragungen. Man kennt das zum Beispiel auch von Facebook. Hey, hast du nicht mal drei Minuten Zeit? Klick dich mal kurz durch, sag uns mal kurz deine Meinung. Ansonsten auch in-house kennt man das ganz gerne, dass man dann auch mal einen Fragebogen hat. Sag uns mal dein Feedback, was so los ist, was eben auch häufig einiges bringt, aber eben auch versteckte Sachen nicht zeigt.
Tagebuch studieren, das ist, dass man jeden Tag mitschreibt und einfach guckt, wo entstehen jeden Tag Probleme. Eye-Tracking, das wird gleich ja nochmal vorgestellt, deswegen gehe ich darauf jetzt nicht so ein. Das ist, dass man eben eine Kamera am Bildschirm hat, gleichzeitig der Bildschirm aufgenommen wird
und man dann analysiert, wo hat sich das Auge hinbewegt. Single-Loud ist meine persönliche Lieblingsmethode, gerade wenn die Software fertig ist, weil es eben lautes Denken bedeutet. Man setzt sich hin und dann bittet man den Nutzer einfach das, was er denkt, in Worte zu fassen und zu sagen,
oh, wo ist denn der Button? Die Suche ist nicht da. Wo ist die Suche? Warum finde ich die nicht? Also gerade solche Sachen, dadurch weiß man sehr, sehr viel, was der Nutzer so möchte. An für sich eine richtige Aussage, gerade für das Tracking ist es sehr, sehr wichtig.
Deswegen auch dieses laute Denken favorisiere ich, weil das, was Nutzer machen, ist meistens eine ganz andere Sache als das, was sie nochmal von sich geben. Wann setzt ihr denn was ein? Ich bin gerade eben schon mal darauf eingegangen mit den verschiedenen Möglichkeiten,
was im Prinzip Prototyping ist in der Phase vor der finalen Entwicklung oder wenn ihr zum Beispiel neue Features baut. Dass ihr die einfach mal kurz prototypt und dann vielleicht hinlegt und mal irgendeinem Kollegen sagt, hey, funktioniert das jetzt gerade?
Wenn der damit klarkommt, ist die Wahrscheinlichkeit, dass zumindest ein Großteil der Nutzer damit klarkommt, ziemlich hoch. Ansonsten habt ihr natürlich solche Fragen wie Budget. Also gerade in der freien Open Source Software ist es ja auch so, dass man oft kein Budget hat, nicht so viel Geld, dass man jetzt sagen könnte,
wir machen jetzt verschiedene Stadien des Testings und jetzt gehen wir alles durch. Da wäre natürlich auch nochmal drauf zu achten, für was nehme ich was? Woher bekomme ich die Testpersonen? Immer eine gute Frage, damit haben sogar große Unternehmen ihre Schwierigkeiten.
Entweder man kauft Tester, meistens studentische Hilfskräfte irgendwo ein, die dann Dinge durchtesten, was aber vielleicht nicht unbedingt meine Zielgruppe in irgendeiner Form ist. Das was und das wie. Was soll überhaupt getestet werden und wie soll ich das überhaupt testen? Für Laien meistens eine ganz, ganz schwierige Frage. Die denken sich dann, ich habe jetzt ein System, das besteht aus 30, 40 Templates
und da habe ich noch Funktionen drin und letztendlich ist es dann ein Katalog von wahrscheinlich irgendwie 20, 30 Seiten, die man da durchgehen würde mit dem Nutzer. Nutzer ist aber, man sagt so nach einer halben Stunde, spendest nach Stunde nicht mehr wirklich aufnahmefähig. Am besten Kürzer erhalten.
Und die Auswertung. Auswertungen kann man natürlich über Statistik machen. Das kennen wahrscheinlich auch einige so aus dem Studium, wenn ihr Bachelorarbeiten geschrieben habt, habt ihr ja auch noch eine Umfrage mit Auswertungen, Statistiken und ansonsten eben einfach darauf zu achten. Was möchte euer Nutzer? Was ist denen wichtig? Deswegen finde ich zum Beispiel die ThinkAloud Methode sehr, sehr gut, weil man danach nochmal Feedback sich einholen kann und solche Sachen.
Ja, die Tester. Why you only need to test with five users. Das hat Jakob Nielsen herausgefunden. Jakob Nielsen ist ein Inhaber von einer relativ renommierten Testing Firma aus den USA
und hat da wirklich auch Statistiken zugemacht. Das bedeutet, fünf Nutzer können euch schon wirklich nach vorne bringen, wenn ihr testen wollt. Ja, die Tester. Woher kommen die? Also eure Zielgruppe, die professionellen einkaufen. Entweder ihr habt irgendeine Firma, die das für euch regelt
oder eben ihr guckt einfach mal, macht eine Ausschreibung. Meistens kommt da aber nicht so viel rum. Bekannte Fragen. Also im ersten Versuch gehe ich immer ganz gerne mit Kollegen durch. Hey, ist das jetzt überhaupt optimal?
Funktioniert das? Auch ganz nett ist das, wenn man zum Beispiel so eine Großmutter hat, die um die 80 ist und Software überhaupt nicht versteht. Einfach mal reinwerfen. Ansonsten kann ich noch sagen, ich bin ein Fan von Veranstaltungen, also Usability-Veranstaltungen, wo man auch ein paar Leute hat, die testen wollen. Dazu gebe ich euch gleich nochmal ein Beispiel.
Die kann man besuchen, aber auch organisieren. Dann kann man sich mit einigen Firmen zusammentun oder auch einfach sagen, ach, da ist gerade ein Usability-Testing und dann schließe ich mich da einfach an und gucke mal, was ich gerade an Prototype habe oder sogar an fertiger Software und lasse die einfach mal testen, kostenlos.
Single-Loud, lautes Denken, darauf würde ich jetzt gerne nochmal eingehen. Das Was und Wie. Das ist natürlich immer eine große Frage. Was genau soll getestet werden? Die Software. Das Testszenario zum Beispiel sollte nicht eine DIN A4 Seite überschreiten. Und da reden wir jetzt schon von zwölf Punkten.
Dass wirklich die Leute optimal testen können und auch nicht frustriert rausgehen, sondern eher Spaß an der Sache haben. Die Aufgabenstellung sollte meistens in mehrere leichter oder zumindest, dass man auch so eine Aufgabenstellung hat. Da gebe ich euch gleich noch ein Beispiel zu, die dann unterteilt ist. Das bedeutet nach dem ersten, wenn sie das und das geschafft haben, freut man sich und dann nimmt man den nächsten Step.
Start- und Zielfestlegen ist auch wichtig, dass man entweder eine begrenzte Zeit hat oder eben sagt, okay, ich möchte gerne Aufgabe eins, zwei, drei und vier durchmachen und dann eben guckt, wie weit man kommt. Ja, wie soll getestet werden? Natürliche Testsituationen sind wichtig. Tester und Moderator.
Also ihr könnt einfach selber hingehen und euch das zusammen schreiben und dann einfach als erstes ein bisschen Smalltalk halten. Der Nutzer sollte kurz das System kennenlernen. Gerade wenn es für ihn Neuland ist und er einfach keine Ahnung davon hat, sollte er ja kurz mal eingeführt werden, worum es geht. Dann die Aufgabenstellung, Hypothese und Ziel. Das kann man sehr, sehr schön nochmal auch auf so eine emotionale Ebene bringen.
Dann das Feedback einholen und ganz, ganz wichtig ist Bedanken. Ja, vor dem Testing bzw. während dem Testing ist für uns als Moderator sehr, sehr wichtig, dass wir als erstes eine Einverständnis haben.
Gerade seit DSGVO ist das ein bisschen tricky oder eben auch wenn man sagt, hey, wenn du eh schon laut denkst, darf ich das überhaupt aufnehmen? Also zum Beispiel, dass man sagt, ich lass einfach kurz was mitlaufen, dann kann ich das später nochmal abspielen oder wir können das im Team nochmal anders auswerten. Name und Alter notieren, damit ihr eben auch eure Statistik pflegen könnt, wenn ihr das weitermacht.
Erkenntnisse notieren, also wenn zum Beispiel man sagt, ich find die Suche nicht. Und dann wiederum, ich find die Suche nicht oder so etwas. Dann wäre es wichtig, dass ihr dort einfach nochmal die anderen zentraleren Platz rückt oder so etwas. Die Aufgabenstellung, darauf bin ich gerade eben schon eingegangen.
Und dann, oh, da hab ich doppelt gekoppelt und gepastet. Genau, Feedback. Feedback könnt ihr auch nochmal stärken und Schwächen abfragen. Ein Beispiel jetzt, anhand von MapBender hab ich das jetzt mal erstellt. Das ist als erstes Smalltalk. Stimmung auflockern. Hallo, ich bin. Und eben auch solche Sachen wie, wer bist du überhaupt?
Ach, du bist so und so alt, schön, fähig, noch einen Beruf herausfinden. Dann hat man direkt so eine Schnittstelle, welche Hobbys hast du? Damit kann man auch so ein kleines Profil anlegen. Das ist PersonXY und das macht sie vielleicht auch noch Dinge, die euch wichtig sind. Wenn wir jetzt im Geobereich sind, ob die Person irgendetwas mit eurem speziellen Thema zu tun hat.
Oder ob ihr vielleicht guckt, ob da jetzt gerade jemand ist, der damit überhaupt noch gar keine Schnittstellen hat. Dann das System kennenlernen. Genau, du wirst MapBender testen, kennst du MapBender?
Dann vielleicht nochmal darauf eingehen, was die Software kann, was sie tut. Und dann eben auch nachzufragen, bist du stark klar, hast du noch Fragen. Dann die Aufgabenstellung. Du möchtest eine neue Anwendung im MapBender anlegen und dort eine Karte zerstellen, mit der du die öffentlichen Spielplätze von Köln anlegen kannst. Das ist zum Beispiel, wir haben herausgefunden, dass die Person, die wir jetzt gerade vor uns sitzen hatten,
zum Beispiel Erzieherin ist und deswegen zum Beispiel machen wir aus Plätze Spielplätze oder legen das so an, dass diese Person direkt einen emotionalen Bezug dazu hat. Dadurch kommt sie sehr viel schneller in das Testing rein, als wenn wir einfach nur sagen, ja such jetzt mal ein paar Plätze.
Also es sollte ja irgendwie auch so die Stimmung mitschwingen. Ja, genau, was auch wichtig ist, vielleicht Dinge nochmal fett zu markieren, vielleicht auch in einzelnen Dateikarten die Aufgabenstellung zum Beispiel hier eins nochmal vorzulegen, dass sie sich die durchlesen können oder einfach sie so kurz zu machen, dass man einfach nur sagt, suche den Speicherbutton.
Beispiel hier an der Aufgabenstellung kann zum Beispiel sein, ok, du hast jetzt als erstes die Karte angelegt, jetzt gehen wir weiter auf der Basis, dass man auf die Karte aufbaut oder eben auch neue Dinge darauf erstellt.
Das bedeutet, der Nutzer sieht nicht, dass das, was er tut, ins Blaue läuft, sondern einfach aufeinander aufbauen. Das Feedback ist ganz wichtig, dass ihr offene Fragen stellt, damit auch etwas zurückkommt. Also nicht, du hast ja gerade den Speicherbutton nicht gefunden, woran denkst du lag das, sondern einfach zu sagen, ok, was hat dir jetzt gerade besonders gut gefallen, was hat dir überhaupt nicht gefallen?
Hast du vielleicht auch noch Lust, irgendetwas uns mitzugeben? Und dann fangen die meisten wirklich an zu reden. Sie fangen an zu reden, was sie wollen, was sie möchten, wie sie meinen, dass die Software sein sollte.
Dann Danke sagen, bedanken, gegebenenfalls nach Kontaktmöglichkeiten fragen, da kann man sich auch so ein bisschen ja so eine Community selber aufbauen, ein kleines Netzwerk, wo man dann zum Beispiel, wenn man zwei, dreimal irgendwie was getestet hat, dass man dann wirklich sagt, ok, hast du nicht nochmal Lust, was mitzumachen?
Und dann irgendwann so eine Datenbank auf 20, 30 Personen da hat. Und die Auswertung. Ja, Confucius hat schon gesagt, der Weg ist im Usability-Testing das Ziel. Also in unserem Fall ist wirklich der Weg das Ziel. Viele wollen ganz gerne das perfekte Produkt direkt haben.
Das funktioniert so nicht. Es gibt immer ein paar Steine, die man nicht im ersten Moment betrachtet, wo man aber jederzeit irgendwie wieder sagen kann, ok, der Button muss jetzt eben nicht auf die linke Seite, auf der rechten Seite ist er gerade vom Suchverlauf des Blickes her viel besser zu finden oder solche Sachen. Ja, wie wertet man aus?
Jedes Feedback ist gutes Feedback. Was ist aufgefallen? Mitschreiben, während dem Testing mitschreiben oder eben auch wirklich aufnehmen. Stolpersteine, die bei mehreren Tests dann aufgefallen sind, solltet ihr ernst nehmen. Und Stärken und Schwächen, wirklich so eine Pro- und Kontraliste machen. Was ist gut, was ist negativ und das aus dem System dann ausmerzen.
Links, Usability-Testessen. Das ist das, was ich schon angesprochen hatte. In jeder größeren Stadt kann man kostenlos daran teilnehmen. Gerade dadurch, dass es kostenlos ist, ist es natürlich gerade hier auf der Foskes wahrscheinlich auch sehr willkommen, dass man da einfach mal Software nehmen kann, durchtesten kann
und keine zigtausende einfach noch mal in Testing investieren muss. Ja, danke für eure Aufmerksamkeit. Ich hoffe, es hat euch gefallen. Gibt es noch Fragen?
Danke für den Vortrag. Ich schließe mich an, gibt es Fragen? Ja. Ich habe eine Frage dazu, was ist, wenn man ein Projekt hat für irgendeine Funktionalität
und es gibt bereits etablierte Konzepte. Ist es nicht so, dass man irgendwie automatisch den Marktführer folgen muss oder diese Gewohnheiten, die die Leute schon von Google, Microsoft und X... Also Menschen adaptieren natürlich sehr, sehr schnell. Deswegen ist es natürlich gut, zum Beispiel einen Blick auf Google Maps oder Ähnliches zu haben,
um zu sehen, was ändern die vielleicht. Die machen ja auch viele große Testings im Hintergrund, was da alles mitläuft, könnte dann natürlich relevant sein. Ansonsten, wenn man natürlich schon Aufzeichnungen hat über Dinge, die gut funktionieren oder so etwas, dann sollte man die auch nicht verändern. Ansonsten hilft es auch mal, irgendwie eine Zweitversion zu machen,
wo man zum Beispiel einfach nur Buttons tauscht oder so etwas. Oder irgendwie eine Legende auf die andere Seite packt und einfach guckt, wie die Zugriffszahlen zum Beispiel sind. Oder man bietet optionale Möglichkeiten an. Zum Beispiel, dass man sagt, ok, du kannst dir jetzt selber etwas auf den Bildschirm verschieben, von links oder nach rechts oder von oben nach unten.
Anpassbarkeit zum Beispiel anbieten. War das das, was du wissen wolltest? Also ich denke, bei neuen Sachen habe ich ja recht viel Freiheit, wenn ich der erste Winner das mache. Also ist es sinnvoll, sich anders zu verhalten als andere Software, die schon etabliert ist?
Also da sagst du etwas, das würde ich ernsthaft testen. Ich würde gucken, was die Nutzer erwarten. Weil natürlich kann etwas etabliert sein. Das kann richtig sein, muss es aber nicht. Bestes Beispiel ist zum Beispiel Word, hat man den Speicherbutton von der Mitte schräg oben
einfach auf die rechte Seite gestellt, weil sie dachten, den benutzt eh keiner. Dann aber gab es einen riesigen Aufschrei, Supportaufkommen und so weiter und so fort. Dementsprechend hat man ihn wieder zurückgemacht. Gleichzeitig kennt man das aber zum Beispiel von Otto, die zum Beispiel 20 verschiedene Speicherbuttons hatten und die irgendwann einfach auf einen geändert haben, auf Otto.de.
Und das dann vereinleitlicht hatten und dadurch weniger Absprungraten hatten. Ich denke, es ist vieles mit Testing einfach mal zu gucken oder eben auch Bestätigung zu holen. Dass du vielleicht sagst, ich mache jetzt mal ein Testing mit oder ich gucke, welche Software ich bräuchte, führe das selber durch
und dann einfach mal zu gucken, ist das Etablierte das Richtige oder kann man es nicht neu vielleicht besser machen und einfach nur, indem man vielleicht drei Sachen umstellt. Eine weitere Frage hier und dann vorne.
Ich hätte eine Frage zu den fünf Nutzern. Brauche ich nur fünf Nutzer oder brauche ich die fünf richtigen Nutzer? Eigentlich brauchst du einfach nur fünf Nutzer. Die richtigen Nutzer gibt es nicht. Natürlich ist es vielleicht relevanter, wenn du deine Zielgruppe ansprichst oder dort eben auch bleibst. Ansonsten ist es eben so, dass der Mensch an für sich immer ähnlich reagiert.
Also auch Dinge, die man vieles beim Testing, also beim Vortesting zum Beispiel, wenn man das einfach selber macht oder sich austauschen mit Kollegen, die zum Beispiel schon eine vorgefestigte Meinung haben, erwarten die Dinge an einer anderen Stelle als vielleicht Leute, mit denen man nichts zu tun hat. Daher habe ich aus meiner Erfahrung mitnehmen können,
die fünf Tester sind super. Dass man vielleicht zwei, drei Monate später nochmal hingeht und nochmal sich fünf Tester holt und damit nochmal durchguckt, ob die Schwachstellen jetzt raus sind, das funktioniert meistens.
Ich hätte vielleicht noch eine Anmerkung zur Frage davor. Aus unseren Erfahrungen heraus, ja, man kann sich sehr deutlich von dem etablierten Back bewegen, denn Usability, und das passt jetzt nicht ganz so dazu, aber in dieser sperrigen Risonorm, die es zu Usability gibt, ist ganz eindeutig beschrieben, dass da immer das Ziel
und auch der Nutzungskontext mit berücksichtigt werden muss. Und wenn der Nutzungskontext nicht Google Maps-like ist, dann darf man sich auch von Google Maps oder von den Mappen ja vielleicht sehr, sehr stark entfernen. Also man darf auch neue Konzepte entwickeln, sonst würde man ja gar nicht weiterkommen. Das so als Anmerkung zur Frage davor. Mich hat so ein bisschen hellhörig gemacht, dass du gesagt hast,
das Sinking allowed findest du super. Wir haben die Erfahrung gemacht, dass es unsere Probanden total irritiert, dass viele sich mehr in eine Prüfungssituation versetzt fühlen, darüber nachdenken, was sage ich jetzt,
dadurch behebiger handeln und gar nicht so dieses spontane, ich schlage mir die Hand an den Kopf, was ich mir mitnotieren kann, aber jetzt nicht bewusst abgefragt habe oder so. Mist, wo ist denn jetzt der Button, dass ich das nicht so spontan erhalte, wenn ich bewusst sage, bitte kommentiert jeden Schritt, den ihr macht.
Also ich habe die Erfahrung gemacht, wenn ich distanziert rangehe, reagiert mein Gegenüber auch so. Deswegen habe ich vorher immer Smalltalk. Hallo, ich bin Lina, ich mache das und das. In meiner Freizeit mache ich CrossFit. Kennst du CrossFit? Hey, lass uns das und das mal durchspielen oder hier das. Darf ich dir das mal kurz vormachen oder hier oder da?
Das bedeutet, die lernen mich binnen fünf Minuten unglaublich persönlich kennen und öffnen sich mir gegenüber. Da braucht man natürlich jemand relativ Kommunikatives. Und danach haben die eigentlich alle gar keine Berührungsängste mehr, weil ich dann sage, hey, hast du jetzt einfach mal Lust? Machste, falsch machen kannst du eh nichts, komm, tu mal.
Und dadurch ist das Eis gebrochen. Die sind in keiner Prüfungssituation, sondern rasen einfach durch und haben Bock drauf. Gibt es weitere Fragen? Wir hätten noch Zeit für eine Frage. Zwei sogar, wir müssen mal gucken, wie es hinpasst.
Ich habe es jetzt erst gesehen. Ja, meine Frage ist einfach zum Zeitaufwand. Also wenn ihr so Usability-Testings macht, was braucht es an Vorbereitungszeit? Wie viel Zeit muss man einladen, um so einen Test durchzuführen? Und für die Auswertung?
Und gibt es verschiedene Iterationsstufen vielleicht? Ja, also man kann das im Prinzip ab Anfang an über das Prototyping mit einbauen, ist aber natürlich relativ zeitintensiv. Aber erschlägt man im Prinzip schon die Dinge, die am Anfang auftreten können. Also das bedeutet, es schleicht sich nicht irgendwas Falsches ein,
was gut ist. Ansonsten natürlich, wenn man jetzt so ein Usability-Testing macht, also jetzt an der Think-A-Loud-Methode, würde ich sagen, Vorbereitung ist so, wenn man es im Team macht, vielleicht so einen halben Tag einfach nochmal sagt, okay, gibt es da schon Feedback, was wir haben? Oder müssen wir uns jetzt selber einfach was ausdenken, weil wir noch nichts haben?
Und dann eben zu sagen, okay, wir gehen jetzt zum Beispiel beim Usability-Test essen, das ist von 19 bis 22.30 Uhr, glaube ich. Und da hat man auch 6 bis 12 Tester. Und danach eben die Auswertung. Die Auswertung ist dann meistens nochmal das, was am längsten dauert, wenn man nichts vorgefertigtes hat,
wo man schon sagt, okay, wir haben folgende Probleme, die wir nochmal analysieren möchten und verstärken möchten, ob die wirklich da sind. Dann ist das wahrscheinlich relativ einfach auszuwerten. Dann geht man hin und sagt, okay, das sind die vier Hauptprobleme, die merzen wir jetzt aus und gucken mal, was danach passiert. Wenn man das nicht hat, dann braucht man gegebenenfalls
auch schon so eine Stunde, naja, oder auch einen Tag, um wirklich die Listen anzufertigen und zu gucken, was hat die höchste Priorität, was ist uns selber wichtig, wo stolpern wirklich die Nutzer drüber? Eine kurze Frage noch vielleicht.
Ja, meine Frage ging auf das auch erwähnte Eye-Tracking. Gibt es da irgendwie eine Software, die zu empfehlen ist, oder das ist ja doch ein eher technischer Ansatz? Das ist ein sehr, sehr technischer Ansatz, aus der Richtung, wie ich es bisher mitbekommen habe. Wir haben hauptsächlich mit Firmen zusammengearbeitet, die ihre Testprobanden hatten und die dann eben,
wir haben dann nur gesagt, Software, wir möchten folgendes testen. Testszenarien hatten wir, glaube ich, ein-, zweimal oder so mitgegeben, aber ansonsten einfach nur Software-Testing. Daher habe ich da jetzt nicht so die hohe Schnittstelle zu. Aber gleich der nächste Vortrag ist ja genau darüber. Ich denke, dass die wirklich noch mal was dazu sagen können,
was das Beste in dem Rahmen ist. Gut, ich danke noch mal Lina bitte für den Vortrag und auch für die Diskussion. Vielen Dank. Danke.