Überlegungen zu Ressourcen und Zeitachsen
Der Entwickler bzw. die Entwicklerin im einleitenden Szenario hat die Community der Menschen mit Behinderung nicht in den Entwicklungsprozess einbezogen. Vielleicht wusste der Entwickler nicht, wo er beginnen soll, oder er hatte Bedenken in Bezug auf Veröffentlichungstermine und Bandbreite.
In dieser Lerneinheit lernen Sie grundlegende Konzepte zur Einbindung der Community kennen, mit denen folgende Themen aufgegriffen werden. Einige Beispiele für diese Konzepte:
- Konzepte zur Einbeziehung und Optimierung von Feedback von Menschen mit Behinderung in vorhandene Feedbackschleifen.
- Die Bedeutung der Einbindung verschiedener Benutzer*innen und Perspektiven.
- Möglichkeiten, wie Feedback eingeholt werden kann, unabhängig davon, an welcher Stelle im Entwicklungszyklus sich ein Team befindet.
Einbetten von Feedback zur Barrierefreiheit in vorhandene Feedbackprozesse
Wenn sich Ihr Team bislang noch nicht mit Barrierefreiheit befasst hat, wirkt die Befragung von Menschen mit Behinderung nach ihren Perspektiven möglicherweise wie eine große Herausforderung. Das muss aber nicht so sein. Überlegen Sie, welche Standardprozesse in Ihrem Team oder in Ihrer Organisation anwendet werden, wenn allgemeines Benutzerfeedback einholt oder Benutzerforschung außerhalb des Themenbereichs der Barrierefreiheit durchgeführt werden.
Vielleicht verschickt Ihr Team bereits Umfragen, führt regelmäßig Forschungsstudien durch oder führt Spieletests für alle Produkte in der Entwicklung durch. Wenn dies der Fall ist, können Sie Feedback von Menschen mit Behinderung einholen, ohne völlig neue Prozesse oder Programme zu entwickeln, indem Sie einfach dafür sorgen, dass in diese vorhandenen Teilnehmerpools Spieler*innen mit Behinderung eingebunden werden.
Hinweis
Es wird empfohlen, bei dieser Aufgabe nach Möglichkeit mit dem Benutzerforschungsteam zusammenzuarbeiten. Diese Teams sind entsprechend geschult und wissen, wie sie sinnvolle Fragen stellen und Daten analysieren können. Wenn Ihnen keine Ressourcen für die Benutzerforschung zur Verfügung stehen, können Sie sich zumindest über Maßnahmen informieren, mit denen sich die Perspektive von Menschen mit Behinderung in Feedbackschleifen einbinden lässt.
Einbinden verschiedener Benutzer*innen und Perspektiven
Bevor Sie beginnen, haben Sie möglicherweise Fragen wie:
- „Wie viele Spieler*innen mit Behinderungen sollten in eine Feedbacksitzung einbezogen werden?“
- „Woran erkenne ich, dass das Feedback einer einzelnen Spieler*in für das Feedback anderer Spieler mit ähnlichen Behinderungen repräsentativ ist?“
Darauf gibt es zwar keine endgültige Antwort oder Richtlinie, doch es ist wichtig zu wissen, dass sich die Erfahrungen einer Spieler*in mit einer Behinderung stark von denen einer anderen Spieler*in unterscheiden können.
Daher sollten Sie viele verschiedene Benutzer*innen befragen und viele Perspektiven berücksichtigen. Wenn Sie beispielsweise Feedback über die visuelle Barrierefreiheit der Benutzeroberfläche eines Spiels einholen möchten, sollten Sie von mehreren Spieler*innen mit verschiedenen Arten von Sehbehinderungen Feedback einholen.
Einholen von Feedback während der gesamten Entwicklungszeitachse
Es ist auch wichtig, daran zu denken, dass Feedback zur Barrierefreiheit in allen Phasen des Entwicklungsprozesses eingeholt werden kann und muss. Diese Zusammenarbeit beginnt idealerweise mit Planungs- und Zielsetzungsphasen. Wenn Sie die Barrierefreiheit von Anfang an berücksichtigen, vermeiden Sie Situationen, in denen Barrierefreiheitsfunktionen erst in letzter Minute ergänzt werden.
Bei Aktionen in letzter Minute lassen sich Barrierefreiheitslösungen nicht effektiv in den Entwurf eines Spiels integrieren. Es ist unwahrscheinlich, dass sie den Spieler*innen dieselbe Unterstützung und Effektivität bieten können, die Sie erreichen, wenn Sie die Barrierefreiheit von Anfang bis Ende konsistent priorisieren.
Die folgenden Informationen geben einen Überblick über die Möglichkeiten, in den verschiedenen Phasen der Entwicklung Feedback einzuholen:
Vor der Entwicklung: Auch wenn Ihr Team noch nicht mit der formalen Planung oder Entwicklung begonnen hat, gibt es Möglichkeiten, die Community der Menschen mit Behinderung bereits einzubeziehen. Nutzen Sie diese Zeit, um von Spielern wichtige Informationen über Barrieren zu erhalten, die ihnen in der Vergangenheit beim Spielen anderer Spiele aus ähnlichen Genres wie dem begegnet sind, zu dem das Spiel Ihres Teams gehört. Wenn Sie sich dieser Barrieren vor der Entwicklung bewusst sind, können Sie sie in Ihrem Spiel ganz vermeiden.
Frühe Planung und Zielsetzung: Sobald Sie mit der Planung begonnen und Ziele formuliert haben, verwenden Sie diese Informationen, um Feedback einzuholen. Spieler*innen können die Entwicklung von barrierefreien Spielen verbessern, indem sie auf die potenziellen Barrieren hinweisen, die die geplanten Einstellungen, Mechanismen und anderen Designelemente darstellen können. Sie können auch wertvolles Feedback zu den vorgesehenen Zielen und Plänen zum Erreichen von Barrierefreiheit geben.
Prototypentests: Sobald funktionierende Prototypen oder Builds des Spiels zur Verfügung stehen, sollten Sie den Spieler*innen die Möglichkeit geben, über Spieletests oder Benutzerforschungsstudien Feedback zu geben. Diese praktischen Interaktionen sind für die Erarbeitung von Verbesserungsvorschlägen für Ihr jeweiliges Spiel entscheidend.
Während die Umgebung oder das Gerät weitere Iterationen durchläuft, sollten Sie weiterhin Spieler*innen mit Behinderung in die Tests einbinden. Durch diese Beteiligung kann sichergestellt werden, dass zukünftige Entwurfsiterationen weiterhin effektive und nutzbare Lösungen für diese Spieler*innen bereitstellen.
Wichtig
Es mag verlockend sein, mit der Einbindung der Community zu warten, bis Prototypen zum Spielen verfügbar sind. Es ist jedoch wichtig, an alle potenziellen Barrieren zu denken, auf die von diesen Spieler*innen in früheren Entwicklungsphasen hingewiesen wurde. Ohne dieses Feedback könnte Ihr Team unzugängliche Erfahrungen in den Prototyp einrücken, deren es sich nicht bewusst war.
An dieser Stelle in der Entwicklung ist es möglicherweise zu spät, eine lange Liste erkannter Probleme zu beheben, die bei der Markteinführung Erfahrungen mit Barrieren verursachen. Die Zusammenarbeit während der gesamten Entwicklung kann die Wahrscheinlichkeit verringern, dass große Zugriffsbarrieren in einem Prototyp auftreten.