WERTE & WANDEL Cover

Werte & Wandel Podcast

WERTE.IT
Since 11/2025 14 Episoden

#13 - Universal Design: Ein Weg zu barrierefreier Software

David Gollasch über die Grundlagen des UD in der Softwareentwicklung

20.05.2026 30 min

Zusammenfassung & Show Notes

In diesem Gespräch wird das Konzept des Universal Design im Kontext der Softwareentwicklung erörtert. David Gollasch von der TU Dresden erklärt die Bedeutung von Barrierefreiheit und wie diese in den Entwicklungsprozess integriert werden kann. Er betont die Wichtigkeit von partizipativem Design, um die Bedürfnisse der Nutzerinnen und Nutzer zu verstehen und zu berücksichtigen. Zudem werden Herausforderungen und Strategien zur Umsetzung von Universal Design diskutiert, sowie die Messung des Erfolgs von barrierefreien Softwareprodukten.


Kontaktdaten David Gollasch
Experte für Mensch-Computer-Interaktion und digitale Barrierefreiheit
Projektleiter Forschungsprojekt AutARK

AutARK – Automatische Adaption Reizüberflutender Kontexte
https://autark.inf.tu-dresden.de
autark@tu-dresden.de

ein aus Mitteln des Ausgleichsfonds durch das BMAS gefördertes Projekt an der
Technische Universität Dresden
Fakultät Informatik
01062 Dresden

Kontakt zu David:

Informationsmaterial zum Thema

Digitale Barrierefreiheit für private Unternehmen:
Umsetzung der EU-Richtlinie 2019/882
https://www.european-accessibility-act.de

EDAD – Design für Alle Deutschland e.V.
https://www.design-fuer-alle.de/design-fuer-alle/

WAS IST DESIGN FÜR ALLE?
http://www.designforall.org

EIDD – Design für ein ganzes Europa
https://dfaeurope.eu

Bundesministerium für Wirtschaft und Energie - Design für Alle in der Praxis - ein Leitfaden für Unternehmen
https://www.bmwi.de/Redaktion/DE/Publikationen/Studien/design-fuer-alle-in-der-praxis-ein-leitfaden-fuer-unternehmen.html

ISO 9241-11:2018 - Ergonomie der Mensch-System-Interaktion
Teil 11: Benutzerfreundlichkeit: Definitionen und Konzepte
https://www.iso.org/standard/63500.html

SO/IEC 40500:2025
Informationstechnologie — W3C-Richtlinien für barrierefreie Webinhalte (WCAG) 2.2
https://www.iso.org/standard/91029.html


Transkript

Detlef Girke
00:00:00
Die IT bietet einfach für Menschen mit Behinderung unglaubliche Chancen.
Wolfgang Haase
00:00:03
Damit habe ich mich noch nie beschäftigt. Ich bin Unternehmensberater für Mitarbeiter- und Kundenbindung.
Detlef Girke
00:00:11
IT und ein inklusiver Ansatz im Unternehmen kann dazu führen, dass man wirklich gewinnbringend Menschen mit Behinderungen auch im eigenen Unternehmen beschäftigen kann.
Moderationsperson
00:00:21
Werte & Wandel, der Podcast zum Thema inklusives Management in Unternehmen.
Detlef Girke
00:00:27
Herzlich willkommen zu einer neuen Folge von Werte & Wandel. Diesmal geht es um das Thema Universal Design und als Gast habe ich diesmal Herrn David Gollasch. Hallo David.
David Gollasch
00:00:40
Ja hallo Detlef, schön, dass ich hier sein kann.
Detlef Girke
00:00:43
Vielen Dank, dass du hier bist.
David Gollasch
00:00:44
... freue mich auch.
Detlef Girke
00:00:46
David kommt von der Universität Dresden und er wird sich jetzt einmal kurz mit ein paar Worten vorstellen.
David Gollasch
00:00:53
Genau, das ist eigentlich nicht schlecht, sich so ein bisschen einzuordnen. Also David Gollasch, mein Name, ich bin wissenschaftlicher Mitarbeiter an der TU Dresden und da speziell im Fachbereich Mensch-Computer-Interaktion. Das ist so ein Fachbereich, der gehört mit zur Informatik und beschäftigt sich eigentlich vor allen Dingen damit, bei uns am Lehrstuhl, mit der Interaktion zwischen dem Mensch und dem Computer.
Detlef Girke
00:01:16
Gut, das sagt der Name schon.
David Gollasch
00:01:18
Aber im Prinzip die Frage, wie man eigentlich interaktive Systeme, digitale Systeme gut gestaltet. Und speziell an unserem Lehrstuhl auch, wie man vor allen Dingen Systeme auch barrierefrei gestaltet. Also das große Thema der digitalen Barrierefreiheit. Und ganz speziell leite ich ein Forschungsprojekt dort an dem Lehrstuhl zur Entwicklung von assistiven Technologien für autistische Menschen. Zur Verbesserung der Beschäftigungssituation, weil es da durchaus prekär ist am Arbeitsmarkt. Und das ist unser Forschungsprojekt, das ich leite. Und da können wir bestimmt nochmal mit dem ein oder anderen Beispiel im Laufe der Folge drauf zu sprechen kommen.
Detlef Girke
00:01:54
Sehr spannendes Thema. Sag doch mal einfach jetzt erstmal für alle Zuhörerinnen und Zuhörer, was verstehst du unter Universal Design im Kontext zur Softwareentwicklung?
David Gollasch
00:02:04
Ja, großes Feld erstmal, Universal Design. Ich finde das immer ganz interessant, dass es ja eigentlich in diesem Umfeld ganz viele verschiedene Begrifflichkeiten gibt, die so vom Grundkonzept was Ähnliches meinen oder das ähnliche Ziel verfolgen. Im Prinzip geht es ja beim Universal Design darum, Systeme oder Design so zu verstehen, dass es für eine möglichst breite Gruppe, eigentlich für alle, zugänglich ist und nutzbar ist. Im Grunde genommen gibt es ja verschiedene Bewegungen, die in die Richtung gehen. Also Universal Design als Begriff eigentlich etwas, was eher so aus dem US-amerikanischen Bereich herrührt, wo die Ursprünge lagen. Aber auf der europäischen Seite gibt es das auch. Also gibt es auch den Begriff des Design for All. Hat ein bisschen eine andere Perspektive auf das Thema, aber das Ziel ist eigentlich das Gleiche. Möglichst viele Menschen abzuholen und Systeme Design so zu verstehen, dass es für alle zugänglich ist. Ich möchte es nicht ganz gleichsetzen, aber was Vergleichbares, wie auch mit den Begriffen Barrierefreiheit oder Accessibility oder inklusivem Design. Im Prinzip immer wieder das Ziel, niemanden auszuschließen, alle einzuschließen und keine Barrieren aufzubauen oder eben, wo Barrieren sind, diese eben abzubauen. Was ich immer ganz toll finde, ist ein Begriff, der das Ganze noch ein kleines bisschen weiter fasst als eben mit Universal Design, Design for All und so weiter. Das wäre diversitätssensibles Design.
Detlef Girke
00:03:31
Sehr schön.
David Gollasch
00:03:32
Also so eine Begrifflichkeit, bei der man sagen könnte, Diversität ist das, was uns alle als Gesellschaft ausmacht. Wir sind alle unterschiedlich, und dabei geht es nicht nur um Behinderungen, dabei geht es auch um unterschiedliche Sprache, unterschiedliche kognitive Fähigkeiten und Merkmale, Hintergründe, Erfahrungen und so weiter, die alle irgendwo eine Rolle spielen, im Hinblick auf das Entwickeln von Systemen, das Design als Verständnis insgesamt. Und wenn wir da eben ein sensibles Design haben, dann berücksichtigen wir eben im Idealfall alle.
Detlef Girke
00:04:10
Okay, das waren jetzt viele Begrifflichkeiten und Konzepte eben auch. Und wie verhalten sich diese eigentlich in Bezug auf die Vorgehensweise bei der Umsetzung von Softwareprojekten?
David Gollasch
00:04:20
Ich unterrichte nebenher, das hatte ich vorhin in der Vorstellung so noch nicht gesagt, ich unterrichte nebenher noch an der dualen Hochschule Sachsen auch so das Feld Mensch-Computer-Interaktion und versuche dort auch immer Entwicklungskonzepte zu lehren, beizubringen, wie menschzentriertes Design funktioniert. Und da stellt sich eigentlich auch immer so ein bisschen die Frage, wie setzt man das eigentlich tatsächlich und auch im tatsächlichen Alltag eines Softwareentwicklers, der in einem Softwareentwicklungsprojekt arbeitet und sich überlegt, wie mache ich denn das jetzt menschzentriert? Und im Grunde ist es so, für einen Informatiker oder eine Informatikerin, da sind ja eigentlich Konzepte, Regeln, Richtlinien, feste, definierte Vorgehensweisen immer wichtig. Und gar nicht so sehr die Philosophie von Universal Design oder Design for All, sondern konkrete, umsetzbare Schritte, wie man jetzt Software entwickelt. Und in dem Zusammenhang finde ich es wichtig, dass es Regelungen gibt, die darauf Bezug nehmen. Also da gibt es durchaus Standards, wie sich das gehört. Die ISO 9241 ist so ein Bereich für die Software-Ergonomie. Und da ist sowas wie menschzentriertes Design auch definiert, wie man da vorgeht. Und genauso gibt es Regelungen, was Barrierefreiheit ist, mit den Web Content Accessibility Guidelines, den WCAG oder Gesetze. Auch mit dem Teil 171 von der 9241.
Detlef Girke
00:05:47
Auch das, ja, genau.
David Gollasch
00:05:49
Auch ein Teil der WCAG ist standardisiert in der ISO. Also ich meine, gut, die verweisen auch zum Teil aufeinander und je nachdem kommt es auch immer ein bisschen drauf an, was davon, ich sag mal, gesetzesähnlichen Charakter hat, was dann auch eingesetzt werden muss. Genauso wie es ja bei uns das Barrierefreiheits-Stärkungsgesetz gibt, was dann auch die Leute verpflichtet, barrierefreie Lösungen anzubieten. All solche Konzepte braucht man im Grunde, um dann eben auch einem Informatiker oder Informatikerin beizubringen, wie man denn jetzt nun Universal Design betreibt, sag ich mal. Also wie man eben Systeme entwickelt, die barrierefrei sind. Und dann geht es vor allen Dingen immer wieder auch darum, zu überlegen, wie man diese klassischen unterrichteten Entwicklungsprinzipien und Vorgehensweisen, angefangen vom Wasserfallmodell oder V-Modell hin zu agilen Methoden wie Scrum, immer da das grundlegende Konzept ist oder die Projektstruktur so strukturiert ist, dass agil vorgegangen wird oder eben klassisch nicht agil vorgegangen wird, dass man sich überlegen muss, wie man das eigentlich in Einklang bringen kann mit dem menschzentrierten Design, mit seinen eigenen Methoden und Vorgehensweisen.
Detlef Girke
00:06:57
Kommen wir mal zu den methodischen und technischen Umsetzungen im Rahmen von Softwareentwicklung. Welche methodischen Anpassungen empfiehlst du, Barrierefreiheit und Universal Design möglichst frühzeitig in klassische, aber auch in agile Entwicklungsprozesse, die du eben auch schon erwähnt hast, wie Scrum oder Kanban, zu integrieren?
David Gollasch
00:07:16
Grundsätzlich kann man Software-Projekte auch insgesamt einfach nach einem menschzentrierten Entwicklungskonzept strukturieren. Also das funktioniert, das zu nehmen und zu sagen, okay, das ist jetzt mein Workflow, das Projekt umzusetzen. Das ergibt in den meisten Fällen dann Sinn, wenn es hauptsächlich darum geht, wirklich Interaktion zu designen. Also wenn das System vielleicht kein kompliziertes Backend hat, keine komplizierte Datenstruktur oder Datenbankstruktur, sondern wenn es wirklich im Wesentlichen darum geht, ein Frontend, eine Benutzeroberfläche zu entwickeln. Aber in den allermeisten Fällen geht es darum, ein ganzes Projekt umzusetzen, eine komplette App zu entwickeln zum Beispiel. Und in dem Moment, in dem ich ein anderes Vorgehen zugrunde lege und sage, ich gehe jetzt agil vor oder ich gehe eben nach einem anderen Entwicklungsmodell wie einem V-Modell vor, dann muss man sich zunächst mal überlegen, was so ein menschzentrierter Designprozess eigentlich bedeutet, was das umfasst. Es gibt eben, im Prinzip gibt es vier Phasen. Es gibt eine Kontextmodellierungsphase und eine Benutzer-Verstehen-Phase oder eine Analysephase, in der man sich vor allen Dingen mit der Zielgruppe des Systems befasst, nicht nur theoretisch mit der Gruppe befasst, sondern sich mit ihr gemeinsam zusammensetzt und gemeinsam analysiert, was die Bedürfnisse, was die Needs, die Preferences, die Bedarfe und Wünsche dieser Zielgruppe eigentlich sind, danach ein Design vorzuschlagen, was zu entwickeln ist. das anschließend in einer Evaluationsphase überprüft wird. Wo geschaut wird, inwiefern das den gewünschten Qualitätskriterien hinsichtlich der Usability oder Gebrauchstauglichkeit, heißt das auch in Deutsch so ein bisschen, entspricht, wie man diese Ziele erreicht oder wie man eben auch ein gewisses Level an Barrierefreiheit erreichen kann. dann iterativ zu überlegen, fangen wir damit neu an. Und wenn man diesen Grundprozess erst mal kennt, dann kann man sich überlegen, inwiefern man den eigentlich so mit ... ich sag mal, mit einpflanzen kann in den eigentlich übergeordneten Prozess. Es gibt beispielsweise gerade im agilen Bereich gibt es immer so ein Grundkonzept, dem alle agilen Entwicklungsmodelle folgen. Es gibt zwei Lebenszyklen. Es gibt so einen agilen Produktlebenszyklus, dem man folgt, der also sozusagen von der Grundidee, bevor das Projekt eigentlich startet, startet und aufhört, wenn die Lebensdauer des Produktes insgesamt vorbei ist. Und dann gibt es allerdings diese agilen Einzelschritte, die kleinen Iterationen, die nach und nach die Entwicklung des Produktes ausmachen. Und menschzentriert kann man beides betrachten. Man kann also menschzentriert herangehen von der Idee sozusagen eines Produkts bis zum Ende des Lebenszyklus, sowie aber eben auch bei der Entwicklung einzelner Artefakte, die sozusagen zur Entwicklung des Produktes beitragen. Man kann immer überlegen, Wo steckt eigentlich Anforderungserhebung dahinter? Wo steckt das Verstehen der Aufgabe des Kontextes dahinter? Wo steckt Verstehen des Nutzenden dahinter? Wo steckt Entwicklung, Umsetzung eines Vorschlages, also die eigentliche Implementierung dahinter? Und wo steckt das Überprüfen, das Testen sozusagen oder Evaluieren dahinter? Und bringt sozusagen auf die Weise die einzelnen Methoden, die es im menschzentrierten Design gibt, dort mit unter. Und damit bringt man das so ein bisschen überein. und hat nicht zwei parallele Welten von eigentlichen Projektplanen und dann aber jemand, der ankommt und sagt, lasst mal menschenzentriert entwickeln, was dann schlecht überein zu bringen ist. Aber das muss man sozusagen individuell bei jedem Projekt so ein bisschen entscheiden, wie man die Methoden am besten unterbringt und wie man den Prozess am besten implementiert. Das ist immer so ein kleines bisschen Abwägungssache und auch Kostensache. Aber dieses Verständnis für den Grundprozess und Verständnis der Ziele sozusagen der einzelnen Phasen im menschenzentrierten Design und das überein bringen mit den Zielen der Phasen des übergeordnet angewandten Entwicklungsprozesses sind das, was man tun muss, um menschzentriertes Design in der Softwareentwicklung in einem Projekt umzusetzen.
Detlef Girke
00:11:07
Okay, hört sich komplex an. In der Praxis stehen Teams häufig unter Zeit- und Kostendruck. Das kommt jetzt ja dazu, das hast du ja gerade auch schon erwähnt, gerade den Kostenfaktor. Wie gelingt es eigentlich, Universal Design oder Human Centered Design, aber auch Accessible Design, dennoch als Qualitätsmerkmal und nicht nur als Zusatzaufwand zu etablieren? Dass es kein Add-on ist am Ende, sondern wirklich mittendrin sozusagen als Teil des Ganzen.
David Gollasch
00:11:33
Du hast gerade schon gesagt, das ist aber ein komplexes. Das kann man aber ganz schön komplex betrachten. Und in dem Moment, in dem man bei dieser Sichtweise bleibt, kann das natürlich abschrecken und man denkt, okay, das wollen wir eigentlich nicht zu kompliziert. Und vielleicht kommt man dann zu der Erkenntnis, ja, so groß ist das Produkt vielleicht oder auch doch gar nicht und wir wollen das nicht aufblasen, unnötig. Aber ich glaube, die Perspektive auf das Thema Barrierefreiheit oder auf das Thema diversitätssensibles Design, Universal Design ... Insgesamt muss dazu eigentlich ein bisschen geschiftet werden. Also man darf dann nicht sehen, dass man jetzt Barrierefreiheit nur umsetzt, weil es das Barrierefreiheitsstärkungsgesetz gibt. Dass man sagt, okay, jetzt weil ich das machen muss, mache ich es halt. Sondern dass man ein kleines bisschen über den Tellerrand schaut und erst mal guckt, wie viele Menschen betrifft das eigentlich. Sich überhaupt erst mal bewusst zu machen, wie groß eigentlich die Zielgruppe ist, die man mit dem Thema Barrierefreiheit erreicht. Und wenn man jetzt das Ganze aufmacht und sagt, Barrierefreiheit ist nicht nur da für Menschen mit Behinderungen, damit die Teilhabe erleben und Zugang bekommen zu Systemen, sondern eigentlich ist Barrierefreiheitsdesign etwas, von dem jeder am Ende was hat. In dem ein Text nicht unnötig kompliziert geschrieben wird, sondern leicht verständlich ist. Dann ... können nicht nur Menschen mit einer kognitiven Beeinträchtigung lesen, sondern es ist insgesamt einfach einfacher zu verstehen. Oder nehmen wir mal bei visuellen Beeinträchtigungen das Thema Kontraste. Das Einhalten von guten Kontrastwerten oder ausreichend großer Schrift sind Themen, die jetzt nicht nur Menschen zugutekommen, die darauf angewiesen sind, das System ohne nicht nutzen könnten, sondern es wird insgesamt viel leichter, solche Systeme dann zu nutzen, wenn Kontraste richtig eingehalten werden. Und wie oft sieht man, dass das nicht richtig gemacht wird? Das wäre so ein... Ja, eine gute Farbwahl, eine schlaue Farbwahl und gute Schriftarten und gute Schriftgrößen ist ja eigentlich relativ... eine low-hanging fruit eigentlich. Eigentlich immer sehr leicht zu schaffen bei der Barrierefreiheit an den Stellen zusammen. Wenn man es vom Firmenlogo ableitet, dann vielleicht nicht. Dann hängt die Fruit nicht so low. Ja gut, alle machen ab und zu mal so ein Rebranding und Redesign-Phase durch, an der TU ja jetzt dieses Jahr auch. Und das kann man ja immer gleich zum Anlass nehmen und überlegen, ob man da nicht richtig das Thema Barrierefreiheit mit entwickeln kann.
Detlef Girke
00:14:00
Okay, super. Kommen wir mal zum Universal Design in der Praxis und zur Prozessgestaltung. Und eben deine Erfahrungswerte. Die verschiedenen Stakeholder, etwa UX Designer, Designerin, Accessibility Expert, Experten, Endnutzerinnen mit Behinderungen. Wie bindest du die in die Planung, ins Testing und in die Evaluation ein?
David Gollasch
00:14:21
Das ist im Grunde schon so ein bisschen beschrieben, aber vielleicht mal so noch mal ein bisschen zusammenfassend.
Detlef Girke
00:14:27
Genau.
David Gollasch
00:14:28
Ich habe ja bisher noch kein Beispiel aus unserem Projektalltag genannt. Allerdings habe ich ja jetzt gerade auch eher so ein bisschen über Barrierefreiheit und Universal Design im Großen so gesprochen. Wir arbeiten in unserem Forschungsprojekt ja vor allen Dingen daran, Assistenztechnologien, assistive Technologien zu entwickeln. Das ist ja eigentlich die Brücke, sage ich mal, für Menschen, die dann eben diese assistiven Technologien benötigen, andere Systeme wiederum überhaupt erst nutzen zu können und das zu tun. In einer perfekten Welt würde man assistive Technologien gar nicht benötigen. Wenn alles universal designed wäre, bräuchte man ja gar keine Assistenz. Aber gut, jetzt ist unser Ziel, eigentlich assistive Technologien zu entwickeln und deswegen ist unser übergeordneter Entwicklungsprozess, das eben auch mal so darzustellen, eben doch der menschzentrierte, der an erster Stelle steht. Also wir entwickeln nicht nach Scrum oder wir entwickeln auch nicht nach V-Modell, sondern wir entwickeln ganz klar nach diesem menschzentrierten Designansatz und da ist es so, Also so wie der Name eigentlich schon sagt, menschzentriert, geht es nicht nur darum, dass der Mensch rein theoretisch im Zentrum steht, sondern dass er auch ganz praktisch mit eingebunden wird. Da finde ich eigentlich, also ich finde diesen Begriff menschzentriertes Design oder user-centered Design an sich ganz schön, so als bezeichnenden Prozess. Aber auch da gibt es ja einen anderen Begriff noch dafür, dieses participatory Design, dieses partizipative, was hier an der Stelle eigentlich noch mal das Ganze noch ein bisschen deutlicher macht, dass nicht nur der Mensch im Mittelpunkt steht, sondern er sogar partizipiert im Entwicklungsprozess dessen. Und an der Stelle richte ich mich natürlich nicht nur an den letztlichen Endnutzer eines Systems, sondern eigentlich an alle, die da involviert sind, an alle Stakeholder. Und auf die Weise kann ich ganz verschiedene Disziplinen mit einbinden und im Prinzip die Leute befragen, was denn die Zielgruppe eigentlich genau benötigt, was deren Aufgaben sind, wie die sie erfüllen und was Sorgen und Ängste sind, Erwartungshaltungen. Und indem ich sie einerseits analysiere dahingehend, dass ich die Umgebung, den Kontext, die Aufgabe, die am Ende das System entwickeln, bewerkstelligen soll, analysiere, aber eben auch die Bedarfe der Nutzenden eben an sich auch. Auf diese Weise binde ich sie sozusagen in der Anforderungserhebung zu Beginn schon mit ein. In der eigentlichen Umsetzung in der Designphase ist es nicht unbedingt notwendig, die Zielgruppe mit zu involvieren, weil hier an der Stelle ja eigentlich Designentscheidungen abgeleitet werden sollen und umgesetzt werden sollen, ein Vorschlag entwickelt wird. Geht aber. Also es gibt durchaus die Möglichkeit, Co-Design Sessions zu starten und sozusagen den Entwicklungsprozess auch ein bisschen gemeinsam zu gestalten, mit der Zielgruppe auch. Aber noch wichtiger ist dann bei der Evaluation zum Schluss, herauszufinden, ob man denn jetzt eigentlich die Gebrauchstauglichkeit oder die Barrierefreiheit so erreicht hat, wie man es benötigt. Und da braucht man dann auch wieder nicht nur theoretische Richtlinien, die man abcheckt, sondern am besten richtige Nutzerstudien, in denen die Zielgruppe eingeladen wird, die Systeme nutzt und messbare Ergebnisse liefert, denen es dann möglich ist zu entscheiden, wie es mit dem System weitergeht, ob wir fertig sind, ob das Ziel erreicht ist oder auch zu sagen, wo noch Verbesserungen notwendig sind. Also eigentlich eine ganz umfassende Miteinbindung, Partizipation der Zielgruppe, die ist hier ganz unbedingt gewollt. Also hier sollen nicht Informatikerinnen und Informatiker alleine daran arbeiten. Und vielleicht passt das auch nochmal ganz gut zu unserem Forschungsprojekt Autark. Letztlich ist es so, ich selbst bin Informatiker, meine Kolleginnen und Kollegen sind Medieninformatikerinnen und wir sind selbst nicht autistisch. Aber unsere Zielgruppe sind autistische Menschen. Da kann man natürlich berechtigterweise die Frage stellen, was uns überhaupt dazu qualifiziert, für autistische Menschen etwas zu entwickeln. Aber im Prinzip ist es eben doch so, wir entwickeln Systeme, aber indem wir sie menschzentriert, partizipativ entwickeln, binden wir von Anfang bis Ende eben die Zielgruppe selbst mit ein aus allen möglichen Richtungen, aber auch Expertinnen und Experten. Und ja, auf diese Weise binden wir letztlich alle relevanten Zielgruppen, alle relevanten Personen mit ein. Hoffen wir jedenfalls, also so viel wie möglich.
Detlef Girke
00:18:27
Neugierige Frage, was ist effizienter, dieses partizipative Design, was du vorhin erwähnt hast, dass man selbst dann, wenn man entwickelt, nachdem man schon vorher die Anforderungen gemeinsam mit Menschen mit Autismus, Beispiel aus dem Autismus-Spektrum, mit einbezogen hat und danach natürlich wieder evaluieren lässt oder indem man sie wirklich kontinuierlich sozusagen mit einbezieht, gibt es da irgendwelche Erkenntnisse, was effektiver ist?
David Gollasch
00:18:51
Naja, ich würde sagen, das hängt ein bisschen mit der Phase zusammen. Wenn ich dieses Human-Centered-Design, dieser Design-Prozess ist iterativ, also den kann man mehrmals durchlaufen und wäre natürlich gut, in der Projektplanung zu überlegen, den auch wirklich mehrmals zu durchlaufen und dann in den anfänglichen Phasen jetzt kein fertiges System zu implementieren in der Designphase, sondern vor allen Dingen prototypisch zu arbeiten. Und beim Entwickeln von Prototypen, auch meinetwegen auch Pen-and-Paper-Prototypen, etwas auf Papier aufzeichnen oder zu skizzieren. Das sind Dinge, die man auch sehr gut gemeinsam mit der Zielgruppe machen kann. Wenn es dann allerdings in die spätere Entwicklungsphase geht, implementieren, da brauche ich natürlich den Sachverstand, Software entwickeln zu können, programmieren zu können. Und an der Stelle macht das Einbinden jetzt nicht mehr ganz so viel Sinn. Aber es gibt verschiedene Methoden, die das Design, gerade das Strukturieren von Informationen und sowas als gemeinsame Gruppenaufgabe eigentlich wie so einen Workshop angehen. Und wenn man das so macht, dann würde ich sagen, es ist immer eine gute Idee, die zu... Oh und wenn man in einer späteren Entwicklungsphase ist, dann macht es Sinn, die Entwicklungen erst einmal entwickeln zu lassen.
Detlef Girke
00:20:00
Okay, trotzdem ist es ja so, dass viele Organisationen vor der Aufgabe stehen, bestehende Systeme nachträglich zu optimieren. Das passiert ja ständig sozusagen. Welche Strategien empfiehlst du für eine schrittweise Nachrüstung in Richtung Universal Design?
David Gollasch
00:20:16
Das ist wirklich spannend. Gerade im Informatikstudium lernt man eigentlich oftmals vom Idealfall. Man lernt eigentlich, wie man so eine Software auf der grünen Wiese entwickelt. Und die Realität sieht ja eigentlich so aus, dass diese grüne Wiese-Projekte überhaupt gar nicht existieren. Also ganz, ganz selten, dass das überhaupt mal relevant ist. Und man muss immer überlegen, wie man eigentlich mit einem bestehenden System anfängt, das eben so weiterzuentwickeln und zu verbessern, wie man es braucht. Und ich sag mal, wenn eine alte Codebase, ein altes Produkt, ein altes System vielleicht noch mit einem Wasserfallmodell vielleicht entwickelt wurde, dann überlege ich mir ja vielleicht doch, wie ich die Weiterentwicklung agil gestalten könnte heutzutage. Ja, das wäre der erste Schritt. Und wenn ich jetzt sage, ich möchte das Ganze in Zukunft menschzentriert angehen, dann hält mich eigentlich nichts davon ab, diesem menschzentrierten Ansatz sofort umzusetzen. Ich sollte vielleicht mit einer Evaluationsphase beginnen. Also erstmal gucken, wo steht denn das aktuelle System? Und mir überlegen, was sind eigentlich meine Messkriterien? Weil ich kann solche Themen wie Gebrauchstauglichkeit oder auch kognitive Anstrengung bei der Nutzung eines Systems, also wie schwierig ein System ist zu nutzen oder auch Barrierefreiheit mit einem bestehenden System messen. Das muss man vielleicht zum Verständnis bei menschenzentriertem Design noch mal dazu sagen. Es gibt eigentlich immer bei jedem Entwicklungsprozess ja so eine Vorgehensweise, dass man sagt, wir haben erstmal Anforderungen, die wir erheben wollen. Dann setzen wir was um und danach überprüfen wir, ob wir die Anforderungen erfüllt haben. Und das steht so in dem Verständnis von, haben einen Lastenheft, daraus entwickeln wir einen Pflichtenheft. Das ist mehr oder weniger eine Checkliste, die wir am Ende gegenprüfen und abhaken können, ob jetzt eben diese Checkliste erfüllt ist, also das Pflichtenheft erfüllt ist. Das funktioniert bei menschenzentriertem Design ein bisschen anders. Es geht am Anfang eben nicht so sehr darum, einen Pflichtenheft zu entwickeln, eine Anforderungsliste, die man anschließend abhaken kann, sondern Verständnis zu entwickeln für die Bedarfe, für das auch das Denken, auch ein bisschen das mentale Modell der Zielgruppe, um da gute Designentscheidungen zu treffen und anschließend hinterher die Gebrauchstauglichkeit zu messen. Nicht die Anforderungen abzuhaken, sondern zu messen, wie gut kann man jetzt das System benutzen. Es gibt so diesen umgangssprachlichen Begriff der Benutzerfreundlichkeit, das nicht mehr so verbreitet, aber das ist auch immer ganz gutes Verständnis dafür, was damit gemeint ist. Wie gut benutzerfreundlich ist das System, wie gut kann ich meine Ziele erreichen? Wie schwierig ist es, so System zu benutzen? Oder aber auch überhaupt die Frage, wie akzeptiert ist das System? Also, wie wird das von der Zielgruppe angenommen? Wollen die das nutzen? Oder ist da eher so eine Reaktanz, so, na, da wieder was Neues, ein neues System, wollen wir gar nicht nutzen?
Detlef Girke
00:23:02
Ja, aber da habe ich eine Zwischenfrage. Im Rahmen der ganzen iterativen Schritte ergeben sich aber trotzdem ja Anforderungen. Wie werden die dann festgehalten? Wenn es kein Katalog ist, den man dabei festhält, was ist es dann?
David Gollasch
00:23:14
Naja, also man kann das schon machen. Man kann, wenn man konkrete Anforderungen ermittelt hat und gerade zu Beginn, wenn es darum geht, Verständnis dafür zu entwickeln, was das System eigentlich machen soll, ist es schon sinnvoll, aufzuschreiben, was jetzt die genaue Zielstellung eigentlich ist. Wobei, ich würde sagen, bei normalen Pflichtenheften ist es eher so, dass man verbal einfach beschreibt, welche Aufgabe man oder welche Anforderungen zu erfüllen ist. Es gibt ein bisschen bessere Methoden beim menschenzentrierten Design. Zum Beispiel kann ich eine Aufgabenanalyse machen und habe dann am Ende eine Baumstruktur, die mir beschreibt, wie das Verständnis der Zielgruppe ist, eine bestimmte Aufgabe zu erledigen, die anschließend mit dem System gemacht, bewältigt wird. Und genauso ist es auch bei der Verstehensphase des Benutzenden, wenn am Ende das Ziel ist, zum Beispiel eine Persona zu entwickeln, dann habe ich daraus jetzt auch nicht direkt eine Liste von Anforderungen, sondern ein Werkzeug, mit dem ich andere Menschen befähigen kann, Empathie aufzubauen für die Zielgruppe. Sich sozusagen so ein bisschen hinein zu versetzen und zu überlegen, was brauchen die eigentlich. Man kann dann am Ende natürlich festhalten, welche Designentscheidungen man getroffen hat. Und das ist dann sozusagen die Liste. Das habe ich davon abgeleitet und das habe ich da jetzt umgesetzt. Aber insofern hat man nicht unbedingt eine Liste von Anforderungen am Ende als Ergebnis, sondern vielleicht ein bisschen, ich sag mal, ausführliche, detailliertere Informationen über das, was der Nutzende braucht.
Detlef Girke
00:24:34
Ich finde es einfach nur wichtig, welchen Weg geht man, damit nichts verloren geht? Was man an Erkenntnis im Rahmen der Evaluation gewonnen hat.
David Gollasch
00:24:41
Wie gesagt, bei der Evaluation ist ja jetzt gar nicht so entscheidend, ob das System eine Aufgabe so löst, wie man sie vorher in der Kontextanalyse mal beschrieben hat. Dass man jetzt alle Kriterien, die man aus einer Persona abgeleitet hat, jetzt 100 Prozent so in dem System umgesetzt hat. Sondern interessant ist, ob ich messen kann, ob es eine Verbesserung gibt durch den Iterationsschritt hinsichtlich der... Effektivität, Effizienz oder Zufriedenstellung, der Kriterien für die Gebrauchstauglichkeit eines Systemes, inwiefern ich eine Verbesserung gebracht habe in Bezug auf Barrierefreiheit oder eben auch Technologieakzeptanz. Wie gesagt, so für mich sind das so diese drei Themen, also Gebrauchstauglichkeit, Usability, Nummer zwei dann die Technologieakzeptanz und Nummer drei wäre die Barrierefreiheit als nochmal so.
Detlef Girke
00:25:31
Es führt uns jetzt direkt dahin, wie lässt sich der Erfolg von Universal Design und Softwareprodukten messen? Etwa durch KPI's, also Key Performance Indices oder Indikatoren oder Nutzungsanalysen oder qualitative Feedback Prozesse. Darüber hast du gerade ja schon gesprochen, auch. Was ist so das präferierte Instrument hier?
David Gollasch
00:25:52
Also Key Performance Indicators wirken so schön griffig. Und man kann ja auch so ein Ziel formulieren. Da gibt es auch Maßnahmen wie Smart Ziele, specific und messbar und attainable und so weiter, um Ziele festzulegen. Ich finde es tatsächlich entscheidend, wenn man jetzt über diversitätssensibles Design und Universal Design spricht, dass man da jetzt gar keine so harte Grenze setzt von Erfolgskriterien, sondern vor allen Dingen Verbesserungen zum ... Ist Stand sozusagen eigentlich produziert und deswegen ist es wahnsinnig schwierig, alle Richtlinien und alle Kriterien der Barrierefreiheit zu erfüllen zum Beispiel. Das macht ja auch keiner. Das schafft keiner. Deswegen kann man schlecht sagen, 100 Prozent aller Richtlinien und Erfolgskriterien, die in der WCAG festgelegt sind für Barrierefreiheit, wenn wir das erfüllt haben, haben wir ein fertig barrierefreies System. Ist ja auch nicht so, weil selbst die WCAG löchrig ist. Da gibt es auch Weiterentwicklungen in Richtung, ich beschäftige mich mit Autismus. Das kommt da jetzt eigentlich gar nicht richtig vor. Also, kognitive Beeinträchtigungen sind zwar ... Kann man da reininterpretieren, aber ... Es gibt keine Erfolgskriterien, die messen würden, wie gut das ganze System jetzt für autistische Personen ist. Der ganze Bereich der psychischen Behinderung kommt da auch nicht vor.
Detlef Girke
00:27:10
Ja, deswegen ist das auch nicht das Nonplusultra.
David Gollasch
00:27:14
Aber man muss natürlich irgendwo für sich festhalten, bis wohin man gehen möchte, zu sagen, jetzt ist das Produkt oder das System so weit, dass ich sage, ich kann es ausliefern.
Detlef Girke
00:27:24
Wir kommen damit auch schon am Ende irgendwie an und vielleicht mal letzte Frage so zum Ausblick. Wie siehst du den aktuellen Stand? Sagen wir jetzt so global und und was meinst du? Wie lange brauchen wir noch, bis wir wirklich an einem Punkt sind, wo wir Universal Design wirklich in den Genen sozusagen der Unternehmen mit drin haben?
David Gollasch
00:27:50
Du hast mir nicht gesagt, dass ich eine Glaskugel mitbringen soll. Aber prinzipiell würde ich sagen, ich sehe schon eine Weiterentwicklung, einen Fortschritt. Man sieht schon auf jeden Fall Verbesserungen. Solche Dinge wie dieses Barrierefreiheitsstärkungsgesetz zum Beispiel sind ja ein deutliches Zeichen dessen. Und damit wächst auch ein kleines bisschen das Verständnis für die Notwendigkeit von Barrierefreiheit. Dass das eben nicht nur das notwendige Übel ist, sondern eben eine Qualitätsverbesserung für alle. Eine Mutmaßung bis wohin wir gehen müssen, bis sozusagen alles barrierefrei ist und universell designed ist. Ich glaube, das ist einfach eine große Vision, an der man sich orientieren kann und jede Verbesserung in die Richtung ist ein Gewinn. Je mehr es ins Bewusstsein dringt, der Leute, desto besser. Und so ist es ja auch wegen meiner Aufgabe als Dozierender, das eben auch ein bisschen weiterzutragen und die Relevanz deutlich zu machen und auch zu zeigen, dass es auch kleine Verbesserungen gar nicht so schwierig sind und eine Verbesserung für alle produzieren. Ich denke mal, da sind wir auf einem ganz guten Weg.
Detlef Girke
00:28:54
Das waren doch jetzt perfekte abschließende Worte. Ganz vielen Dank, David, für dieses spannende Interview.
David Gollasch
00:29:00
Herzlichen Dank, dass ich hier sein durfte.
Moderationsperson
00:29:04
Werte und Wandel, der Podcast, der Inklusion in der Informationstechnologie in den Mittelpunkt stellt. Gemeinsam beleuchten wir, wie Unternehmen durch Inklusion nicht nur soziale Verantwortung übernehmen, sondern auch zukunftssicher und erfolgreich agieren können. Lassen Sie sich inspirieren von entspannten Gesprächen, Experteninterviews und praxisnahen Einblicken. Ein Podcast des Projekts Werte.IT, gefördert vom Bundesministerium für Arbeit und Soziales, unter der Federführung des Blinden- und Sehbehinderten Vereins Hamburg e.V., wissenschaftlich begleitet von der Universität Siegen.

2026 - WERTE.IT

Hosted by LetsCast.fm
Deinen eigenen Podcast erstellen