User Centered Design im Zusammenspiel mit Requirement Engineering

Für User Centered Design musst du heute kaum noch Werbung machen. Den meisten ist klar, dass Produkte nur dann Erfolg haben, wenn sie die Nutzer begeistern – und dass sie das am besten erreichen, indem sie die Nutzer bei der Entwicklung einbeziehen.

Und so sind Usability-Tests in vielen Unternehmen inzwischen üblich. Doch der Bereich, in dem man immer noch am wenigsten Nutzer antrifft, sind die frühen Phasen der Produktentwicklung. Dies ist maßgeblich auf den UX-Reifegrad von Unternehmen zurückzuführen, der aufzeigt, unter welchen Rahmenbedingungen sie Usability-, UX- und CX-Testing in den Produktentwicklungsprozess integrieren. Ideen für neue Produkte finden und Funktionen festlegen – das passiert auch heute noch oft am Grünen Tisch, ohne dass irgendein Nutzer beteiligt wäre.

Häufig wird dabei mit dem iPhone argumentiert: Das habe sich Steve Jobs einfach selbst ausgedacht und es sei so ein großer Erfolg geworden. Das ist im Ansatz richtig, doch auch das iPhone ist nicht ohne User Research entstanden. Jobs und seine Mitarbeiter haben sich zunächst sehr genau angesehen, was die Nutzer brauchen, wie sie agieren und wo dort der Markt für ein neues Produkt ist. Ohne Nutzerbeteiligung ging es hier also auch nicht.

Und genau so kannst du auch vorgehen,

• um zu besseren Entscheidungen zu kommen,
• um unerfreuliche Diskussionen im Team zu vermeiden und
• um erfolgreichere Produkte zu entwickeln.

Der Schlüssel dazu ist, beim Start des Projekts damit zu beginnen, die Anforderungen der Nutzer unter die Lupe zu nehmen. Genau das ist es, was man beim Requirements Engineering macht.

Was ist Requirements Engineering?

Requirements, also Anforderungen, legen funktionale und nicht-funktionale Eigenschaften eines zu entwickelnden Produkts fest. Also

1. was das Produkt können soll (funktionale Eigenschaften) und
2. welche Qualitäten es haben soll (nicht-funktionale Eigenschaften).

Ergebnis des Requirement Engineering-(RE-)Prozesses nach dem Lehrbuch ist eine Software Requirement Specification (SRS). Oft spricht man einfach von den Spezifikationen, oder auch kurz von Specs. Ziel dabei ist immer, testbare Anforderungen zu definieren. Denn wenn ich eine Anforderung nicht testen kann, weiß ich nicht, ob mein entwickeltes System diese erfüllt.

Beim Wasserfall-Modell der Softwareentwicklung stehen die Spezifikationen am Beginn der Programmierung. Hier definiere ich, was ich umsetzen will. Bei moderneren Methoden ist die Requirement Specification nicht dauerhaft festgelegt, sondern wird laufend aktualisiert.

Agile Entwicklung und Requirements Engineering

Man könnte meinen, dass mit der agilen Entwicklung das Requirements Engineering weniger wichtig geworden ist. Denn es ist klar, dass es schon bei mittelgroßen Projekten kaum möglich ist, von Anfang an alles haarklein festzuschreiben.

Traditionelles Vorgehensmodell beim Requirement Engineering – die Anforderungen werden zu einem bestimmten Punkt fertig und sind damit fix – so funktioniert die Entwicklung nach dem Wasserfall-Modell.

Anforderungen sollten idealerweise Folgendes sein:

• vollständig
• konsistent
• relevant

Nach dem agilen Konzept können Anforderungen das aber nie sein. Denn moderne Software ist zu komplex, um vorher alle ihre Eigenschaften definieren zu können. Und hinzu kommt, dass sich bei den langen Projektlaufzeiten Anforderungen auch ändern können.

Vereinfacht gesagt wird daher bei der agilen Entwicklung nicht mit einem festen Set von Requirements, sondern mit dem Product Backlog gearbeitet. Das ist eine Sammlung von Funktionen bzw. meist von User Stories (gilt so für Scrum, der häufigsten Variante der agilen Entwicklung).

Was sind User Stories?

User Stories beschreiben Anforderungen als Mini-Geschichte. Diese folgen einem festgelegten Schema: Als … möchte ich…, damit ich…

Das sieht dann also etwa so aus: Als Administrator möchte ich die Daten eines Nutzers bearbeiten, damit ich seine Kontaktinfos aktualisieren kann.

User Stories haben den Vorteil, dass sie aus Nutzersicht geschrieben werden müssen. Sie lassen sich schneller schreiben als eine funktionale Anforderung. Das folgt dem agilen Ansatz, die Dokumentation möglichst schlank zu halten.

Wann User Stories weniger sinnvoll sind

Anforderungen an die Sicherheit lassen sich z.B. kaum sinnvoll aus Nutzersicht definieren. Die User Story „Als Nutzer will ich, dass mein System nicht von Hackern beschädigt werden kann…“ – das wirkt etwas albern.

Sehr grundlegende Anforderungen lassen sich schlecht als User Stories abbilden. Und z.B. auch Branding-Anforderungen funktionieren als User Story nicht. Die User Story „Als Kunde möchte ich schöne Fotos der Produkte sehen, um mich von der Marke begeistern zu lassen.“ ist natürlich Quatsch. Aber eine Anforderung der Marketing-Abteilung kann die Kundenbegeisterung durchaus sein.

Sprich: Wenn du ein Projekt hast, bei dem es wenig um Funktionen geht, mehr um Marke, Marketing, Branding oder Information, dann sind User Stories wahrscheinlich nicht geeignet, um deine Requirements festzuhalten. Das gilt also für die meisten Website-Projekte.

Hast du dagegen komplexere Interaktionen wie interaktive Formulare, Filter- und Such-Werkzeuge, dann sind User Stories interessant.

Anforderungen dürfen sich ändern – du solltest es nur dokumentieren

Wichtig ist: Anforderungen werden heute nicht als in Stein gemeißelt betrachtet. Vielmehr sieht man sie in der agilen Entwicklung als Hypothese, die während der und durch die Entwicklung geprüft wird. Nach technischen Tests, Gesprächen mit Stakeholdern und Nutzern sowie vor allem nach Tests können die Anforderungen angepasst, ergänzt oder aufgegeben werden.

Du siehst also auch: Die agile Entwicklung hat sich nicht vom Requirements Engineering verabschiedet. Vielleicht ist es sogar anders herum, und das Requirements Engineering ist wichtiger geworden. Denn wenn du agil arbeitest, dann musst du dich die ganze Zeit um die Requirements kümmern. Anders als beim Wasserfall ist das keine Aufgabe, die du einmal erledigst und dann abgeschlossen hast.

Das ist auch die Chance der agilen Entwicklung: Dieses Vorgehen ist flexibel, insofern können an sich einfach Ergebnisse von Nutzertests u.a. Erkenntnisse des User Reaserch einfließen.

Wichtig ist, dass du den Spruch immer im Kopf hast: Anforderungen gibt es immer – nur oft sind sie nicht dokumentiert.

Das heißt, ihr solltet im Projekt dafür sorgen, dass die Anforderungen anfangs aufgeschrieben werden. Und dass sie im Projektverlauf aktualisiert werden, wenn sich neue Erkenntnisse ergeben.

Schon Goethe meinte: „Was man schwarz auf weiß besitzt, kann man getrost nach Hause tragen.“ Von Requirements hatte er zwar noch keine Ahnung, aber für die gilt das auch: Man schreibt sie besser auf.

Beim agilen Vorgehen hast du mit dem Backlog ein gutes Instrument dafür. Ansonsten kann es einfach eine Liste in Google Docs sein oder du pflegst die Anforderungen in einem Kollaborationstool wie Asana oder Trello.

Nutzerorientierte Gestaltung & Requirements Engineering-Praxistipps

Zum Thema Requirements Engineering findest du viele Informationen online, die das aus Programmierer-Sicht beschreiben. Was du kaum findest ist eine Erklärung, wie das mit dem User Centered Design zusammenspielt. Dabei ist das gar nicht so kompliziert.

Generell hat Requirements Engineering die folgenden 5 Phasen:

1. Erkunden (discovery)
2. Erfassen (refinement)
3. Priorisieren (prioritization)
4. Prüfen (review)
5. Dokumentieren (documentation)

User Centered Design Methoden fürs Requirements Engineering

Vor allem beim Erkunden kommt die nutzerzentrierte Entwicklung ins Spiel. Folgende UCD-Methoden kannst du besonders gut einsetzen:

• Contextual Inquiry (Teilnehmende Beobachtung, Vor-Ort-Interviews)
• Interviews, Fokusgruppen
• Tagebuch-Studien
• Card Sorting
• Personas
• Befragungen (on- oder offline-Fragebögen)
• Top-Task-Analyse
• Customer Journey Mapping
• Storyboards
• Prototyping
• Cognitive walkthroughs, Expert reviews

Wenn du das Gefühl hast, das sind viel zu viele – keine Sorge, die lange Liste zeigt dir nur deine Möglichkeiten auf. In der Praxis kommen am häufigsten diese drei Methoden zum Einsatz:

1. Contextual Inquiry
2. Personas
3. Prototyping.

Ein Beispiel: Für deine neue Kitesurfer-App tauchst du erstmal richtig ein in die Welt der Lenkdrachensegler. Für die Contextual Inquiry begleitest du sie an den Strand, sprichst mit ihnen, lässt dir zeigen, wie ihr Sport funktioniert. Du befragst sie vor allem dazu, welche Probleme sie haben, was sie ärgert und was ihnen am meisten Spaß macht. Du sprichst mit so vielen Fans, bist du das Gefühl hast, nichts Neues in den Gesprächen zu lernen. Damit hast du eine Grundlage für einen Ideen-Workshop, in dem du im Team mit deinen Kollegen Ansätze dafür entwickelt, wie eine App den Kitesurfern helfen kann. Das ist dann die Grundlage fürs Festlegen der Requirements.

Als Nächstes könnt ihr Personas entwickeln. Dabei erstellt ihr Portraits von prototypischen Nutzern, an denen ihr die weitere Entwicklung ausrichten könnt. Beim Beurteilen der Bedeutung eurer Requirements z.B. sind die Personas eine große Hilfe.

Und beim Prototyping schließlich erstellt ihr Prototypen auf Papier oder digital. Dabei seht ihr, wie das Produkt eure Requirements erfüllt. Und vielleicht ergeben sich daraus auch weitere Anforderungen, die euch bei euren Vorüberlegungen noch nicht aufgefallen sind. Oder ihr stellt sogar fest, dass manche Anforderungen vielleicht gar nicht nötig sind. Insbesondere wenn ihr die Prototypen mit Vertretern der Zielgruppe testet, bekommt ihr wertvolle Erkenntnisse über eure Requirements.

Requirements & Nutzerzentriertes Design – ein Traumpaar

Auch wenn du bisher noch nichts mit Requirements Engineering zu tun hattest, dann hattest du bisher dennoch aber immer mit Requirements zu tun in deinen Projekten. Denn Anforderungen gibt es immer, nur hat sie manchmal einfach keiner aufgeschrieben.

Das solltest du in Zukunft am besten immer tun – notiere am Anfang des Projekts die Anforderungen der Projektbeteiligten/Stakeholder und die der Nutzer. Beim Nutzerzentrierten Design aktualisierst du diese dann laufend – mit allen Erkenntnissen, die du aus Usability-Tests und deinen anderen UCD-Aktivitäten gewinnst. So ist allen Projektbeteiligten immer klar, wohin eure Reise geht.

Und wenn du noch mehr wissen willst dazu, wie Requirement Engineering und User Centered Design zusammenspielen, dann sieh dir diese wissenschaftliche Veröffentlichung an: Requirements engineering related usability techniques adopted in agile development processes