Name/Rolle/Wert – Wem gehört diese Rolle eigentlich?

Willkommen zur nächsten Ausgabe meiner Blogreihe zum Thema Designstrategie. Heute möchte ich euch eine Kundengeschichte vorstellen, in der Hoffnung, dass ihr euch Gedanken darüber macht, WARUM ihr Dinge anders angehen solltet, damit euer Programm schnell reifen und skalieren kann. Ich werde erneut auf die übliche „How-to“-Artikelformel und trockene Aufzählungen taktischer „Tu dies/Tu das nicht“-Anweisungen verzichten. Nun aber zur Geschichte…

Das Problem

Dieser Kunde wandte sich an uns, um eine Bestandsaufnahme seiner digitalen Präsenz durchführen zu lassen. „Natürlich“, sagten wir, „wir helfen gerne weiter!“ 

Ihre Website wies eine ganze Reihe von Problemen auf. Es ist wichtig zu wissen, dass das in Ordnung ist. Wenn man sich auf die positive Seite der Sache konzentriert, ist dem Kunden nun klar, wo er steht und was zu tun ist.

Mensch. Dieses Szenario ist sogar mehr als nur in Ordnung – es ist fantastisch! Warum? Weil wir mit einem Kunden zusammenarbeiten, der jetzt bereit ist ist, die Ärmel hochzukrempeln, nicht nur, um Abhilfe zu schaffen, sondern auch, um der Sache auf den Grund zu gehen und die Ursache zu finden und zu beheben. Mit anderen Worten: Er wird sich darauf konzentrieren, das zu beheben, was schiefgelaufen ist und steckt Energie in die Frage, was getan werden kann, um sicherzustellen, dass es nicht wieder passiert. Dieser Fokus wird dem Unternehmen helfen, schnell zu wachsen und sich weiterzuentwickeln.

Schauen wir uns nun an, wie sich das Ganze entwickelt hat. Wir werden die Ursachen und die damit verbundenen Lernmöglichkeiten untersuchen.

Gibt es gemeinsame Themen bei diesen Ergebnissen?

Als ich begann, mich durch die Bewertungsergebnisse dieses Kunden zu arbeiten, fielen mir einige zentrale Themen auf. In diesem Fall waren es mehr als die Hälfte … HALB!!! … der Probleme betrafen den Bereich „Name/Rolle/Wert“. Wie ein Blitz schoss mir der Gedanke durch den Kopf: „Fangen wir hier an!“ Okay, vielleicht nicht ganz wie ein Blitz … aber es war ein naheliegender Ansatzpunkt, um schnell bedeutende Fortschritte zu erzielen.

Name/Rolle/Wert

Lassen Sie uns einige Einzelheiten aus den Erfolgskriterien 4.1.2 der Richtlinien für barrierefreie Webinhalte (WCAG) klären… [Lesen Sie das bitte so vor, wie einer dieser Sprecher in Fernsehwerbespots, die diese trockenen Passagen am Ende ganz, ganz schnell vorlesen.]

Zustände und Eigenschaften sind Attribute, die dazu dienen, Screenreadern und anderen assistiven Technologien wesentliche Informationen über ein Element zu vermitteln. Bestimmte Rollen erfordern bestimmte Zustands- und Eigenschaftsinformationen – wie beispielsweise den aktivierten bzw. deaktivierten Zustand eines Kontrollkästchens. Dieser Code muss gültig sein, damit ein Screenreader die Informationen an einen Nutzer weitergeben kann. Jedes Steuerelement der Benutzeroberfläche muss über eine Rolle sowie alle zutreffenden Zustände und Eigenschaften verfügen, damit Nutzer von Bildschirmleseprogrammen wissen, wie sie mit dem Steuerelement interagieren können. Entwickler müssen die relevanten Rollen sowie alle zutreffenden Zustände und Eigenschaften und die erwarteten Wischgesten hinzufügen.

Lassen Sie uns dies anhand eines Beispiels näher erläutern. Angenommen, wir möchten, dass der Nutzer beim Ausfüllen eines Formulars das Newsletter-Abonnement abbestellt (anstatt es zu abonnieren). Daher gestalten wir die Benutzeroberfläche so, dass das Kontrollkästchen „Newsletter abonnieren“ bereits angekreuzt ist; die Entscheidung ist also bereits getroffen für Benutzer bereits getroffen. Der Benutzer muss diese Auswahl vor dem Absenden aufheben, wenn er sich nicht für den Newsletter anmelden möchte. Die Anmerkung im Wireframe muss dem Entwickler genau mitteilen, dass das Kontrollkästchen im Rahmen der Entwicklung aktiviert werden soll, damit es beim Laden der Seite bereits markiert erscheint. Diese Anmerkung weist auch den Tester darauf hin, im Rahmen seines Testprozesses sicherzustellen, dass das Kontrollkästchen beim Laden der Seite markiert ist. Der Tester wird natürlich auch prüfen, ob es ausgewählt (aktiviert und deaktiviert) werden kann, und testen, ob das Formular im deaktivierten Zustand ordnungsgemäß abgeschickt werden kann.

Der „Aha!“-Moment, gefolgt von Überlegungen und Erkenntnissen

Schauen wir uns den letzten Satz dieses Klappentextes einmal etwas genauer an:

Entwickler müssen die entsprechenden Rollen sowie alle zutreffenden Zustände und Eigenschaften und die erwarteten Wischgesten hinzufügen.

Wenn ich über diese Aussage nachdenke, frage ich mich , wie die Entwickler wissen sollen, dass sie die Rollen, Zustände und Eigenschaften hinzufügen müssen. Vor allem frage ich mich, wo die Werte dokumentiert sind und wie sie definiert sind.

Da wir bereits über ein wenig Branchenerfahrung verfügen, wissen wir: Wenn etwas nicht definiert ist und dokumentiert ist, werden Entwickler manchmal einfach ihre eigenen Definitionen verwenden. Und ja, manchmal wehren sie sich mit der Begründung, dass ihnen nicht alle Informationen vorliegen, die sie für eine effiziente Programmierung benötigen. Nicht jeder Entwickler denkt sich einfach etwas aus, nur um den Code weiterzureichen.

Bei weiteren Überlegungen kommen mir Gedanken zum Journey Analyst (in manchen Unternehmen auch als Business Analyst oder Agile Story Coach bezeichnet). Welche Erwartungen hat dieser Kunde an seinen JA? Ist ihm beim Verfassen der Jira-Story oder bei der Erfassung der Anforderungen aufgefallen, dass diese Informationen fehlen? Ist er befugt, den Designer dazu aufzufordern, dies zu definieren? Legt der Kunde eine RACI-Matrix in dieser Detailtiefe fest?

Daraus ergeben sich für uns einige Erkenntnisse:

1. In gut informierten Teams sind die Rollen so festgelegt, dass klar ist, wer für welche Aufgabe verantwortlich ist. In diesem Fall sollte der User-Experience-Designer diese Details in den Anmerkungen zu seinen Wireframes festhalten, und die Designleiter sollten sicherstellen, dass diese Details vor der Design-Review vorhanden und angemessen sind. Bei der Verwendung von Komponentenbibliotheken sollten diese Informationen in der Begleitdokumentation der jeweiligen Komponente klar definiert sein.
2. Erfolgreiche Organisationen verfügen über Kontrollmechanismen: Jeder im Arbeitsablauf überprüft die Arbeit des vorherigen Prozessschritts noch einmal. Entspricht etwas nicht den Standards oder weicht es von den Vorgaben ab, wird die Arbeit zur Korrektur an den Schritt zurückgeschickt, in dem der Fehler aufgetreten ist. Dies ist vor allem deshalb möglich, weil jeder im Team die Rollen und Verantwortlichkeiten aller anderen versteht. Dank dieses Wissens wissen die Teammitglieder sofort, an wen sie sich wenden müssen, um das Problem zu beheben. Das ist nicht nur effizienter, sondern trägt auch dazu bei, den Erfolg des gesamten Teams sicherzustellen und gleichzeitig stärkere Teams aufzubauen.
   • HINWEIS: Möchten Sie das einmal in der Praxis erleben? Beobachten Sie das Team Ihrer Lieblingskaffeekette doch einmal, wenn Sie das nächste Mal auf ein leckeres Kaffeegetränk warten. Jeder versteht, welchen Beitrag die einzelnen Positionen leisten und wie wichtig es ist, proaktiv mitzuhelfen, damit alles reibungslos läuft.
3. Teammitglieder müssen befähigt und ermutigt werden, sich sofort zu Wort zu melden. Wenn sie feststellen, dass etwas fehlt oder nicht ganz stimmt, melden sie dies. Sie wissen, wie viel Zeit und Aufwand eingespart werden kann, wenn Probleme so schnell wie möglich behoben werden. In diesem Fall hätte das Problem bereits in der Entwurfsphase vom Design-Leiter oder einem Fachexperten für Barrierefreiheit (SME) verhindert werden können. Es hätte vom Journey-Analysten entdeckt werden können, der dafür sorgen sollte, dass der Entwickler über alle Informationen verfügt, die er für eine erfolgreiche Programmierung benötigt. Der Entwickler hätte sich zu Wort melden können, um alle Beteiligten bereits in einer früheren Phase des Prozesses darüber zu informieren, dass diese Informationen fehlten. Der Tester hätte dieses Problem entdecken können, als er an seinem Testskript arbeitete und die Wireframes überprüfte. Es gab mehrere Gelegenheiten, zu verhindern, dass dieses Problem in die Produktion gelangte.
4. Im Rahmen einer gründlichen Barrierefreiheitsprüfung hätte dieses Problem bereits vor der Produktionsfreigabe erkannt werden müssen, da die Behebung dort kostengünstiger gewesen wäre als bei einem Problem, das erst in der Produktionsumgebung entdeckt wurde.
5. Das Risiko (und auch die Kosten) steigen noch weiter an, wenn neben den Verstößen gegen die WCAG auch Prozessfehler berücksichtigt werden.

Was könnten wir mit diesen Erkenntnissen anfangen?

Hier gibt es jede Menge „Stoff“, um Verbesserungen, Effizienzsteigerungen und solide Methoden zu entwickeln. Arbeiten Sie effizient, nehmen Sie sich aber auch Zeit, um Design-Thinking-Ansätze anzuwenden, um Ihre Probleme und mögliche Lösungen zu verstehen. (Letztendlich steigert dies sogar die Effizienz.) Planen Sie strategisch, um Prozessänderungen und Anpassungen so zu staffeln, dass sie sowohl dosiert (um die Akzeptanz durch Ihre Teams zu erleichtern) als auch priorisiert (um Ihrem Unternehmen so früh wie möglich den größtmöglichen Nutzen zu bringen) umgesetzt werden.

Einige Überlegungen:

• Nutzen Sie die Trends in Ihren Daten, um Ihre Probleme anhand der Menge, der Reparaturfreundlichkeit oder der Reparaturmöglichkeit anzugehen.
• Erstellen Sie Rollenmatrixen, um sicherzustellen, dass alle erforderlichen Elemente identifiziert und einer Rolle zugeordnet werden. In diesem Fall sollten Rolle, Name und Wert von einem User-Experience-Designer dokumentiert werden. Der Design-Leiter sollte dafür verantwortlich sein, deren Vorhandensein und Richtigkeit sicherzustellen.
• Stellen Sie sicher, dass alle Teammitglieder die Beiträge – und die Bedeutung dieser Beiträge – für die ihnen vorausgehenden Rollen und Aktivitäten verstehen. Stellen Sie sicher, dass sie die Bedeutung von ihrer Beiträge für diejenigen, die im Prozess nach ihnen kommen.
• Machen Sie Ihren Teammitgliedern klar, wie wertvoll es ist, sich einen Moment Zeit zu nehmen, um ein Problem zu beheben, sobald es auftritt – im Vergleich zu dem Aufwand und den Kosten, die entstehen, wenn diese Probleme später in Form von Tickets oder Fehlern wieder auftauchen.
• Helfen Sie Ihren Teams zu verstehen, wie wichtig es ist, die Arbeit gegenseitig zu überprüfen, und dass das Aufzeigen von Fehlern oder Problemen eine gute Sache ist. Beschwerden sind ein Geschenk, wenn sie früh genug eingehen. (Es gibt zahlreiche Bücher zum Thema „Beschwerden als wertvolle Informationsquelle“; ich empfehle Ihnen, sich diese später einmal anzusehen.)
• Stellen Sie sicher, dass Ihre SDLC-Prozesse die Barrierefreiheit in jeder Phase des Prozesses und häufig auch innerhalb der einzelnen Phasen analysieren und testen.
• Nutzen Sie agile Retrospektiven, um Fehlertrends zu analysieren und aktiv nach Lösungen für die Grundursachen zu suchen, die sicherstellen, dass Fehler dieser Art in Zukunft nicht mehr auftreten.
• Halten Sie Ausschau nach Gelegenheiten für kurze Weiterbildungsmaßnahmen, die dazu beitragen, diese Probleme zu vermeiden. Erstellen Sie entsprechende Materialien und präsentieren Sie diese im Rahmen von „Lunch-and-Learn“-Veranstaltungen, auf dem Portal Ihres Barrierefreiheitsprogramms oder in Ihrem Intranet, in Newslettern und/oder über Ihr Lernmanagement-Tool. Erstellen Sie in diesem Fall Schulungen für alle Rollen, in denen erläutert wird, was „Name/Role/Value“ ist, wie es dokumentiert werden sollte, welche Kodierungsstandards gelten und wie es getestet werden sollte.
• Wenn Sie gerade erst mit Ihrem Barrierefreiheitsprogramm beginnen, sollten Sie den Schwerpunkt zunächst auf die Behebung von Fehlern legen, indem Sie Ihre Teams dazu anweisen, sich zunächst auf die Beseitigung von Hindernissen und kritischen Fehlern zu konzentrieren. Fügen Sie im Verlauf Ihrer Sprints oder Epics nach und nach weitere Fehlerstufen hinzu, bis der gesamte neu entwickelte Code frei von Barrierefreiheitsproblemen ist. Lassen Sie Ihre Teams anschließend die Beseitigung der barrierefreiheitsbezogenen technischen Schulden in Ihrem Produkt (End-to-End) priorisieren, bis die Tests keine Probleme mehr aufzeigen.

Warum ich diesen Ansatz zur Lösung von Designproblemen in großem Maßstab so schätze

Jedes Team und jedes Teammitglied kann sich einen Fehler ansehen und schnell eine lange Liste möglicher Verbesserungen aufstellen. Doch alle möglichen Optionen durchzugehen, ist zeitaufwendig und ineffektiv. Der Schlüssel liegt darin, immer wieder Fragen zu stellen, um dem Problem auf den Grund zu gehen. (Wie Sie sich vielleicht erinnern, haben wir die Fischgräten-Methode .) Wenn ein Problem klar definiert ist, ist es einfacher (und schneller), die richtige Lösung zu finden. 

Kommen wir zurück zu dem Problem des Kunden, bei dem die Hälfte der Probleme mit „Name/Rolle/Wert“ zusammenhing. Ich hoffe, Sie erkennen, dass ich dieses Problem als Allegorie verwende, um Ihnen zu verdeutlichen: Wenn Sie dieses Problem genauer unter die Lupe nehmen, werden Sie feststellen, dass es tiefer geht als die Definition von Rollen. Es gibt Probleme mit der Teamdynamik und ein kulturelles Problem, das dazu führt, dass schlecht dokumentierte Wireframes erstellt werden.

Alle arbeiten mit Hochdruck daran, das Programm fertigzustellen und in Produktion zu bringen. Ich verstehe das. Glaub mir, das kenne ich nur zu gut. Aber wenn man das nicht von Anfang an gut macht von Anfang an und den Nutzerpfad so gestaltest, dass der Nutzer keine Probleme hat, wirst du wirst du wieder die Bildschirme überarbeiten müssen, wenn es weder dem Nutzer noch dem Unternehmen einen Mehrwert bietet.
Für mich als Stratege und Service-Designer ist die Optimierung von Betriebsabläufen und Prozesseffizienz für eure Gesamtabläufe wichtiger als fast alles andere. Die Auseinandersetzung mit diesen Aspekten kann die positiven Effekte verstärken, die Lösungen an der Ursache bieten können. Behebt nicht einfach nur den Fehler. Lernt, Probleme so zu beheben, dass sie in großem Maßstab gelöst werden.

Bevor wir zum Ende kommen, möchte ich euch noch das Happy End erzählen … In diesem Fall gelang es dem Team, die Hälfte der bekannten Probleme innerhalb eines einzigen Sprints schnell zu beheben, und es wurde festgelegt, wer dafür verantwortlich ist, Name, Rolle und Wert von Anfang an zu dokumentieren. Das Team arbeitet aktiv an der Teambildung, um sicherzustellen, dass sich jeder ermächtigt fühlt, auf Probleme hinzuweisen – in dem Wissen, dass diese langfristig tatsächlich den Arbeitsaufwand reduzieren. Gut gemacht, Team!