Geschrieben von
Claudia Monstein
Technologie & Entwicklung
19.8.2026

Anforderungen validieren: Erst testen, dann entwickeln (5/5)

Im letzten Blogartikel «Anforderungen visualisieren: Von der Idee zum klickbaren Prototyp» beschrieben wir, wie wir Anforderung visualisieren. In diesem Artikel geht es nun darum, die visualisierten Anforderungen zu validieren, damit wir auch einen echten Mehrwert liefern und allfällige Usability Stolpersteine noch vor der Entwicklung (Software Development Phase) entdecken.

Anforderungen zu erheben und zu visualisieren ist wichtig. Noch wichtiger ist jedoch die Frage: Lösen wir damit wirklich das richtige Problem? Und wird die angedachte Lösung von den Benutzer:innen auch verstanden?

Genau hier setzt die Validierung an. Bevor Zeit und Budget in die Entwicklung investiert werden, sollte überprüft werden, ob die geplante Lösung die Bedürfnisse der späteren Nutzenden tatsächlich erfüllt.

Je früher Feedback eingeholt wird, desto einfacher und günstiger lassen sich Anpassungen vornehmen.

Einen Test gut vorbereiten

Ein erfolgreicher Usability-Test beginnt lange vor dem eigentlichen Test.

Zunächst sollte klar definiert werden, was überhaupt überprüft werden soll.

Dabei helfen Fragen wie:

  • Was ist die Testhypothese, was möchten wir mit dem Test herausfinden?
  • Welche Anforderungen möchten wir validieren?
  • Welche Aufgaben sollen die Testpersonen lösen?
  • Mit welchen Personen möchten wir testen?
  • Soll ein Mockup, ein klickbarer Prototyp oder bereits eine Anwendung getestet werden?
  • Werden verschiedene Varianten miteinander verglichen?
  • Findet der Test vor Ort oder remote statt?


Je klarer die Ziele formuliert sind, desto aussagekräftiger werden die Ergebnisse.

Ein realistisches Testszenario erstellen

Menschen testen keine Funktionen. Sie erledigen Aufgaben. Deshalb sollten Testpersonen immer ein realistisches Szenario erhalten. Das hilft auch die Testsituation so realitätsnah wie möglich zu gestalten und dadurch auch echte und relevante Erkenntnisse für den späteren Betrieb zu erhalten.

Zum Beispiel:

"Sie möchten einen Termin vereinbaren. Wie würden Sie dabei vorgehen?"

Solche Aufgaben zeigen viel besser, ob eine Lösung verständlich und intuitiv nutzbar ist, als wenn einzelne Funktionen einer Anwendung erklärt werden. Denn wie Steven Krug sagte:

«Benutzeroberflächen sind wie Witze: Wenn du sie erklären musst, sind sie nicht besonders gut.»

Zu Beginn eines Usability Tests reicht meist der sogenannte «Happy Flow», also das Testen des häufigsten Anwendungsfalls. Sonderfälle und Fehlersituationen können später ergänzt und getestet werden. Wenn eine Funktion im Prototyp noch nicht umgesetzt bzw. verfügbar ist, dann reicht ein kurzer und freundlicher Hinweis durch die Testkoordinator:in. So bleiben Testpersonen im Ablauf und verstehen, dass der Prototyp noch nicht vollständig ist.

Der Testleitfaden beeinflusst das Ergebnis

Wer Usability-Tests leitet, sollte mehr beobachten als erklären. Fragen sollten möglichst neutral formuliert sein. Sie dürfen keine Lösung vorgeben und keine Begriffe verwenden, die bereits auf der Benutzeroberfläche stehen.

Statt zu fragen:

"Haben Sie den Speichern-Button gefunden?"

ist es besser zu fragen:

"Wie würden Sie jetzt weiter vorgehen?"

So zeigt sich, ob die Navigation tatsächlich verständlich ist.

Ebenso wichtig ist es, die Sprache der späteren Nutzenden zu verwenden und ganz genau hinzuhören, welche Formulierungen die Testpersonen verwenden, wenn Sie ihr Vorgehen beschreiben oder die Anwendung kommentieren. Fachbegriffe aus dem Projekt helfen selten weiter.

Walkthrough: Gemeinsam Lösungen verbessern

Ein Walkthrough eignet sich besonders gut in frühen Projektphasen. Dabei geht die Testleiter:in zusammen mit benutzernahen oder echten Endnutzer:innen den Ablauf der Anwendung durch. Endnutzer:innen können direkt Fragen stellen und  Ideen können gemeinsam diskutiert werden. Das Ziel besteht darin, Schwachstellen möglichst früh zu erkennen und Anforderungen weiter zu verbessern.

Ein gemeinsaer Walkthrough hat sowohl Vor- als auch Nachteile: Ein Walkthrough kann zwar bereits mit einfachen Skizzen oder ersten Prototypen durchgeführt werden, was frühe Erkenntnisse liefert. Andererseit beeinflusst die Testleiter:in den Ablauf stärker, was die Erkenntnisse verfälschen kann. Deshalb sollte die Testleiter:in bewusst zurückhaltend moderieren.

Usability Tests: Funktioniert die Lösung wirklich?

Beim Usability Test wird die Lösung möglichst realitätsnah überprüft. Die Testpersonen bearbeiten typische Aufgaben, die die Anwendung abbildet, selbstständig, während der Testleiter hauptsächlich beobachtet und nur durch die Aufgaben führt.

Besonders wertvoll sind Beobachter:innen, die den Test mitverfolgen und ihre Erkenntnisse notieren. Fragen sollten jedoch erst nach Abschluss des Tests gestellt werden.
Wichtig ist auch die Auswahl der richtigen Testpersonen. Je besser sie den späteren Endnutzer:innen entsprechen, desto aussagekräftiger sind die Ergebnisse.

Eine bewährte Methode ist das sogenannte Laut-Denken. Dabei sprechen Testpersonen ihre Gedanken während der Bedienung und während der Ausführung ihrer Aufgaben aus. So wird sichtbar, welche Überlegungen hinter ihren Entscheidungen stehen und an welchen Stellen Unsicherheiten entstehen.

Bei der Auswertung eines Usability-Tests hilft ein strukturiertes Vorgehen. Bewährt hat sich beispielsweise eine Excel-Tabelle, in der für alle Testpersonen die Ergebnisse pro Aufgabe inklusive Angaben zur Aufgabenerfüllung erfasst werden. Werden diese Ergebnisse über alle Teilnehmenden hinweg zusammengeführt, entsteht eine übersichtliche Grundlage, um Usability-Probleme und wiederkehrende Stolpersteine in einzelnen Funktionen gezielt zu identifizieren.

Abbildung 1: Auswertung der Taskerfüllung eines Usability-Tests

A/B Tests: Zwei Lösungen im direkten Vergleich

Nicht jede Designfrage lässt sich durch einen Workshop beantworten. Gibt es mehrere überzeugende Lösungsansätze, hilft ein A/B-Test: Unterschiedliche Benutzergruppen erhalten verschiedene Varianten einer Funktion, anschliessend wird gemessen, welche Lösung die besseren Ergebnisse erzielt. Um statistisch signifikante Resultate zu erhalten, ist hier jedoch meist ein grosser Pool an Tester:innen notwendig. Oft wird dies auch im Live-Betrieb gemacht bei Anwendungen, die kontinuerlich verbessert werden sollen, z.B. zur Optimierung der Conversion oder Kaufabschlüsse.

Für kleinere Fragestellungen reicht oft ein einfacherer Ansatz. Nach einem Usability-Test können Testpersonen zwei Varianten gezeigt werden, um im anschliessenden Gespräch herauszufinden, welche Lösung sie bevorzugen und warum.

Benutzbarkeit messbar machen

Nach Usability-Tests, helfen standardisierte Fragebögen dabei, die Benutzererfahrung objektiv zu bewerten. In den folgenden Abschnitten zeigen wir einige solcher Auswertungsmöglichkeiten auf.

System Usability Scale (SUS)

Die System Usability Scale, kurz SUS, gehört zu den bekanntesten Verfahren zur Bewertung der Benutzbarkeit.

Nach dem Test beantworten die Teilnehmenden zehn kurze Fragen. Daraus entsteht ein Gesamtwert, mit dem sich verschiedene Versionen einer Anwendung vergleichen lassen. SUS eignet sich besonders gut, um Verbesserungen über mehrere Iterationen und Verbesserungszyklen der Anwendung hinweg sichtbar zu machen. Wichtig dabei ist auch festzulegen wie hoch der SUS Score sein soll, damit es gut genug ist.

User Experience Questionnaire (UEQ)

Während SUS die Benutzbarkeit bewertet, betrachtet der User Experience Questionnaire zusätzlich die emotionale Wahrnehmung einer Anwendung.

Die Teilnehmenden beurteilen Eigenschaften wie Verständlichkeit, Effizienz oder Attraktivität. Neben der ausführlichen Version mit 26 Aussagen existiert auch eine kompakte Kurzversion.

Gerade bei der Weiterentwicklung eines Produkts liefert der UEQ wertvolle Hinweise zur Benutzererfahrung.

Customer Satisfaction Score (CSAT)

Der Customer Satisfaction Score misst die allgemeine Zufriedenheit. Nach einer Aufgabe oder einem Usability-Test beantworten die Teilnehmenden eine einfache Frage auf einer Skala von sehr unzufrieden bis sehr zufrieden.

Der CSAT eignet sich besonders gut, um schnell ein Stimmungsbild zu erhalten und verschiedene Versionen miteinander zu vergleichen.

Fazit

Anforderungen zu validieren bedeutet, Annahmen durch echtes Nutzerfeedback zu ersetzen.

Ob Walkthrough, Usability-Test oder A/B Test: Jede Methode hilft dabei, Unsicherheiten früh zu erkennen und Anforderungen gezielt weiterzuentwickeln. Die besten Erkenntnisse entstehen dabei nicht durch Diskussionen im Projektteam, sondern durch das Beobachten der späteren Nutzenden, die einen Prototypen der vorgesehene Lösung mittels einer realitätsnahen Aufgabe testen.

Je früher getestet wird, desto günstiger lassen sich Änderungen umsetzen. Genau deshalb sollte Validierung nicht am Ende eines Projekts stattfinden, sondern den gesamten Entwicklungsprozess begleiten.

Wenn du mehr über unseren gesamten  RE-Prozess erfahren möchtest, schau dir die anderen Artikel dieser Blogserie an:

Das könnte dich ebenfalls interessieren

chevron-right
Anforderungen visualisieren: Von der Idee zum klickbaren Prototyp (4/5)
Im letzten Blogartikel «Anforderungen spezifizieren: Die richtige Methode zur richten Zeit» beschrieben wir, wie wir Anforderung spezifizieren. In diesem Artikel geht es nun darum, die spezifizierten Anforderungen zu visualisieren damit wir sie mit echten Benutzenden testen und validieren können, bevor Software entwickelt wird.
Claudia Monstein
chevron-right
Anforderungen spezifizieren: Die richtige Methode zur richtigen Zeit (3/5)
Im letzten Blogartikel «Anforderungen erheben und priorisieren. Oder: System statt Wunschkonzert» beschrieben wir, wie wir Anforderungen erheben und priorisieren. In diesem Artikel geht es nun darum, die priorisierten Anforderungen detaillierter zu spezifizieren.
Claudia Monstein
chevron-right
Anforderungen erheben und priorisieren. Oder: System statt Wunschkonzert (2/5)
Am Anfang eines Softwareprojekts stehen oft viele Ideen, Wünsche und Anforderungen im Raum. Klingt gut, kann aber schnell unübersichtlich werden. Denn nicht jede Anforderung bringt automatisch Mehrwert. Und nicht jede gute Idee funktioniert später auch im Alltag. Gerade im Gesundheitswesen treffen unterschiedliche Bedürfnisse, komplexe Prozesse und klare Rahmenbedingungen aufeinander. Deshalb geht es im Requirement Engineering darum, die richtigen Fragen zu stellen, Annahmen früh zu prüfen und gemeinsam herauszufinden, was wirklich hilft. So entsteht Software, die einen echten Unterschied macht.
Claudia Monstein
Zu allen Blogposts