Transcript
Anja Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja und in der heutigen Folge hört Ihr die Aufzeichnung des UX und Accessibility Panels vom INNOQ Technology Day vom 30. November 2022. Viel Spaß!
Anja Hallo und herzlich willkommen zum UX und Accessibility Panel. Das hier ist eine Session, in der Ihr eure brennenden Fragen im Chat stellen könnt, bei Vito zum Thema UX und Accessibility und vor allem über deren Zusammenhänge. Das ist nämlich auch sehr spannend. Das sind so Themen wie Accessibility als besondere Charakteristik der Usability, methodisches Vorgehen, die Erfüllung psychologischer Bedürfnisse, Prototyping und auch der Nutzungskontext des Produkts. Und wir haben dazu zwei Gäste eingeladen, Sven und Andreas. Andreas, stell dich doch mal vor.
Andreas Hi, ich bin Andreas. Ich bin seit ungefähr 14 Jahren inzwischen bei dem Thema User Experience dran. Damals noch Usability bzw. da ging es um den Übergang, das kann man gar nicht so genau sagen, aber um die Unterschiede zwischen Usability und UX. Warum braucht man überhaupt UX als Ergänzung der Usability? Und UX war dann auch mein Promotionsthema und mein zweites Steckenpferd quasi ist die Accessibility und dann war es einfach naheliegend die beiden Dinge zu kombinieren, was aber auch sehr einfach ging. Wir kommen darauf noch zurück.
Anja Ja, ich weiß, dass Sven in erster Linie hier ist, weil er neulich mal über UX gestolpert ist. Sven, stellt du dich doch mal vor.
Sven Hallo, ich bin Sven Johann, Consultant bei der INNOQ. Ich bin kein UX Experte, bin eher Backend Developer, aber ich habe schon in meiner täglichen Arbeit ziemlich viel mit UX zu tun. Sei es UX im allgemeinen Vorgehen, AB Testing, Nutzerverhalten verstehen und auswerten, aber auch manchmal so bei Accessibility Gesetze, ganz andere Themen sogar, Performance und Verfügbarkeit aus UX Sicht. Aber auch Developer Experience. Developer sind eigentlich auch nur User. Developer Experience, was APIs und Infrastruktur angeht. Ich habe meine Fragen dabei an Andreas, aber ich halte mich zurück, weil ich kann Andreas immer fragen. Daher, stellt mir ruhig eure Fragen. Und wenn gerade nichts kommt, dann stelle ich meine Fragen.
Anja Gut, dann schauen wir mal. Bisher gibt es noch keine Fragen. Ich denke, Andreas, du wolltest noch mal kurz über die Grundlagen gehen, damit wir erst mal eine Basis haben.
Andreas Richtig, als kurze Einführung, gerade was den Zusammenhang angeht. Wir haben bei der User Experience schon gesagt, wir haben alles, was mit der Erfahrung, mit dem Erlebnis zu tun hat, das irgendeine Interaktion mit Produkten bei uns auslöst. Und in der Informatik reden wir immer über Information, Informationsgewinn, Informationsvermittlung. Damit wir Informationen vermitteln können, müssen die Informationen zugänglich sein, accessible. Und das ist ganz wichtig. Accessibility hat nichts mit Behinderten zu tun und auch nichts mit einer ganz kleinen Gruppe, die man vielleicht vernachlässigen kann, sondern bei Accessibility geht es darum, Informationen wahrzunehmen. Und man kann eigentlich sagen, Accessibility zieht sich durch die komplette Customer Journey, durch die User Journey und wir sprechen mit den Informationen, die unser Produkt vermittelt, einfach die Leute ganz früh schon an. Wie wecken wir Interesse? Wie machen wir überhaupt darauf aufmerksam, dass es das Produkt gibt? Wie erkennt ein Nutzer, was man mit dem Produkt tun kann, wie man damit interagiert, was die Änderungen in der Welt quasi sind? Wie ist der aktuelle Zustand? Und wie stark er sich auch an die Interaktion und das Produkt selbst erinnern kann. Und das ist ein ganz großes Thema, auch im Bereich Usability. Es geht am Ende darum, die Accessibility zu steigern, um auch die gesamte Gebrauchstauglichkeit zu erhöhen. Und das ist ein großer Zweig der User Experience, dieser ganze praktische Teil. Der andere große Zweig ist der emotionale Part, der psychologische Part, der sich um die Bedürfnisbefriedigung der Nutzer kümmert. Und die haben wir tatsächlich vom ersten Moment an, wenn wir mit dem Produkt irgendwie in Berührung kommen. Und wir haben ihn, diesen emotionalen Part, auch lange, nachdem wir mit dem Produkt interagiert haben. Es geht auch um die Zeit zwischendrin, um die tatsächliche Interaktion. Aber eigentlich ist das, wenn es um User Experience geht, vielleicht der am wenigsten relevante. Es geht vor allem um die Zeit vorher und um die Zeit danach. Und die eigentliche Interaktion ist eigentlich nur das, was uns dazu bringt, darüber nachzudenken und Emotionen aufzubauen. Ich hoffe, der Zusammenhang ist in der Kürze irgendwie verständlich geworden. Aber wie gesagt, stellt die Fragen dazu und ich rede gerne weiter darüber.
Anja Bisher gibt es noch immer keine Fragen. Sven, du hast doch ein paar Fragen mitgebracht, oder?
Sven Genau. Vielleicht die erste Frage, die passt ganz gut zu deinem Punkt Customer Journey. Was kann ein Nutzer mit dem Produkt tun? Da denke ich immer so automatisch an Requirements Engineering. Wo ist eigentlich der Unterschied zwischen User Experience und Requirements Engineering? Unterschiede und Gemeinsamkeiten.
Andreas Wir haben immer ganz verschiedene Arten von Anforderungen. Anforderungen an das System. Anforderungen auf rechtlicher Seite. Marktanforderungen. Was bei User Experience am wichtigsten ist, sind die Nutzungserfahrungen oder Nutzungsanforderungen. Und auch hier haben wir immer noch einen breiten Bereich an Nutzungsanforderungen, die bedacht und erfüllt werden müssen. Und daraus ergeben sich dann wieder neue Systemanforderungen. Da spielt wieder alles zusammen. Aber wir konzentrieren uns bei der UX auf den Nutzer und das sind Anforderungen.
Sven Wo ist dann der Unterschied zu Usability? Mal wieder Unterschiede und Gemeinsamkeiten.
Andreas Ich habe schon versucht zu erklären, dass die Usability ein ganz großer Bestandteil der UX ist. Wenn ich ein System nicht nutzen kann oder auch nicht zu den Zielen komme, für das das System eigentlich da ist, dann brauche ich über den emotionalen, psychologischen Part der UX eigentlich gar nicht zu sprechen. Auch wenn wir es schaffen würden, eine positive UX zu erzeugen, auch wenn das Produkt schlecht ist. Aber das ist eine Ausnahme. Die Usability ist ganz entscheidend. Nutzer erwarten das aber mittlerweile auch einfach. Ich will kein Produkt mehr nutzen, mit dem ich nicht gut arbeiten kann. Das keine hohe Ease of Use hat zum Beispiel. Deswegen ist dieser emotionale Part einfach viel entscheidender inzwischen. Die Usability sollten wir alle immer berücksichtigen. Manche schaffen es immer noch nicht, die Usability so bereitzustellen, wie sie erwartet wird. Wenn ein Produkt eben diese Usability nicht aufweist, ist es ganz schwer, positive UX zu erzeugen. Und deswegen ist da der Zusammenhang groß, aber bei Weitem nicht das einzige, was wichtig ist bei der UX.
Anja Ich habe da tatsächlich auch mal eine Frage. Ich weiß nicht, ob das dazu passt, aber mir ist gerade eingefallen, aus der Praxis heraus sehe ich auch öfter, dass wir als Entwicklungspersonen sagen: Wir wollen unbedingt Nutzungstests haben, wir wollen das den späteren Nutzerinnen mal vorführen und validieren, ob das Feature, so wie es gebaut ist, überhaupt nutzbar ist oder begeistert. Und es wird immer gesagt: Ja, das wollen wir auch machen, aber es fehlt entweder an Zeit oder Geld. Aber das Wichtigste ist, es fehlt meistens an Probanden. Wie kann man dieses Problem lösen?
Andreas Wir haben sogar vorab noch das starke Problem, auf das wir immer wieder stoßen, dass nämlich Auftraggeber oder Entwickler im Team oder Teamleiter denken, sie würden die Nutzer kennen. Das stimmt in keinem Fall. Wenn wir uns einfach mal überlegen, wir würden mit Freunden über irgendeine Software sprechen oder auch mit Kollegen, wird sich der Eindruck, den wir von der Software haben, immer ändern. Und jeder wird auch seine eigene Vorgehensweise haben, wie man mit der Software arbeitet, eigene Vorstellungen, was die Software ist und was sie tut. Und dann kann man eigentlich nicht davon ausgehen, auch nur einen Nutzer wirklich zu kennen. Damit wir die kennenlernen lernen, hängt ein bisschen davon ab, was es für ein Tool ist, wenn es eins ist für den Alltag, kann man natürlich auch einfach Kollegen mal fragen, was sie davon halten. Auch wenn der Kunde vielleicht nicht will, dass man mit Nutzern redet. Aber bei so einem allgemeinen Tool geht es eigentlich immer. Wenn es ein Spezial Tool ist, wird das Ganze schwieriger und dann ist es eigentlich sinnvoll, erst mal den Kunden oder den Teamleiter davon zu überzeugen, dass es wichtig ist. Und das kann genau so funktionieren, dass man ihm vorhält, warum man den späteren Nutzer einfach nicht kennen kann. Manchmal funktioniert sogar den Teamleiter zu bitten, mal wie ein Nutzer auf dieses Produkt zu schauen. Und schon das funktioniert nicht, weil der Teamleiter und das Entwicklerteam einfach schon so tief drin ist, dass die Vorstellung, was man damit vielleicht als Novize tun kann oder wie das Produkt wahrgenommen wird, nicht mehr möglich ist. Und wir können uns nicht in den Kunden hineinversetzen. Es führt kein Weg daran vorbei, mit Nutzern zu sprechen.
Sven Was hältst du in dem Zusammenhang davon, mit Nutzern zu arbeiten? Zum Beispiel, wenn ich eine Trading Plattform baue, bin ich einfach eine Woche bei den Tradern. Oder wenn ich eine Call Center Applikation baue, sitze ich eine Woche im Callcenter?
Andreas Wir hören immer wieder davon, wie wichtig die Arbeit im Team ist, wie wichtig diese Softskills sind, wie wichtig Zusammenarbeiten ist. Und viele schränken das ein auf das agile Entwicklungsteam mit Entwicklern, POs, Scrum Master, vielleicht noch ein Stakeholder. Was aber hier eigentlich gemeint ist, ist: Arbeite von Anfang an mit den Nutzern zusammen. Hol dir einen Nutzer ins Team, berede jeden Schritt mit diesem Nutzer und mache ganz schnell klar, ob du auf dem richtigen Weg bist oder nicht. Wenn du keinen Nutzer ins Team abgestellt bekommst, dann entweder machst du es tatsächlich so, dass du beim Kunden entwickelst und immer wieder auf die Reaktion schaust. Oder du gehst in regelmäßigen Abständen, zum Beispiel in der Mitte eines Sprints zum Nutzer und lasst ihn mal als Feedback geben, ob das wirklich ist, was er erwartet hat, ob er neue Ideen hat, die immer auftreten, ob sich die Anforderungen geändert haben, was auch immer passiert. Und diese Interaktion oder auch die Zusammenarbeit mit dem Nutzer ist einfach das Ausschlaggebende. Du weißt einfach sonst nie, ob du die Bedürfnisse des Nutzers immer noch erfüllst.
Sven Ja, ich muss sagen, so als alter Sack, der noch von Anfang an bei Xtreme Programming dabei war, hört sich das für mich super an, weil Xtreme Programming hatte auch gesagt, wir brauchen im Team, wir brauchen den Customer on site. Was natürlich immer eine super Idee war und in den initialen Projekten, da hat es tatsächlich den Customer die ganze Zeit on site zu haben, das hat damals nicht so gut funktioniert, wenigstens ab und an. Aber ein Problem ist tatsächlich, da würde ich dir zustimmen: Wie kommst du an die Leute, dass sie die ganze Zeit da im Team sitzen? Das ist natürlich eine große Herausforderung.
Andreas Ja, ich kann das initial sogar verstehen. Aus Kundensicht: Mein Mitarbeiter kann nicht für mich entwickeln, das kostet mich nur Geld. Das stimmt im ersten Moment, das kostet Geld. Aber das, was man damit einspart, ist deutlich höher. Extrem deutlich. Man kann es gar nicht richtig benennen. Aber das, was du dadurch gewinnst. Das geht einfach anders überhaupt nicht.
Anja In meinem aktuellen Projekt ist es so, wir haben auch Nutzungstests angestrebt, nachdem wir sehr lange drüber geredet haben, dass wir das auf jeden Fall brauchen. Und das war auch sehr gut. Und wir hatten den Vorteil, dass es Nutzerinnen waren, beziehungsweise man konnte die Nutzerinnen ansprechen, es waren Kundinnen und konnte sagen: Wir bauen eine neue Software und wir wissen, wir arbeiten schon sehr lang miteinander zusammen. Und das war ein Trending Nutzer. Man kann Trending Nutzer ansprechen und es sind eine Handvoll, mit denen man eine bestimmte Beziehung hat. Und die sind dann eher bereit teilzunehmen an dem Prozess, diese Software zu verbessern.
Andreas Ja. Es ist auch durchaus üblich, Leute zu bezahlen, damit sie an deinen Tests teilnehmen. Auch das ist vor allem dann nützlich bei einer Software, die einfach im Alltag auch eingesetzt werden kann. Von einer breiten Nutzerschaft, wo du keine Expertennutzer dafür brauchst. Bei einer anderen Software, wo du Experten brauchst, geht das auch. Aber der Kreis an potenziellen Testern ist deutlich kleiner. Und je geringer deine Nutzerschaft ist, desto mehr musst du eigentlich auch bezahlen. Und je höher qualifiziert die sind, desto schwieriger ist es, die zu kriegen. Was wirklich wichtig ist, dass sie im normalen Job zur Verfügung stehen.
Anja Wollen wir über das Thema Nutzungstest weiterreden? Ansonsten haben wir eine Frage im Chat.
Andreas Ja, dann gerne den Chat.
Anja Ich lese vor. Dirk hat die Frage gestellt, oder eine Anmerkung. Ein sehbehinderter Mensch hat eine andere Anforderungen an eine Software als blinde Menschen. Schriftgröße, Kontrast, Screenreader. Desktopanwendungen erfordern andere Anpassungen als Anwendungen im Webbrowser. Gibt es ein Best Practice für Accessibility, was unterschiedliche Entwicklungstechnologien angeht?
Andreas Wir haben eigentlich grundsätzlich den Auftrag oder auch aus meiner Sicht die Pflicht, von Anfang an auf die Accessibility zu schauen. Dass die Kontraste hoch sind zum Beispiel. Das ist einfach etwas, dass nicht nur Leuten mit Sehbeeinträchtigungen hilft, sondern eben allen, die die Software in unterschiedlichen Umgebungen benutzen wollen. Wir müssen auch an die alten Leute denken und an uns selbst, die wir auch irgendwann alt werden. Und wir müssen einfach sehen, dass es ganz wichtig ist, über Kontraste klar zu machen, wo ist in meiner Anwendung ein Text? Welche UI Elemente gibt es? Es geht bei dem Kontrast nicht nur darum, Text gut lesen zu können. Es geht darum, dass du unterscheiden kannst, wo die UI Elemente aufhören, wo das nächste anfängt, aber eben auch auf einen Blick zu sehen, wo ist denn der relevante Part? Und hier ist es egal, auf welchem System du die Anwendungen laufen lässt und es ist eigentlich egal, für wen du das brauchst. Die Technologie dahinter ist auch egal, solange du dich damit gut genug auskennst, um diese Kontraste herstellen zu können.
Anja Okay. Das heißt, du hast die Frage damit beantwortet. Die Technologien sind eigentlich egal, solange es zum Ziel führt.
Andreas Genau. Ich weiß nicht, ob das wirklich mit Technologien gemeint war, aber welche Programmiersprache ich verwende, ist egal. Welche IDE ich verwende, ist egal. Und ob ich eine native App verwende oder eine Web-basierte App ist auch egal. Es kommt auf die UI an, man sagt, das UI ist für den Nutzer das Produkt. Alles andere ist egal.
Anja Das User Interface, es muss nicht unbedingt eine grafische Oberfläche sein, aber das User Interface. Ich habe neulich in einem Onlineshop einen Button gesehen, da stand drauf 'Enabled Accessibility’. Ich habe mich gewundert, was da passieren würde. Ich habe da drauf gedrückt und augenscheinlich in dem grafischen Nutzungs-Interface ist da irgendwie nichts passiert. Und ich habe dann auch mal die Kolleginnen gefragt, die meinen: Ja, das ist so ein besonderes Tool, das verbessert automatisch die Accessibility. Was ist denn deine Meinung zu solchen Tools?
Andreas Das hängt natürlich davon ab, was diese Buttons tun. Wenn du als nicht beeinträchtigter Mensch nichts erkennst was sich ändert, dadurch, dass du den Button drückst, dann ist es vielleicht auch die Frage, warum dieser Modus nicht einfach standardmäßig aktiv ist. Viele haben Angst, wenn man sich um Accessibility kümmert, dass man weniger kreativ sein kann, dass man nicht mehr schicke Designs umsetzen kann. Aber wenn man durch die Aktivierung eines Modus einfach keinen Unterschied erkennt, was ganz oft so ist, dann beeinträchtigt Accessibility nur in ganz wenigen Fällen das Aussehen. Dann kann man doch auch einfach sagen: Ich habe standardmäßig diesen Modus aktiviert und dann decke ich die Anforderungen von allen möglichen Nutzern ab, die mit meiner Software arbeiten wollen. Ich verstehe diese Unterscheidung oder den Grund nicht, warum man solche unterschiedlichen Modi anbieten wollen würde.
Anja Ja, genau das habe ich auch nicht verstanden. Wenn wir bei den Tools bleiben. Es gibt ja auch noch andere Tools, die meine Software oder meine Webseite analysieren und mir von einer Skala von 0 bis 100 zeigen, wie gut die Webseite angepasst ist oder auf Accessibility hin programmiert wurde. Hast du da ein paar Empfehlungen oder Erfahrungen, die du teilen kannst?
Andreas Um noch mal kurz zurückzukommen, fällt mir gerade ein, wenn ich diese Erfahrung mache, diese UX erhalte, dass ich erst auf den Button drücken muss, um mit der Seite interagieren zu können, dann ist die UX schlecht. Und eine schlechte UX ist viel schlimmer als eine, die nur ein bisschen positiv ist. Eine positive wandelt sich irgendwann in eine neutrale UX. Deswegen ist es wichtig, da immer mal wieder drauf zu schauen. Eine negative UX bleibt negativ und sorgt vielleicht dafür, dass du Nutzer tatsächlich verlierst oder eben auch keine dazu gewinnst. Entschuldigung, jetzt habe ich deine Frage vergessen.
Anja Kein Problem. Meine Frage war: Es gibt Analyse-Tools, die mir zeigen, wie gut meine Webseite optimiert ist auf Accessibility. Was hältst du von diesen Tools oder kennst du Tools? Kannst du da was empfehlen?
Andreas Oft geschaut wird mit Google Lighthouse. Verschiedene Browser haben diese Funktionen um prüfen zu lassen, wie accessible meine Website gerade ist. Das sind alles Dinge, die vielleicht während der Entwicklung helfen können, keine groben Fehler zu machen. Aber es ist am Ende überhaupt keine Aussage darüber, ob mein fertiges Produkt wirklich accessible ist. An einem Beispiel deutlich gemacht werden kann, dass bei den Alternativtexten diese automatischen Tools erkennen, ob es überhaupt Alternativtexte gibt. Die erkennen aber auf keinen Fall, ob die Alternativtexte zu den Grafiken passen. Und auch wenn das vielleicht manche Tools noch versuchen, durch KI oder durch ein einfaches Mapping zwischen deinen Bildern und welchen, die irgendwo anders schon liegen und vielleicht auch einen Alternativtext haben. Der Detailgrad von deinem Alternativtext und ob der wirklich dazu beiträgt, dass deine spezielle Software besser benutzt werden kann. Dadurch, dass du den Nutzern diesen Alternativtext vermittelst. Das kann kein automatisiertes Tool der Welt. Was du eigentlich immer machen musst am Ende ist ein Test mit einem Nutzer, der darauf angewiesen ist. Du kriegst ungefähr 30% aller Mängel, die insgesamt auftreten können, kriegst du von so einem Tool gesagt. Das sind genau die ganz groben. Und 70% aller Mängel findest du durch diese Tools einfach nicht. Dafür brauchst du einen Nutzer, der dir das Feedback gibt.
Sven Wann ist die Zeit für so was? Ich denke, in so einem Projekt haben wir natürlich immer einen Haufen. Priorisierung ist natürlich immer ein Problem, wenn ich mich um UX kümmere, da ist irgendwie klar: So ein PO gibt UX immer sehr viel. Offensichtlich ist das sehr wichtig, das versteht jeder. Und das wird priorisiert angegangen. Es gibt auch noch so andere Qualitätsmerkmale Security, Wartbarkeit, Performance, Zuverlässigkeit und weiter. Da muss Accessibility mit konkurrieren. Wie siehst du das? Wie kann ich das einsortieren? Wie ist der Kosten- und Nutzenaufwand, wenn ich Accessibility angehen will?
Andreas Das will ich eigentlich nicht beziffern. Wir haben inzwischen auch immer mehr Kunden, die Software genau deswegen kaufen, weil man sich um Accessibility bemüht hat. Weil eine Firma ehrlich auftritt als jemand, dem Accessibility wichtig ist. Da gehen Kunden hin, auch wenn sie selber nicht betroffen sind. Aber sie finden das gut und richtig, moralisch und sozial gesehen richtig. Da gibt es auch Studien drüber. Und allein der Aspekt sagt schon, dass man es eigentlich nicht vernachlässigen darf, sich um Accessibility auch möglichst früh zu kümmern. Während der Entwicklung schon immer mal wieder von mir aus diese automatisierten Tools einsetzen, um zu schauen, ob man grobe Fehler gemacht hat und hinterher tatsächlich mit Nutzertests zu arbeiten, Leute dran setzen, die es brauchen. Und das kannst du dann machen, wenn du zum Beispiel ein MVP hergestellt hast. Das geht sogar mit einem POC, Proof of Concept. Da musst du dich allerdings daran halten, dass du die Konzepte, die dort vorgestellt werden, auch hinterher in die Produktivversion bringst. Weil es bringt nichts damit zu testen und ein gutes Feedback einzuholen, wenn du hinterher die Hälfte wieder wegwirfst.
Anja Es sammeln sich tatsächlich einige Fragen im Chat. Ich versuche sie einmal ein wenig zu sortieren, damit wir eine gute Reihenfolge hinbekommen. Ich werde sie jetzt nicht chronologisch vorlesen. Die erste Frage, die ich ausgesucht habe, ist folgende: Möglicherweise ging es beim genannten Button im Shop der sogenannte Accessibility Overlays und KI. Diese kleine JavaScripts, dass dieses große Wunder vollbringt, davon wäre meiner Meinung nach abzuraten, sagt diese Person.
Andreas Diese Buttons kenne ich auch nicht. Aber ja, Wunder sollte man bitte vermeiden und auch Leute zu überraschen. Überraschung ist schön und gut, aber eher im Gaming Bereich als hier, wenn es um Usability geht. Überraschung funktioniert auch nur genau einmal, wenn man weiß, dass irgendwas passiert, wenn ich einen Button drücke, entweder erwarte ich das und mag das, was da passiert oder ich mags eben nicht. Und das zieht sich dann durch, durch die ganze Software. Ich mache einen Fehler, vielleicht als Entwickler mit einem einzigen Button und ein Nutzer findet die ganze Anwendung schlecht.
Anja Dann gibt es hier noch zwei Anmerkungen, die ziemlich ähnlich sind. Ich werde sie nacheinander vorlesen. Tim sagt zum Beispiel: An der Uni wurde mir damals noch die ISO 9241210 eingebläut: Grundsätze der menschzentrierten Gestaltung. Finden die Ansätze bei euch im Alltag Einzug in die aktive Entwicklung? Und eine andere Frage, die ziemlich ähnlich ist, ist: Wie ist eure Erfahrung im Consulting Alltag? Muss man für Usability, Accessibility stark kämpfen oder geht der Trend eher in Richtung, dies vermehrt mitzudenken? Zu der ersten Frage wenden wir eigentlich diese DIN ISO Norm an, die wir damals in der Universität gelernt haben?
Andreas Für mich sind diese ISO Normen wichtig, weil sie einfach den Standard für das geben, was wir einfach standardmäßig tun wollen und womit wir auch Kunden zeigen könnten, warum das wichtig ist. Weil sich da viele Leute schon viele Jahre lang Gedanken drüber gemacht haben und das eben aufgeschrieben haben als Nonplusultra für die Basisversion. Die 9241210 ist die, in der User Experience definiert wird und in der auch der Designprozess quasi erläutert wird. Der besteht aus vier Schritten. Die kann ich gerne noch erläutern, wenn Fragen dazu kommen. Für die Accessibility gibt es das übrigens auch. Da ist es nicht die 210, sondern die 171. Und da wird auch ganz klar gesagt, dass es nicht um Behinderte geht oder um Leute, die einfach wirklich darauf angewiesen sind. Es geht um alle Nutzer, die einfach davon profitieren durch höhere Accessibility. Und leider ist es tatsächlich noch so, dass wir kämpfen müssen, dass Accessibility mit berücksichtigt wird. Das kostet natürlich auch ein bisschen Geld, aber diese Norm, dieser Standard hilft auch dabei. Zum einen können wir besser erklären, worum es eigentlich geht. Zum anderen haben wir was in der Hand, wo wir sagen können: Hier, schau rein, das ist so definiert. Wir erklären die hier kein Quatsch oder irgendwas, womit wir dich einfach überzeugen wollen, sondern es ist standardisiert. Wir haben das eigentlich als Grundsatz für unsere Arbeit. Aus unserer Sicht müssen wir uns um die kümmern. Das machen wir auch. Da muss nicht diskutiert werden. Man muss das nicht extra beauftragen. Wenn wir entwickeln, kümmern wir uns um Accessibility, weil es einfach wichtig ist und nicht viel mehr Arbeit kostet. Wenn wir früh genug damit anfangen in unserer Entwicklung ist der Kostenaufwand sehr gering. Wenn wir erst spät anfangen und merken: Oje, oje. Hier sind viele Accessibility-Mängel oder hier kommen jetzt viele Beschwerden von Nutzern, die auf Accessibility angewiesen sind, dann kann das echt kostenintensiv sein, die Überarbeitung. Wir könnten merken, dass das kaum machbar ist und wir eigentlich die Anwendungen neu entwickeln müssten. Das ist halt der Supergau. Kann aber durchaus vorkommen.
Anja Das bedeutet aber auch, du würdest jetzt nicht in einem Kundenprojekt sagen: Lieber Kunde, liebe Kundin, wir müssen uns jetzt um die Accessibility kümmern, sondern würdest von Anfang an Accessibility in deine Arbeit mit einfließen lassen und erst gar nicht draufkommen, aktiv danach zu fragen, ob wir das jetzt machen sollen?
Andreas Ja, ja, es ist so ein großer Bestandteil der Usability. Usability will jeder. Das verstehen auch Kunden, das fordern Kunden auch ein. Da muss man nicht darüber reden, was alles zur Usability gehört. Wir machen das, was auch standardisiert wurde in der ISO. Dazu gehört eben auch Accessibility genauso wie zum Beispiel die leichte Erlernbarkeit oder die Vermeidung von Fehlern. Das sind Dinge, da würde jeder zustimmen. Ja, wir wollen das haben, bei Accessibility sind wir da leider noch nicht so weit auf Kundenseite, aber es wird besser.
Sven Ich erinnere mich in dem Zusammenhang noch an: das priorisieren wir runter. Auch wenn wir Strafe zahlen müssen, weil in manchen Ländern wie Kanada, wenn du nicht accessible bist, dann kostet das Geld. Aber da haben die trotzdem gesagt: Machen wir nicht.
Andreas Das kostet viel Geld in den USA auch. Da kannst du dich beschweren, auch vor Gericht gehen und das einklagen als Betroffener. Und du bekommst Recht. Und wie man das so kennt aus den USA sind die Strafen echt hoch. Dominos Pizza ist da ein gutes Beispiel. Die haben echt Millionen Dollar bezahlt als Bußgeld, weil ihnen das lieber war, als die Anwendung zu überarbeiten. Die sagen nach wie vor: Wir kümmern uns nicht um Accessibility, wir zahlen lieber die Strafen. Das verstehe ich nicht. Aber es gibt Firmen, die so vorgehen.
Sven Ich würde es tatsächlich verstehen, wenn man sagt, unsere Opportunitätskosten sind größer, weil Geld, was wir investieren, investieren wir in andere Dinge. Oder die Kosten sind einfach zu hoch und die Strafen sind niedriger. Das wären die einzigen Motivationen, die ich gut nachvollziehen kann.
Andreas Wie gesagt, die Kosten sind nicht hoch. Wenn du früh Accessibility berücksichtigst in deiner Entwicklung. Die steigen, je später du damit anfängst. Die Kosten sind aber dann auch hoch, wenn du später merkst, dass du Nutzer verlierst.
Anja Es gibt noch weitere Fragen im Chat, von Marc. Stimmt es, dass zu lange Alt-Texte auch hinderlich sein können? Ich frage, weil ich immer dachte, es sei gerade vorteilhaft, eine detaillierte Beschreibung zu verwenden.
Andreas Die sind nachteilig, genau. Bei den Alternativtexten geht es überhaupt nicht darum, alle Details von Grafiken zu beschreiben, noch nicht mal bei Diagrammen. Da denkt man vielleicht Diagramme, Statistiken sind total wichtig, dass du die vollumfänglich in einem Alternativtext beschreibst. Aber wenn du einen langen Alternativtext brauchst, heißt das eigentlich, dass du diesen Text irgendwo in deinem normalen Content unterbringen solltest, weil das wahrscheinlich jedem hilft, irgendeine Grafik besser zu interpretieren. Und wenn du dir vorstellst, dass du mit einem Screenreader zum Beispiel Zeile für Zeile liest und dann kommt so ein langer Alternativtext, das ist völlig rausgerissen aus dem normalen Content, der dich eigentlich interessiert. Und dann wartest du eigentlich nur darauf, dass der Alternativtext endlich endet, weil du schnell verstanden hast, worum es geht. Oder weil dich die Grafik im Moment überhaupt nicht interessiert. Weil du vielleicht erst mal wissen willst: Was kommt in dem Text noch? Ist der Text insgesamt für mich immer noch spannend? Wenn du wirklich Alternativtexte lang schreiben willst, gibt es diese langen Beschreibungen extra als Feature von HTML, Long Descriptions. Die kann man einsetzen. Dann ist der Alternativtext erst mal kurz und du hast die Möglichkeit auf einen Link zu klicken, um dir die Langbeschreibung anzeigen zu lassen. Ich persönlich mache das so gut wie nie. Weil es einfach in den allermeisten Fällen überhaupt nicht nötig ist. Es ist eine Art von Kunst, gute Alternativetexte zu schreiben. Das kann auch nicht jeder. Vor allem nicht von Anfang an. Es ist auch sinnvoll, Alternativtexte, die für sich selber gut klingen, einfach mal von anderen testen zu lassen, indem man die Texte vorlegt und dann einfach mal fragt: Wie stellst du dir denn jetzt das Bild vor, das hier beschrieben wird? Du zeigst das Bild gar nicht am Anfang, sondern du lässt dir anhand des Text beschreiben, wie das Bild aussieht. Und auch da geht es nicht darum, dass du alle Details beschreiben kannst. Was jemand anhat zum Beispiel ist vielleicht nur dann sinnvoll oder wichtig, wenn du ein Bekleidungsshop betreibst. Wenn es um Gesichtsausdruck geht, ist es vielleicht nicht so wichtig, was die Person anhat. Es ist wirklich wichtig, die Hauptaussage zu beschreiben und am Ende eigentlich die meisten Details wegzulassen.
Anja Es bedeutet im Grunde, wenn ich jetzt eine Redakteurin bin und einen Artikel schreibe und Alt-Texte verfasse, dann sollte ich mir klar machen: Könnte dieser Text auch im normalen Text stehen? Könnte er dort stehen? Ist es okay? Könnte er dort nicht stehen, weil es gar nicht zur Sache tut? Dann sollte ich es am besten umformulieren oder weglassen.
Andreas Das hängt wieder von der Grafik ab. Gerade bei Statistik, wo ganz viel Information drinsteckt, ist es sinnvoll, den in den Haupttext zu stecken, weil jeder davon profitiert, wenn diese Grafik mal interpretiert wird als Text. Es gehört dazu bei Alternativtexten, die nicht nur zu schreiben, sondern sich zu überlegen auch mit deinen Kollegen zusammen. Warum habe ich jetzt diese Abbildung da eigentlich hingesetzt? Was wollte ich dann als Entwickler oder als Webdesigner damit aussagen? Und wenn hier keine Antwort kommt oder dir fällt es schwer, noch mal nachzuvollziehen, warum die Grafik da ist, dann schmeiß sie raus. Versuch nicht dazu, irgendeinen Alt-Text zu schreiben.
Anja Okay, wir haben noch weitere Fragen im Chat. Ich lese vor, eine Frage von Dirk: Muss man sich bei bestimmten Technologien, WPF, bestimmte Automation IDs setzen, damit Screenreader funktionieren? Wenn man es später machen will, ist es eigentlich nicht mehr möglich. Daher von Anfang an mitfliegen. Ich glaube, es ist nur ein Hinweis.
Andreas Das klingt nach einem Hinweis.
Anja Dann gibt es so eine Frage, ganz praktisch: Wie finde ich Testpersonen, die meine Anwendung auf Accessibility prüfen? Diese Frage habe ich schon am Anfang gestellt. Vielleicht gehst du noch mal darauf ein.
Andreas Es gibt wirklich Unternehmen, die sich nur darauf spezialisiert haben. Die haben einen Pool von Mitarbeitern, die wirklich betroffen sind. Auch ganz unterschiedlicher Art. Blinde, Taube, motorisch eingeschränkte Menschen. Die kriegen dann deine Anwendung vorgelegt. Die testen das auf Herz und Nieren und geben dir dann einen Bericht zurück, was funktioniert hat und was eben noch nicht. Das ist natürlich auch etwas teurer als ein normaler Nutzertest, aber es lohnt sich auf jeden Fall, weil du da so gutes Feedback zurück bekommst, dass du von einem nicht-beeinträchtigten Nutzer einfach nicht bekommen wirst. Du kannst auch versuchen, vielleicht mal auf die Straße zu gehen und jemanden anzusprechen, der offensichtlich beeinträchtigt ist. Du wirst da keine Leute finden, die vielleicht auch kognitiv beeinträchtigt sind oder die einfache Konzentrationsschwäche haben. Aber so offensichtliche Sachen kannst du da machen, wenn du den Leuten zum Beispiel auch mal 50€ dafür gibst.
Anja Ich kann mir vorstellen, dass es da schon eine moralische Hürde, jemanden sozusagen aufgrund von äußeren Merkmalen zu sagen: Hey, wir brauchen jemanden für Accessibility Tests.
Andreas Ist es. Auf der anderen Seite weiß auch jeder Nutzer, dass es ihm selbst hilft. Also wenn ich angesprochen werde, mache ich gerne mit. Auch wenn so eine E-Mail Anfrage kommt von irgendeiner Uni zum Beispiel, die irgendwelche Testpersonen brauchten für eine Anwendung, die auf Accessibility getrimmt wurde. Ich mache gern mit, weil das jedem hilft, auch zu verstehen, warum Accessibility wichtig ist. Und wenn das jemand verstanden hat, dann wird die künftige Software, die dieser Mensch entwickelt, eben auch höchstwahrscheinlich accessible sein. Man muss nicht mehr viel rumprobieren und auf Feedback warten von Nutzern, die sich hinterher beschweren, dass das eben nicht accessible ist.
Anja Eine sehr ähnliche Frage: Gibt es Verfahren? Ich glaube, da geht es um den Fokus Verfahren testen zu können, wie accessible die eigene Anwendung ist. Wahrscheinlich jetzt mal von den Testpersonen an sich abgesehen, gibt es Verfahren?
Andreas Am Ende ist so ein Test kaum anders als ein normaler Usability Test. Eben weil Flexibilität Teil der Usability ist. Wir wollen immer Feedback von den Nutzern haben, egal, ob die beeinträchtigt sind oder nicht. Bei beeinträchtigten Menschen haben wir, vielleicht kann man das nicht unbedingt Vorteil nennen, aber die geben viel heftigeres Feedback, wenn irgendwas nicht funktioniert, weil zum Beispiel irgendein Button nicht auffindbar ist, weil ein Eingabefeld nicht nutzbar ist oder nicht beschriftet ist. Da wird man schnell sauer, wenn man es wirklich braucht. Und so wie andere Nutzer dann bei so einem Test einfach auf Dinge eingehen wie: Mir gefällt das Icon nicht oder ich werde abgelenkt von der Farbe oder wie auch immer. Dann kriegst du von beeinträchtigten Leuten halt eher das Feedback, was sie nicht nutzen können, wo auch der Text vielleicht noch zu klein ist. Welche Animationen stören oder wie auch immer. Du wirst normalerweise sehr viel mehr negatives Feedback bekommen, aber auch gerne Unterstützung, wie man das Ganze besser macht. Auch so richtige Verfahren oder Tests speziell auf Accessibility gibt es eigentlich nicht. Zumindest nicht bei solchen Tests mit Nutzern. Es gibt natürlich Richtlinien, die eingehalten werden sollten. Das ist auch ein bisschen blöd gemacht. Es gibt die Web Content Accessibility Guidelines, denen kannst du folgen als Entwickler und du kannst abprüfen, ob die erfüllt sind oder nicht. Auch da kannst du als nicht betroffene Person aber schwer sagen, ob die wirklich erfüllt sind oder nicht. Jemand, der selber entwickelt hat und diese Tests durchführt und einfach prüft, ob die Richtlinien da sind und erfüllt sind oder nicht, der ist positiv eingestellt gegenüber der eigenen Software natürlich. Und dann sagt man eher mal: Ja, ich hab’s erfüllt, auch wenn da vielleicht ein kleines Problem noch vorherrscht. Das ist aber nicht so ausschlaggebend, dieses kleine Problem. Wenn du wirklich die Nutzer fragst, die davon betroffen sind, dann kann das aus deiner Sicht das kleine Problem zu einem ganz großen Problem werden. Wenn, wie gesagt, also vielleicht ein Teil der Anwendung nicht erreichbar ist über die Tastatur zum Beispiel. Und deswegen ist auch hier wichtig. Es gibt diese Selbstbewertung. Das ist eigentlich Quatsch, weil du als Entwickler nicht selbst bewerten solltest und weil auch eine Handvoll Kollegen oder Freunden das nicht bewerten sollten. Auch hier eigentlich: Nutze betroffene Nutzer, Anbieter, die betroffene Leute zur Verfügung stellen. Man kann auch gerne auf Verbände zugehen, auf Sehbehinderten Verbände, auf Verbände von tauben Menschen, auf Verbände von kognitiv beeinträchtigten Menschen. Am Ende freuen die sich, wenn Anfragen kommen, weil sie merken: Oh, da kümmert sich jemand um unsere Bedarfe.
Anja Ja, genau diesen Hinweis gab es auch im Chat, dass es Verbände gibt, die eine gute Schnittstelle sein können zwischen Entwicklerinnen und Testpersonen. Du hattest gerade gesagt, es bringt nichts, wenn eine Handvoll Kolleginnen das mal testen. Du sagst, eine Handvoll. Braucht man mehr? Wie viele braucht man?
Andreas Wenn es um die Usability und auch um die User Experience geht, brauchst du für dein abschließendes Produkt, für einen echten, statistisch relevanten Test mindestens 20 Personen. Und zwar 20 Personen, mit denen du einzeln testest. Das ist ein Test über vielleicht zwei Stunden. Und dann kommt die Auswertung noch. Du kannst rechnen mit einem halben Tag pro Test. Bei 20 Personen hast du dann zehn Tage Aufwand plus die Überarbeitung, die durch die Anmerkungen nötig werden. Und dann kannst aber auch nachweisen, dass deine Anwendung accessible ist. Vorher bei einem MVP oder bei einem Prototyp oder bei einem Konzept reichen fünf Leute. Da brauchst du auch nicht unbedingt einen echten, aufwendigen Test für den du auch ein Labor brauchst. Da reichen vielleicht einfache Umfragen, das Ausfüllen von Fragebögen. Und dann hast du mal einen Anhaltspunkt, wo höchstwahrscheinlich noch Mängel auftreten. Aber du kannst nicht sagen: Hier habe ich auf Basis von fünf Evaluationspersonen einfach nachweisen können, dass hier keine Mängel mehr bestehen oder dass die Mängel nicht ganz so relevant sind.
Anja Du hast gerade Fragebögen erwähnt. Ich habe schon mal Usability Tests durchgeführt. Ich habe mich damit beschäftigt. Und ich habe auch Fragebögen verwendet. Ich habe aber so eine Mischung benutzt zwischen qualitativen und quantitativen Fragen. Quantitative Fragen, korrigiere mich, wenn ich falsch liege: das sind Fragen, die man auf einer Skala zum Beispiel beantworten kann. Wie findest du folgende Button Farbe? Gut, schlecht? Und eine qualitative Frage wäre: Welche Button Farbe findest du denn für diesen Button gut? Da könnte man sagen: Die und die Farbe beispielsweise, Wann lohnen sich qualitative Umfragen? Wann lohnen sich quantitative Umfragen?
Andreas Es lohnt sich immer beides. Ich finde es wichtig, beides zu mischen, weil du bei quantitativen eben wieder die Möglichkeit hast, quasi berechnet hinterher ein Urteil zu fällen und auch anderen zu zeigen, dass das wirklich das Ergebnis ist, ohne Interpretationsspielraum. Bei qualitativen Fragen und den entsprechenden Antworten hast du immer das Problem, dass du noch mal rückfragen müsstest, ob du das wirklich richtig verstanden hast. Noch mal rückfragen müsstest, welches Wort bei der Person, die geantwortet hat, wirklich was bedeutet. Auch noch mal neue Gruppen wahrscheinlich bilden müsstest von Leuten, die was Ähnliches gesagt haben und vielleicht aber nicht genauso gemeint haben. Es ist bei qualitativen Fragen diese Diskussion, der Austausch untereinander und der Austausch mit dir einfach so wichtig, dass du da darüber viel mehr erfährst. Wenn es dir um eine Gesamteinschätzung geht, sind die quantitativen Fragen einfach die, mit denen du mehr den Überblick bekommst, wie gut es wirklich im Moment ist.
Anja Du hast gesagt Diskussion, das heißt, ich könnte auch einfach Diskussionsrunden mit Probandinnen einberufen. Aber kann es nicht sein, dass sie sich dann beeinflussen und sich gegenseitig hochschaukeln und dann vielleicht Probleme sehen, wo es gar keine gibt?
Andreas Doch. Gerne werden Workshops durchgeführt. Da passiert das oft, dass sie sich schon beeinflussen. Aber es ist wichtig, dass dort eben jeder zu Wort kommt. Du brauchst eine gemischte Gruppe von Anwendern und auch von Entwicklern und auch innerhalb des Entwicklungsteams von verschiedenen Disziplinen, auch Designer, User Experten Requirements Engineers, die alle natürlich ihren eigenen Schwerpunkt setzen und eine andere Sicht auf die Anwendung haben. Und die werden ihre Sicht verteidigen und auch die Dinge, die sie da umgesetzt haben, verteidigen. Und dann werden die Schwerpunkte klar und du kannst als Moderator einfach erkennen, was insgesamt für die Anwendung am wichtigsten ist. Wenn du auf die Usability im Allgemeinen eingehst, wenn du früh in der Entwicklung bist und für dich herausfinden möchtest, welches Konzept du verfolgen willst, dann sind Fokusgruppen gut. Fokusgruppen sind eine geringe Anzahl von Stakeholdern, die mit dem Tool zu tun haben. Und da merkst du, wie die gegenseitig sich beeinflussen. Wichtig hier ist aber, warum es verschiedenen Stakeholdern diese Anwendung so wichtig? Was ist das Ziel? Hier ist auch ganz wichtig, dass die untereinander verstehen, warum es für andere wichtig ist. Damit man nicht denkt: Okay, diese Anwendung ist für mich gedacht, dann ist doch scheißegal, was andere davon denken oder wie die damit umgehen können. Das kannst du in Fokusgruppen sehr leicht rausfinden. Und die sind natürlich auch billiger als Workshops. Du musst die Workshops immer vorbereiten, nachbereiten. Es ist anstrengender, die zu moderieren und bei einer Fokusgruppen kriegst du einfach sehr früh einen guten Überblick, wo auch vielleicht menschliche Probleme existieren unter diesen verschiedenen Stakeholdern.
Anja Sven, was sind deine Gedanken dazu?
Sven Ich überlege gerade. Ich schaue gerade auf meine Performance und Verfügbarkeit und überlege und versuche rauszukriegen, was ist eigentlich eine angemessene Performance und Verfügbarkeit? Ich würde das auch aus UX Sicht sehen, weil wenn eine Anwendung sehr langsam ist, dann macht es einfach keinen Spaß. Wenn die Anwendung lange down ist oder zu oft Fehler wirft, macht es auch keinen Spaß. Wir versuchen herauszufinden, was ist sozusagen Performance und Verfügbarkeit noch gut genug? Kunden sind noch happy damit und das ist natürlich extrem schwer. Aber ich überlege grad. Ich würde auch jetzt einfach Fragebögen schicken an 20 Leute und würde mir erhoffen, dass ich eine gute Antwort auf meine Frage bekomme. Ob die Leute mit der Performance zufrieden sind oder mit der Verfügbarkeit.
Andreas Fragebögen an 20 Leute reicht bei Weitem nicht. Da kannst du nichts am Ende nachweisen. Das gibt keine statistisch relevante Zahl. Du kannst bei Fragebögen froh sein, wenn 10% zurückkommen, die voll ausgefüllt sind. Und eine Schwierigkeit ist, wenn du Leute darauf aufmerksam macht, dass es Performance Probleme geben könnte, dann finden die auch welche. UX ist so subjektiv und jeder hat eine andere Einschätzung von Zeit, dass du hier auch nichts abschließend raus interpretieren kannst. Für den einen sind zwei Sekunden vielleicht ultra lang, für den anderen ist alles gut. Man gewöhnt sich dran oder der macht sich einfach keine Gedanken drüber. Es ist ganz schwer über Performance irgendwelche Aussagen zu treffen. Das hängt auch wieder von der Art der Anwendung ab. Bei einem Browser ist es wichtig, dass die Seite sehr schnell geladen ist, das ist klar. Sonst gehen die Leute weg. Aber wenn es um eine Anwendung geht, die große Mengen von Daten verarbeiten muss, dann ist auch den Nutzern klar, dass es vielleicht mal einen Moment länger dauert. Deswegen gibt es auch überhaupt diese Spinner, oder Fortschrittsbalken. Es ist hier einfach ganz wichtig, dem Nutzer auch Rückmeldung zu geben, was hier gerade passiert und wie lange es ungefähr noch dauert. Dann ist alles okay. Dann kann der Nutzer für sich entscheiden, ob er so lange warten will oder sich vielleicht noch einen Kaffee holt. Oder vielleicht auch eine andere App mal ausprobiert, ob die schneller damit arbeiten kann.
Sven Also das sozu sagen, wie die vergangene Erfahrung eine Art Anker für die Erwartungshaltung ist, erzähle ich auch immer. Wenn ich eine Suche hab oder eine Produkteseite, das muss schnell sein. Aber so einen Checkout Bezahlvorgang ist man halt gewohnt, das macht man nur einmal. Das kann ruhig ein bisschen langsamer sein. Aber das sind natürlich jetzt keine konkreten messbaren Zahlen: wie das ich jetzt 75 der erhofften Nutzer frage. Nehmen wir mal an, ich kriege 20 Antworten. Ich habe 200 Leute gefragt und ich würde doch Tendenzen feststellen. Ich mein, klar, wenn ich die Leute explizit darauf anspreche, sind sie zufrieden mit der Performance, mit der Geschwindigkeit, wie auch immer. Natürlich gibt es Leute, die sagen: Alles ist Mist. Aber ich muss nicht auf alle gucken. Ich muss größere Tendenzen feststellen, wenn 80% sagen eigentlich ist alles gut, hätte ich jetzt erwartet, dass die Anwendung gut genug performt.
Andreas Wie gesagt, wenn die die Frage gestellt bekommen. Die Nutzer sind nicht blöd. Ganz im Gegenteil, die interpretieren oder die versuchen herauszufinden, warum diese Frage gestellt wird und verhalten sich auch entsprechend. Gerade bei richtigen Tests in einem Labormgebung agieren die Leute ganz anders, als wenn sie alleine vor dieser Anwendung sitzen. So ist das beim Fragebogen auch. Und wenn die Leute merken okay, es geht hier um Performance, fangen sie an darüber nachzudenken, wie sie die finden, dann kann es natürlich sein, dass sie auch die Antwort gut geben. Aber wenn sie nicht drüber nachdenken würden, dann wäre es auch überhaupt kein Problem. Es wäre dann ein Problem, wenn die beim Nicht-drüber-Nachdenken schon erkennen würden, dass es viel zu lange dauert. Und auch wenn du am Ende eine Rückmeldung bekommst, wie die Leute das einschätzen, hast du nicht so viel gewonnen, weil dann weißt du okay, ich kann jetzt hier einen gewissen Wert rausziehen. Du wirst aber dann bei einem späteren Test oder bei einer Umfrage wieder Leute finden, die das schlecht finden, die dir sagen es dauert mir zu lang. Ich habe die Erfahrung gemacht, dass es eigentlich von der Performance her kein Optimum gibt. Du kannst versuchen, das so schnell zu machen, wie es technisch möglich ist, aber das kann einfach zu viel kosten.
Anja Kann es dann sein, dass es besser ist, wenn ich solche spezifischen Fragen habe, wie beispielsweise Performanz, dass ich einen Nutzungsest so durchführe, dass die Probanden, sich durch die Anwendung navigieren, Aufgaben erfüllen und dann am Ende wird gefragt; Fandest du die Webseite oder die Anwendung war schnell genug für die Nutzung oder ist das schon zu gefärbt?
Andreas Ist gefärbt. Die übliche Frage ist eigentlich: Kannst du mit dieser Anwendung schneller deine Aufgaben erledigen als ohne? Und da kann man sich zum Beispiel denken; Ich habe hier eine Suche implementiert. Kann man Nutzer jetzt Dinge schneller finden, als wenn er Kollegen fragt? Oder wenn er den Nutzer anruft? Oder wenn er Aktenordner wälzt ganz egal, auch wenn er sein eigenes Excel führt oder wie auch immer. Dann kriegst du eine bessere Rückmeldung, ob die Performance stimmt oder nicht. Und das reicht. Du musst überhaupt nicht wissen, wie lange es dauert, weil darüber macht sich ein Nutzer einfach auch keine Gedanken. Es ist nur wichtig, dass der Nutzer zufrieden ist und das Gefühl hat, dass die Anwendung einfach in irgendeiner Art schnell genug ist.
Anja Wir haben noch ein paar Wortmeldungen im Chat. Ein Hinweis, den lese ich jetzt vor. Christian meinte: Qualitative Methoden sind eher Hypothesen generieren, quantitative Methoden, Hypothesen testen. Optimalerweise macht man erst qualitativ, dann quantitativ, um herauszufinden, was gemessen werden soll. Also es geht um Entdecken der relevanten Dimension.
Andreas Da kann man drüber diskutieren, aber das hier ist der falsche Rahmen dafür.
Anja Okay, gut. Christian gerne bei Andreas melden, da kann man wahrscheinlich drüber diskutieren. Ich glaube, die Zeit haben wir jetzt nicht. Wir haben noch fünf Minuten. Wir haben aber noch eine Frage. Arbeitet ihr auch mit Personas in der Konzeption und Design Phase. Wenn ja, hilft es, manche Fehler und Barrieren in dieser frühen Phase zu vermeiden?
Andreas Personas sind ein Mittel, das wir einsetzen. Es ist unsinnig jetzt für jeden Nutzer, den man sich vorstellen kann, eine eigene Persona zu bauen. Aber man findet mit der Zeit raus, dass es durchaus Nutzergruppen gibt, die die gleichen Anforderungen stellen, auch Nutzergruppen, mit den gleichen Beeinträchtigungen. Und stellt prototypisch für diese Gruppen eine Persona, also pro Gruppe. Der Vorteil von Personas ist, dass du dir immer selber klar machen kannst, für wen du entwickelst, wer hinterher profitiert von dem, was du tust. Ein ganz großes Problem war lange Zeit, dass die Entwickler für sich entwickelt haben und gedacht haben: Geil, das gefällt mir jetzt. Das heißt, die ganze übrige Welt findet das auch toll. Und das stimmt einfach nicht. Wir haben immer Nutzer, die anders denken. Die bei Weitem nicht so tief in der Software drin sind wie wir. Die das auch nicht wollen. Man muss damit einfach arbeiten können. Und warum das so ist, ist den Nutzern doch egal. Personas helfen einfach vor allem dabei, sich immer wieder daran zu erinnern, dass man nicht für sich selbst entwickelt. Eine Beschreibung von Rollen ist ähnlich gut. Du hast hier nicht detaillierte Informationen über die verschiedenen Nutzergruppen wie bei Personas. Wir benutzen beides je nach Kontext, aber auch je nach Kunde, weil wir nicht immer die nötigen Informationen für Personas zusammenstellen können. Es geht hier auch um realistische demografische Daten auch Hobbies zum Beispiel, sollen wir das rausfinden, wenn wir nicht mit Kunden reden dürfen? Also es hängt immer davon ab, mit wem wir reden dürfen und welche Informationen wir kriegen, um bestimmte Artefakte erstellen zu können. Personas sind schön, aber eben keine komplett ausgedachten. Auch Szenarien sind toll. Also du stellst dir einfach vor, wie man später mit deiner Software arbeitet. Das in einem bestimmten Kontext einer aufschreibt ganz realistisch was passiert. Welche Ablenkungen stattfinden können zum Beispiel. Keine Ahnung, Telefon klingelt, Kollege klopft an die Tür. Was mache ich denn als Nutzer dann mit meiner Anwendung? Diese Dinge geben dir ein realistischeres Bild, in welchem Kontext und von welchen Leuten später deine Anwendung genutzt wird. Und du als Entwickler kannst dir viel mehr Gedanken machen, wo du vielleicht noch Dinge vergessen hast.
Anja In der praktischen Consulting Arbeit passiert es meinem Team zum Beispiel auch so, dass wir immer konkrete Nutzerinnen im Blick haben. Würde dieses Feature jetzt Ute Meier, die auf jeden Fall damit arbeiten wird in Zukunft, wie würde sie das finden? Bräuchte sie vielleicht diese Funktionalität? Am Ende fragen wir natürlich dann auch Ute Meier, ist natürlich nur ein fiktiver Name. Aber wir haben auch immer konkrete Personen im Blick. Wenn man konkrete Personen kennt, also die Nutzerin kennt, dann ist es natürlich sehr einfach. Wir sind schon am Ende unserer Session. Sven wollte gerade noch was sagen. Hast du noch ein abschließendes Statement?
Sven Ja, ich wollte was sagen. Mir ist gestern mal wieder schmerzlich bewusst geworden, wie viel Aufwand und Ärger es führt, wenn man die Benutzer nicht im Blick hat. Weil ich war ein Benutzer einer API oder ich soll der Benutzer einer API sein und die Provider dieser API, die interessieren sich überhaupt nicht für den User. Und das haben nie mit irgendjemandem geredet. Und ich kann mir jetzt gerade als du gesagt hast, wir Entwickler denken sich etwas aus. Die haben sich bestimmt nach bestem Wissen und Gewissen irgendwas ausgedacht. Aber für mich und für meine Kollegen war es die völlige Katastrophe. Das hätte man besser sich überlegen können. Hätten sie nur uns gefragt. Wir können uns viel vorstellen, aber für mich wäre das Ding: Man muss die Benutzer fragen.
Andreas Auch wenn es im ersten Moment teuer ist, man kriegt es doppelt, dreifach, zehnfach zurück.
Sven Ich frage mich halt, ist es wirklich so teuer? Weil ich baue doch das falsche Produkt. Ist doch Teil von meinem Requirements Engineering Prozess.
Andreas Naja, du baust das Produkt dann schon so, dass es dein Ziel erfüllt. Du kümmerst dich nicht darum, dass es wirklich gebrauchstauglich ist und vor allem nicht, dass es nutzbar ist. Es ist am Ende ja schon nutzbar. Aber es ist vielleicht aufwändiger als es sein muss.
Anja So, ich würde sagen, wir könnten jetzt noch weitere Stunden diskutieren. Fragt gerne noch Dinge im Chat. Wir werden versuchen, sie zu beantworten. Und vielen Dank, dass ihr da wart. Andreas, Sven, es war mir eine Freude.
Andreas Oder kontaktiert mich direkt auch über meine Email-Adresse. Ich bin immer da. Ich helfe gerne und ich bin auch froh, wenn sich Unternehmen melden, die vielleicht Interesse haben, die Usability oder Accessibility zu erhöhen. Tschüss.