UX-Audit für Webanwendungen: Ein Leitfaden für Produktteams

UX-Audit für Webanwendungen: Ein Leitfaden für Produktteams

Ein UX-Audit für Webanwendungen ist eine strukturierte Prüfung eines angemeldeten Produkts, etwa eines SaaS-Dashboards, Kundenportals oder internen Tools. Dabei wird ermittelt, wo Nutzer nicht weiterkommen, Fehler machen oder aufgeben. Anschließend werden diese Probleme nach Auswirkung und Aufwand priorisiert, damit Ihr Team weiß, was zuerst behoben werden sollte. Wenn Nutzer abspringen, beim Support immer wieder dieselben Fragen eingehen oder die Akzeptanz stagniert, ist ein Audit meist der schnellste Weg, aus vager Frustration eine priorisierte Liste von Änderungen zu machen.

Dieser Leitfaden befasst sich speziell mit Produktoberflächen. Die meisten Online-Ratschläge sind für Marketingwebsites und Onlineshops geschrieben, bei denen es darum geht, einen Besucher zum Klicken auf eine Schaltfläche zu bewegen. In einer Webanwendung besteht die Aufgabe darin, einer Person dabei zu helfen, wiederholt eine Aufgabe mit echten Daten erfolgreich abzuschließen. Dadurch ändern sich sowohl die Aspekte, die Sie untersuchen, als auch die Belege, die Sie sammeln, und die Anforderungen an einen guten Bericht.

Die wichtigsten Erkenntnisse

• Ein UX-Audit für eine Webanwendung bewertet den erfolgreichen Aufgabenabschluss, nicht die Attraktivität einer Seite: Onboarding, Navigation, Dashboards, Datentabellen, Formulare sowie Fehler- und Leerdatenzustände.
• Die aussagekräftigsten Audits kombinieren eine Expertenprüfung (heuristische Evaluation), Verhaltensdaten und einen begrenzten Umfang an Usability-Tests, da jede Methode Aspekte übersieht, die die anderen aufdecken.
• Erkenntnisse sollten nach Auswirkung und Umsetzbarkeit priorisiert und anschließend mit einer Kennzahl verknüpft werden, die Sie nach der Veröffentlichung der Änderung erneut messen können.
• Automatisierte Tools sind hilfreich, können jedoch weder Barrierefreiheit zertifizieren noch menschliches Urteilsvermögen ersetzen.
• Betrachten Sie das Audit als regelmäßige Prüfung, nicht als einmalige Rettungsmaßnahme.

Inhaltsverzeichnis

• Was ein UX-Audit einer Webanwendung bewertet
• Wie sich ein Produktaudit von einem Website-Audit unterscheidet
• Wann sich ein Audit lohnt
• Die Auditmethoden und was jede davon aufdeckt
• Was innerhalb einer Webanwendung untersucht werden sollte
• Wie das Audit Schritt für Schritt abläuft
• Wie ein guter Auditbericht aussieht
• Was ein Audit nicht aussagen kann
• Messen, ob die Änderungen Wirkung gezeigt haben
• UX-Audit-Leistungen für ein Produktteam auswählen
• Die Zusammenarbeit mit Ridiculous Engineering
• Häufig gestellte Fragen
• Fazit
• Quellen

Was ein UX-Audit einer Webanwendung bewertet

Ein UX-Audit ist eine systematische Bewertung der Benutzererfahrung einer digitalen Plattform, um Probleme zu erkennen, die Benutzerfreundlichkeit einzuschätzen und Verbesserungen zu empfehlen. Dabei werden Benutzeroberfläche, Funktionalität und Inhalte anhand etablierter Prinzipien der Benutzerfreundlichkeit sowie der Erwartungen der Nutzer untersucht, wie in UX-Richtlinien der Regierung beschrieben. Zu den möglichen Dimensionen gehören Barrierefreiheit, Benutzerfreundlichkeit, Informationsarchitektur, Performance und Oberflächengestaltung.

Bei einer Produktoberfläche ist es hilfreich, diese Dimensionen in die Fragen zu übersetzen, die Ihre Nutzer tatsächlich stellen:

• Kann ein neuer Nutzer ohne Hilfe sein erstes nützliches Ergebnis erreichen?
• Kann ein erfahrener Nutzer dieselbe Aufgabe zum fünfzigsten Mal ohne Reibungsverluste erledigen?
• Wenn etwas schiefläuft: Sagt das System, was passiert ist und was als Nächstes zu tun ist?
• Können Nutzerinnen und Nutzer die bereits vorhandene Funktion finden?
• Sind die Daten auf dem Bildschirm lesbar, vertrauenswürdig und handlungsrelevant?

Ein UX-Audit einer Web-App ist weder ein visuelles Redesign noch ein Code-Review. Es liegt zwischen beidem. Es zeigt Ihnen, welche Teile des Nutzungserlebnisses Sie Nutzer, Zeit und Supportaufwand kosten, und gibt Design und Engineering eine gemeinsame Arbeitsliste an die Hand.

Worin sich ein Produktaudit von einem Website-Audit unterscheidet

Bei einem Audit einer Marketing-Website geht es darum, ob eine fremde Person das Angebot versteht und klickt. Bei einem Produktaudit geht es darum, ob ein engagierter Nutzer, der sich bereits registriert hat oder dem sein Arbeitgeber das Tool zugewiesen hat, seine Arbeit erledigen kann. Die Unterschiede zeigen sich an fünf Stellen.

Die letzte Zeile ist am wichtigsten. Auditoren betrachten häufig Kennzahlen wie Traffic, Engagement, Conversion-Raten und Kundenbindung, aber bei einer App sagen Kundenbindung und Engagement auf Funktionsebene wesentlich mehr aus als Besuche. Ein Nutzer, der sich jeden Tag anmeldet und Daten in eine Tabelle exportiert, um die Aufgabe abzuschließen, ist ein Befund, auch wenn Ihre Analysen ihn als loyalen Nutzer zählen.

Nutzerrollen fügen eine weitere Ebene hinzu. Ein Administrator, ein Standardnutzer und ein Stakeholder mit Leserechten sehen möglicherweise drei verschiedene Produkte. Ein sorgfältiges Audit berücksichtigt jede Rolle, denn die Probleme der einen Rolle zeigen sich nur selten in den Ansichten einer anderen.

Wann sich ein Audit lohnt

Teams führen Audits durch, um Usability-Probleme zu finden, Zufriedenheit und Barrierefreiheit zu verbessern und Geschäftsziele wie Engagement zu unterstützen. Regelmäßige Audits helfen einem Produkt außerdem, mit sich wandelnden NutzerbedürfnissenSchritt zu halten. In der Praxis sehen wir am häufigsten folgende Auslöser:

• Die Nutzung liegt unter dem, was die Geschäftsplanung angenommen hatte. Lizenzen wurden gekauft oder Konten erstellt, und die Menschen nutzen das Tool nicht.
• Supporttickets häufen sich bei denselben Bildschirmen. Dieselbe Frage, die zwanzigmal pro Woche gestellt wird, ist ein Designproblem und kein Schulungsproblem.
• Eine funktionsreiche Veröffentlichung hat die Kennzahlen nicht verbessert. Die Nutzung stagniert, und niemand kann sagen, warum.
• Ein Redesign oder eine Neuentwicklung steht zur Debatte. Ein Leitfaden empfiehlt ein Audit vor einer Neugestaltung um Herausforderungen der Nutzer zu erkennen und festzulegen, worauf sich die Nutzerforschung konzentrieren sollte. Das gilt umso mehr für Apps, bei denen ein Neuaufbau teuer ist und die alte Oberfläche Geschäftsregeln verbirgt, die niemand dokumentiert hat.
• Beim Onboarding gehen Nutzer verloren. Neue Konten werden angelegt, erreichen aber nie die erste relevante Aktion.
• Beschwerden über interne Tools sind zum geflügelten Wort geworden. Mitarbeitende erstellen Tabellen und Nebenprozesse, um das offizielle System zu umgehen.

Was die Frequenz betrifft, empfiehlt eine Quelle eine vollständige UX-Überprüfung mindestens einmal jährlich, wobei Teams, die sehr schnell ausliefern, möglicherweise alle drei Monate eine Prüfung durchführen sollten. Diese Zahlen stammen aus den Empfehlungen eines Anbieters und nicht aus einem Standard. Betrachten Sie sie daher als sinnvollen Ausgangsrhythmus. Für die meisten Teams ist eine jährliche vollständige Prüfung plus eine schlanke Überprüfung jedes Bereichs, den Sie wesentlich ändern, ein gut vertretbarer Plan.

Die Prüfmethoden und was jede davon erfasst

Keine einzelne Methode reicht aus. Verwenden Sie mindestens drei und kennen Sie die jeweiligen blinden Flecken.

Heuristische Evaluation

Bei einer heuristischen Evaluation durchlaufen ein oder mehrere erfahrene Prüfende die Oberfläche anhand anerkannter Prinzipien der Gebrauchstauglichkeit und dokumentieren jeden festgestellten Verstoß. Die Methode ist schnell, erfordert keine Rekrutierung und eignet sich gut, um Inkonsistenzen, unklare Bezeichnungen, fehlendes Feedback und Sackgassen zu erkennen. Ihre Schwäche besteht darin, dass sie Expertenurteile und nicht das tatsächliche Verhalten der Nutzer widerspiegelt. Prüfende können Problemen zu viel Gewicht geben, die Nutzer tolerieren, und domänenspezifische Unklarheiten übersehen, auf die nur echte Praktiker stoßen würden.

Bei Apps sollten Sie die Prüfenden anweisen, reale Szenarien durchzuspielen und nicht nur einzelne Bildschirme zu betrachten. Eine Einstellungsseite isoliert zu prüfen, sagt wenig aus. „Einen Teamkollegen einladen und ihm Nur-Lese-Zugriff geben“ zu prüfen, sagt dagegen sehr viel aus.

Verhaltens- und Analyseprüfung

Quantitative Daten zeigen, wo das Verhalten von der Absicht abweicht: Abbrüche im Onboarding-Trichter, Funktionen, die niemand nutzt, Suchen ohne Treffer, Wutklicks, wiederholte Formularfehler und Exporte, die darauf hindeuten, dass der Bildschirm die Frage nicht beantwortet hat. Sie zeigen Ihnen, wo Sie suchen sollten. Warum das so ist, verraten sie nicht – deshalb werden sie mit der nächsten Methode kombiniert.

Usability-Tests

Bei Usability-Tests bearbeiten echte Nutzer mit dem Produkt realistische Aufgaben. Schon wenige Sitzungen können Hypothesen aus der heuristischen Prüfung bestätigen oder widerlegen und Probleme aufdecken, die kein Experte vorhergesehen hätte. Ein UX-Audit-Leitfaden, der den Prozess abdeckt, beschreibt, wie Sie Ziele und Umfang festlegen, qualitative und quantitative Daten sammeln, Gebrauchstauglichkeit und Barrierefreiheit bewerten und Nutzertests durchführen bevor Sie die Ergebnisse zusammenstellen und priorisieren. Rekrutieren Sie Personen aus Ihren tatsächlichen Rollen und nicht Kollegen, die das Produkt bereits kennen.

Hinweise aus Support und Vertrieb

Dies ist der kostengünstigste und am wenigsten genutzte Input. Kennzeichnen Sie einen Monat lang Support-Tickets nach Bildschirm und Aufgabe. Fragen Sie den Customer Success, welche drei Dinge sie in jedem Onboarding-Gespräch erklären. Fragen Sie den Vertrieb, welche Demo-Bildschirme er vermeidet. Diese Liste ist oft die beste Ausgangshypothese für die Prüfung.

Was Sie in einer Webanwendung prüfen sollten

Das ist der Teil, den allgemeine Checklisten auslassen. Im Folgenden finden Sie die UX-Audit-Checkliste, die wir für eine Produktschnittstelle verwenden würden, geordnet nach den Bereichen, in denen Apps typischerweise Schwachstellen aufweisen.

Onboarding und erste Nutzung

• Weiß der Nutzer innerhalb der ersten Minute, was zu tun ist, und gibt es eine klare erste Aktion?
• Wird die Zeit bis zum ersten Mehrwert gemessen, und ist sie kurz genug für die Geduld Ihrer Nutzer?
• Sind die Einrichtungsschritte nach Abhängigkeiten geordnet, oder werden Informationen abgefragt, die Nutzer noch nicht haben?
• Können Personen die optionale Einrichtung überspringen und später fortsetzen, wobei der Fortschritt gespeichert wird?
• Erhalten eingeladene Nutzer, die das Tool nicht selbst ausgewählt haben, einen anderen Ablauf als der Kontoinhaber?

Navigation und Informationsarchitektur

• Entsprechen die Menübezeichnungen den Begriffen der Nutzer oder den Bezeichnungen, die die Entwicklung den Modulen gegeben hat?
• Können Nutzer erkennen, wo sie sich befinden, wie sie dorthin gelangt sind und wie sie zurückkehren?
• Sind häufige Aufgaben in wenigen Schritten erreichbar, während seltene oder gefährliche Aufgaben angemessen verborgen sind?
• Funktioniert die Suche für die Objekte, nach denen Nutzer tatsächlich suchen?
• Werden Funktionen aufgrund von Berechtigungen sauber ausgeblendet, oder sehen Nutzer Schaltflächen, die zu „Zugriff verweigert“ führen?

Dashboards

• Beantwortet jedes Dashboard eine konkrete Frage oder zeigt es lediglich alles an, was verfügbar ist?
• Sind die für Entscheidungen relevantesten Zahlen am prominentesten dargestellt?
• Sind Zeiträume, Filter und Vergleiche offensichtlich, und bleiben sie erhalten, wenn Nutzer die Seite verlassen und zurückkehren?
• Kann ein Benutzer in einem Schritt von einer Zahl zu den zugrunde liegenden Datensätzen gelangen?
• Sind die Einheiten in Diagrammen beschriftet, und ist Farbe nicht die einzige Möglichkeit, Reihen zu unterscheiden?

Wenn Ihre Dashboards langsam oder inkonsistent sind, weil die Datenschicht aus einem Flickwerk besteht, kann die Lösung teilweise im Datenmodell statt in der Benutzeroberfläche liegen. Dort überschneiden sich Datenanalyse und Business Intelligence mit UX.

Datentabellen

• Können Benutzer Ansichten sortieren, filtern, durchsuchen und speichern, und gibt es dort, wo sie benötigt werden, Sammelaktionen?
• Sind Auswahl und Reihenfolge der Spalten für die Hauptaufgabe sinnvoll, mit fixierten Kopfzeilen und Kennungen in langen Tabellen?
• Wie verhält sich die Tabelle bei 5 Zeilen, 5.000 Zeilen und null Zeilen?
• Ist die Inline-Bearbeitung vorhersehbar, mit eindeutigem Verhalten beim Speichern und Rückgängigmachen?
• Entsprechen Exporte dem, was der Benutzer auf dem Bildschirm sieht?

Komplexe Formulare

• Sind die Felder logisch gruppiert und nur die notwendigen Felder als Pflichtfelder markiert?
• Erfolgt die Validierung unmittelbar und spezifisch neben dem Feld und in allgemein verständlicher Sprache?
• Bleiben die Eingaben des Benutzers erhalten, wenn das Absenden fehlschlägt?
• Speichern lange Formulare Entwürfe, und können mehrstufige Formulare später fortgesetzt werden?
• Kann das Formular ausschließlich per Tastatur ausgefüllt werden, und sind die Beschriftungen programmatisch mit den Feldern verknüpft?

Fehlerzustände

• Gibt jeder Fehler an, was passiert ist, warum es passiert ist und was als Nächstes zu tun ist?
• Werden destruktive Aktionen mit konkreten Angaben bestätigt, und gibt es, sofern möglich, eine Rückgängig-Funktion?
• Sehen Systemfehler (Zeitüberschreitungen, fehlende Berechtigungen, Synchronisierungsprobleme) anders aus als Fehler des Benutzers?
• Gibt es direkt aus dem Fehler heraus einen Weg zur Hilfe, wobei der Kontext übermittelt wird?

Leere Zustände

• Erklärt ein neuer, leerer Bildschirm, was dort erscheinen wird und wie Inhalte hinzugefügt werden?
• Wird zwischen „keine Ergebnisse“, „wird noch geladen“ und „Laden fehlgeschlagen“ unterschieden?
• Bieten leere Zustände eine eindeutige nächste Aktion statt eines leeren Rasters?

Barrierefreiheit

Barrierefreiheit gehört von Anfang an in die Prüfung und nicht erst zu einem abschließenden Durchgang. Behalten Sie eine Einschränkung im Hinterkopf: kein einzelnes Tool kann feststellen, ob eine Website die Barrierefreiheitsstandards erfüllt, und eine sachkundige menschliche Bewertung ist erforderlich. Automatisierte Scanner erfassen einen nützlichen Teil der Probleme, etwa fehlende Beschriftungen und Kontrastfehler. Sie können nicht feststellen, ob ein Benutzer eines Screenreaders einen mehrstufigen Ablauf abschließen kann. Hintergrundinformationen dazu, wie digitale Angebote für alle nutzbar werden, finden Sie in dieser Übersicht zur digitalen Barrierefreiheit einer Website. Unsere eigenen Ausführungen zu barrierefreiem Webdesign für eine inklusive digitale Welt gehen stärker auf die Designseite ein.

So läuft die Prüfung Schritt für Schritt ab

1. Ziele und Umfang festlegen. Wählen Sie die Geschäftsergebnisse aus (Aktivierung, Aufgabenabschluss, weniger Supportanfragen) sowie die Abläufe, die diese vorantreiben. Eine vollständige Prüfung eines großen Produkts ist selten sinnvoll. Beginnen Sie mit den drei bis fünf wichtigsten Abläufen.
2. Belege zusammentragen. Tragen Sie Analysedaten, Supportanfragen, Sitzungsaufzeichnungen, sofern vorhanden, frühere Untersuchungen und die ursprünglichen Anforderungen zusammen. Befragen Sie zwei oder drei interne Personen, die täglich von Beschwerden der Benutzer erfahren.
3. Rollen und Szenarien definieren. Listen Sie die Benutzerrollen und die tatsächlichen Aufgaben auf, die jede Rolle ausführt. Daraus werden die Testszenarien.
4. Führen Sie die Expertenprüfung durch. Gehen Sie jedes Szenario mit den Heuristiken zur Hand durch. Erfassen Sie Screenshots, die genauen Schritte und das verletzte Prinzip.
5. Testen Sie mit Benutzern. Führen Sie moderierte Sitzungen zu den riskantesten Abläufen durch. Halten Sie Beobachtungen fest, die Bearbeitungszeit, Fehler und Abbruchpunkte.
6. Führen Sie die Ergebnisse zusammen und priorisieren Sie sie. Führen Sie die Ergebnisse zusammen, entfernen Sie Duplikate und bewerten Sie jedes nach Auswirkung und Machbarkeit – so, wie es offizielle Leitlinien zur Priorisierung empfehlen.
7. Erstellen Sie eine Roadmap. Ein nützlicher Bericht zeigt Verbesserungsbereiche auf und liefert eine Roadmap, statt nur eine Liste von Beschwerden zu enthalten.

So sieht ein guter Auditbericht aus

Ein Bericht, der in einem gemeinsamen Laufwerk liegt, hilft niemandem. Achten Sie auf diese Elemente:

• Eine Zusammenfassung für die Führungsebene mit den fünf oder sechs wichtigsten Erkenntnissen und dem jeweiligen Geschäftsrisiko.
• Erkenntnisse mit Belegen. Jede Erkenntnis enthält einen Screenshot, die betroffene Rolle und Aufgabe, den zugrunde liegenden Datenpunkt oder die Testbeobachtung sowie eine Bewertung des Schweregrads.
• Konkrete Empfehlungen, so formuliert, dass sowohl ein Designer als auch ein Entwickler danach handeln können – nicht etwa „die Navigation verbessern“.
• Ein priorisierter Backlog der schnelle Verbesserungen (Texte, Bezeichnungen, Validierungsmeldungen) von strukturellen Arbeiten (eine Tabellenkomponente neu erstellen, das Onboarding überarbeiten) trennt.
• Erfolgsmetriken für jede Empfehlung, sodass die Nachverfolgung messbar wird.

Eine einfache Matrix eignet sich gut. Tragen Sie jede Erkenntnis nach ihrem Einfluss auf die Benutzer und dem erforderlichen Aufwand ein. Hoher Einfluss und geringer Aufwand werden in diesem Sprint umgesetzt. Hoher Einfluss und hoher Aufwand werden zu einem abgegrenzten Projekt. Geringer Einfluss und hoher Aufwand werden konsequenterweise verworfen.

Was ein Audit Ihnen nicht sagen kann

Ein Audit hat Grenzen, und ein guter Anbieter wird das offen sagen. Tests während der Entwicklung sind nur begrenzt geeignet, aufzuzeigen, wie ein Produkt in der realen Welt abschneidet, insbesondere bei Tausenden oder Millionen täglicher Benutzer. Ein Usability-Test mit acht Teilnehmern wird nicht den Sonderfall aufdecken, der nur bei einem Konto mit 40.000 Datensätzen und einem benutzerdefinierten Berechtigungssatz auftritt. Deshalb gehören Analyse- und Supportdaten ebenfalls in die Betrachtung.

Ein Audit kann auch kein Problem der Produktstrategie lösen. Wenn die App ein Problem löst, das Benutzer gar nicht haben, werden bessere Formulare sie nicht retten. Ebenso kann es Ihnen nicht mit Sicherheit sagen, was Sie als Nächstes entwickeln sollten: Es zeigt Ihnen, wo die aktuelle Erfahrung scheitert. Schließlich verändert das Audit von selbst nichts. Sein Wert hängt vollständig davon ab, was Ihr Team mit den Erkenntnissen macht.

Messen, ob die Verbesserungen funktioniert haben

Die meisten Audits enden mit dem Bericht, wodurch die wichtigste Frage unbeantwortet bleibt: Ist die Nutzungserfahrung besser geworden? Legen Sie fest, woran Sie das erkennen, bevor Sie auch nur eine einzige Änderung veröffentlichen.

• Erfassen Sie zuerst einen Ausgangswert. Halten Sie die Kennzahlen für jeden geprüften Ablauf vor jeder Verbesserung fest: Abschlussrate der Aufgabe, Bearbeitungszeit, Fehlerquote, Abschluss des Onboardings, Nutzung der Funktion und das Volumen zugehöriger Supporttickets. Dieselben Messgrößen, die ein Auditor zur Ermittlung von Problemen verwendet, nutzen Sie auch, um zu bestätigen, dass diese behoben sind.
• Verknüpfen Sie jede Verbesserung mit einer Kennzahl. Wenn Sie die Formularvalidierung neu formuliert haben, beobachten Sie die Fehlerraten in Formularen und abgebrochene Übermittlungen. Wenn Sie die Navigation neu strukturiert haben, beobachten Sie, wie lange Benutzer brauchen, um die Funktion zu finden, und ob die Suchanfragen danach zurückgehen.
• Führen Sie dieselben Testaufgaben erneut durch. Geben Sie neuen Teilnehmenden dieselben Szenarien wie im Audit und vergleichen Sie die Ergebnisse. Das ist der sauberste Vorher-Nachher-Nachweis, den Sie erhalten können.
• Beobachten Sie die Support-Tickets nach Thema. Ein Rückgang der Tickets zu einem bestimmten Bildschirm ist ein starkes Signal, da er echte Nutzer mit echten Problemen widerspiegelt.
• Führen Sie die Änderungen nach Möglichkeit schrittweise ein. Wenn Sie eine Änderung zunächst nur für einen Teil der Konten freischalten, können Sie das Verhalten direkt vergleichen und Regressionen frühzeitig erkennen.
• Planen Sie Zeit ein, damit sich Gewohnheiten ändern können. Erfahrene Nutzer arbeiten nach einer Änderung möglicherweise zunächst langsamer, selbst wenn das neue Design besser ist. Vergleichen Sie über mehrere Wochen statt über wenige Tage.

Seien Sie bei der Zuordnung der Ursachen ehrlich. Wenn eine Preisänderung und eine Neugestaltung im selben Monat eingeführt wurden, können Sie nicht einer der beiden Änderungen die Veränderung der Kundenbindung zuschreiben. Zeitlich gestaffelte Veröffentlichungen und ein klarer Änderungsverlauf machen Ihre Schlussfolgerungen verlässlicher.

UX-Audit-Dienstleistungen für ein Produktteam auswählen

Bei der Bewertung von UX-Audit-Dienstleistungen sind die Fragen, die einen produktkundigen Prüfer von einem Generalisten unterscheiden, praxisnah:

• Haben sie authentifizierte Anwendungen mit Rollen, Berechtigungen und umfangreichen Daten geprüft – nicht nur öffentliche Websites?
• Werden sie echte Aufgabenabläufe mit Ihren Nutzern prüfen oder nur Screenshots?
• Setzen sie heuristische Evaluation und Usability-Tests gemeinsam mit Ihren Analysedaten ein?
• Wird die Barrierefreiheit von Menschen bewertet und nicht nur durch einen Scanner-Bericht?
• Wird der Bericht so aufbereitet, dass Entwickler direkt damit arbeiten können, einschließlich Schweregrad, Nachweisen und Messwerten?
• Kann dasselbe Team bei der Umsetzung der Korrekturen helfen oder zumindest beratend unterstützen, während Ihre Entwickler sie umsetzen?

An diesem letzten Punkt scheitern viele Audits. Ein rein auf Design ausgerichteter Prüfer übergibt möglicherweise Empfehlungen, die Ihre Architektur außer Acht lassen, während ein rein technisches Team die menschlichen Reibungspunkte übersehen kann. Wir versuchen, diese Lücke zu schließen, indem wir Design und Engineering verbinden, sodass die Empfehlungen berücksichtigen, was in Ihrer Codebasis umsetzbar ist. Weitere Informationen finden Sie in unseren UI/UX-Design- und Barrierefreiheitsdienstleistungen für Produktteams sowie in unserem Beitrag zur Abstimmung von Entwicklung und Design und erfahren dort, wie wir verhindern, dass Erkenntnisse zwischen den Disziplinen ins Stocken geraten.

Zusammenarbeit mit Ridiculous Engineering

Ridiculous Engineering ist eine Softwareentwicklungsberatung mit Sitz in Colorado. Kunden arbeiten direkt mit erfahrenen Ingenieuren, und unser Team vereint UX-Design, Lösungsarchitektur, Geschäftsanalyse und Produktmanagement. Wenn Ihr Audit auf strukturelle Korrekturen hindeutet, etwa den Neubau eines umständlichen internen Tools, die Überarbeitung der Datenschicht eines Dashboards oder die Modernisierung einer veralteten Anwendung, können wir Sie mit individueller Softwareentwicklung und Softwareberatung und Unterstützung bei der Umsetzunghelfen. Die Preise hängen vom Umfang ab. Der praktische erste Schritt besteht daher darin, mit uns über Ihre Anwendung zu sprechen und uns mitzuteilen, wo Nutzer Schwierigkeiten haben.

Häufig gestellte Fragen

Wie lange dauert ein UX-Audit für eine Webanwendung?

Das hängt davon ab, wie viele Abläufe und Nutzerrollen zum Umfang gehören. Eine fokussierte Prüfung von drei bis fünf kritischen Abläufen ist deutlich schneller als ein Audit des gesamten Produkts, und bei Nutzertests kommt für die Rekrutierung der Teilnehmenden zusätzlicher Zeitaufwand für die Terminplanung hinzu. Legen Sie zunächst den Umfang fest und bitten Sie den Anbieter um einen darauf abgestimmten Zeitplan.

Ist ein UX-Audit dasselbe wie ein Usability-Test?

Nein. Usability-Tests sind eine Methode innerhalb eines Audits: Echte Nutzer versuchen, realistische Aufgaben zu erledigen, während Sie sie beobachten. Ein vollständiges Audit umfasst außerdem eine heuristische Expertenevaluation, die Prüfung von Analyse- und Supportdaten sowie eine Barrierefreiheitsprüfung und führt anschließend alle Ergebnisse zu priorisierten Empfehlungen zusammen.

Können automatisierte Tools für uns ein UX-Audit durchführen?

Sie können einige Probleme erkennen, etwa Kontrastfehler oder fehlende Beschriftungen, und sind als eine Informationsquelle nützlich. Sie können nicht beurteilen, ob Ihre Arbeitsabläufe sinnvoll sind, und kein einzelnes Tool kann die Einhaltung der Barrierefreiheitsanforderungen bestätigen. Eine Prüfung durch Menschen ist weiterhin erforderlich.

Sollten wir vor oder nach einer Neugestaltung ein Audit durchführen?

Vorher. Ein Audit zeigt, welche Probleme tatsächlich bestehen und welche Teile der aktuellen Benutzeroberfläche bereits funktionieren. So bauen Sie keine guten Bestandteile neu auf und übernehmen keine problematischen Teile in die nächste Version. Außerdem erhalten Sie eine Ausgangsbasis, an der Sie die neue Version messen können.

Fazit

Ein UX-Audit für Webanwendungen lohnt sich, wenn es auf die richtigen Bereiche ausgerichtet ist: Onboarding, Navigation, Dashboards, Datentabellen, Formulare sowie Fehler- und leere Zustände. Kombinieren Sie eine heuristische Evaluation, Verhaltensdaten und Usability-Tests, priorisieren Sie nach Auswirkung und Machbarkeit und legen Sie Metriken fest, bevor Sie die Anpassungen veröffentlichen. Wiederholen Sie die Prüfung anschließend regelmäßig, damit das Produkt mit den Menschen Schritt hält, die es nutzen.

Quellen

• UI/UX-Richtlinien: UX-Audits durchführen
• Der unverzichtbare Leitfaden für UX-Audits (Dovetail)
• UX-Audit-Checkliste: 7 Schritte zu besserer UX (Maze)
• So führen Sie ein UX-Audit durch (HubSpot)
• UX-Audit: Alles, was Sie wissen müssen (UXPin)
• So führen Sie ein UX-Audit durch: eine Schritt-für-Schritt-Anleitung (Justinmind)
• Überblick zur Bewertung der Barrierefreiheit im Web (W3C WAI)

Empfohlen

• Sichere Entwicklung von KI-Anwendungen: Ein praxisorientierter Leitfaden
• Tipps für die Abstimmung von Entwicklung und Design
• Checkliste für den Website-Relaunch: Neugestaltung ohne Traffic-Verlust