Nachdem man den Nutzungskontext verstanden und angemessen beschrieben hat, geht es gemäß dem User-Centered Design Prozess, dem idealtypischen nach ISO 9241 Teil 210 zufolge im nächsten Schritt darum, daraus aus diesen Erkenntnissen, die man gewonnen hat, Anforderungen abzuleiten.

Eine Anforderung beschreibt eine Möglichkeit, die das System, die das interaktive Produkt bieten muss, damit Benutzer bei der Erreichung bestimmter definierter Ziele bestmöglich unterstützt werden. Diese Anforderungen leitet man aus all den Erkenntnissen ab, die man gewonnen hat, in welcher Form auch immer sie vorliegen, sei es jetzt, dass man die

Dinge schriftlich dokumentiert hat, die man in Interviews herausgefunden hat oder in Fokusgruppen, sei es, dass es Beobachtungsprotokolle sind oder Protokolle von Kontextinterviews, die Beobachtung und Befragung miteinander kombinieren, oder das sind Ergebnisse von Diskussionen von bestimmten Szenarien, die man aufgeschrieben hat, um die Situation,

so wie man sie beobachtet hat, zu beschreiben und darzustellen. Es können also ganz unterschiedliche Quellen sein, ich gehe mal jetzt davon aus, dass es Textquellen sind, in denen bestimmte Dinge geschrieben stehen. Das ermöglicht einem einen ziemlich großen, oder bietet

einem einen ziemlich großen Interpretationsspielraum, das ist so ein bisschen das Unscharfe an dieser Phase. Man hat also alle möglichen Freiheiten, auch alle möglichen unsinnigen Anforderungen abzuleiten, widersprüchliche Anforderungen abzuleiten aus dem, was man da erfahren hat. Das ist schlichtweg auch ein Diskussions- und Entscheidungsprozess.

Es gibt also nicht wirklich eine Methode, die deterministisch, also ganz strukturiert und vorgegeben zwingend, ausgehend von bestimmten Informationen ganz bestimmte Anforderungen zu ermitteln, sondern das ist ein Diskussions- und Entscheidungsprozess. Dabei helfen können natürlich Modelle, die man angefertigt hat, auch Modelle von

Benutzerinnen und Benutzern, also beispielsweise Personas, dabei können Szenarien helfen und und und, um diese Diskussion zu erleichtern und um sich in dieser Diskussion eben möglichst sicher zu sein, dass man die richtigen Anforderungen ableitet. Wenn es darum geht, eine Anforderung zu definieren, man hat dann also am Ende dann tatsächlich

eine Kataloge von Anforderungen, dann ist es oft hilfreich, nochmal so einen Zwischenschritt zu machen auf dem Weg zu einer Anforderung und dieser Zwischenschritt ist das Erfordernis. Also man leitet erstmal ein Erfordernis ab und daraus dann die Anforderung. Der Clou an der Sache ist, dass ein Erfordernis so formuliert ist, dass es erstmal nichts

mit dem Produkt zu tun hat. Und die Anforderung ist dann tatsächlich die Anforderung an das Produkt. Ein Erfordernis beschreibt also eine Voraussetzung, die erfüllt sein muss, damit ein Benutzer oder eine Benutzerin ein bestimmtes Ziel erreichen kann. Ein Erfordernis hat also von der Formulierung her in der Regel die Form, ich muss ... können, um ...

Beispiel, man hat im Rahmen beispielsweise von Kontext-Interviews herausgefunden, dass die Leute, also die Kundinnen und Kunden, ihre Kaufentscheidungen von einem oder anderen Produkt vergleichen abhängig machen. Das heißt, man hat beispielsweise beobachtet,

wie sie in einem Laden verschiedene Kleidungsstücke nebeneinander halten und sie optisch miteinander vergleichen. Oder man hat festgestellt, dass sie in einem Elektronikgeschäft die Spezifikationen, die dann auf Schildern da auf den Kartons stehen, also nebeneinander gehalten haben und das miteinander verglichen haben. Und daraufhin hat man beispielsweise

eine Notiz gemacht wie die folgende. Meine Kaufentscheidung hängt je nach Produktkategorie von verschiedenen Produktmerkmalen ab, die ich miteinander vergleiche. Das ist also die geronnene Erkenntnis, wenn man so will, die man da möglicherweise schriftlich fixiert hat. Und jetzt kann man daraus im ersten Schritt ein Erfordernis ableiten. Ein mögliches

Erfordernis, abgeleitet aus dieser Notiz, könnte zum Beispiel so aussehen. Ich muss verschiedene Produktmerkmale miteinander vergleichen können, um zu einer Kaufentscheidung zu kommen. Wie Sie sehen, hängt diese Formulierung oder bezieht diese Formulierung in keinster Weise irgendeine Art von Produkt ein, sondern es beschreibt eben die Notwendigkeit

eines Produktvergleichs zum Zwecke einer Kaufentscheidung. Egal, wie man jetzt diesen Produktvergleich anstellt, also unabhängig von jeglichen technischen Aspekten und insbesondere unabhängig von dem Produkt, das es jetzt zu entwickeln gilt. Also jetzt hier beispielsweise unabhängig von dem Onlineshop, den man hier möglicherweise

entwickeln möchte. Das ist jetzt aber noch keine Anforderung. Eine Anforderung, die man aus diesem Erfordernis ableiten kann, könnte, wäre zum Beispiel der Onlineshop xy muss die Möglichkeit bieten, beliebige Merkmale der angebotenen Produkte übersichtlich miteinander zu vergleichen. Da kommt jetzt beispielsweise noch dieser Aspekt der

Übersichtlichkeit mit hinein. Das ist eine Entscheidung, die man treffen kann. Das muss man da natürlich nicht reinschreiben. Das ist ja auch nichts, was man vielleicht im Rahmen von Kontext-Interviews oder ähnlichen Methoden beobachtet oder gehört hat. Das ist schlichtweg auch so eine Entscheidung, die man treffen kann, dass es übersichtlich sein soll. Hier also der Unterschied. Hier bezieht sich die Anforderung also wirklich

auf das Produkt. Es ist eine Anforderung an das Produkt. Und eine solche Anforderung, das sehen Sie vielleicht auch, wenn Sie sich das mal ein bisschen anschauen, das ist keine konkrete Designvorgabe oder so. Hier steht jetzt nichts davon,

wie genau dieser Merkmalsvergleich, dieser Produktvergleich technisch oder gestalterisch umgesetzt werden muss. Das heißt, da ist nicht die Rede von irgendwelchen tabellarischen Übersichten oder so. Das ist nicht die Rede davon, wie man verschiedene Produkte oder oder wie man Produkte einer solchen Vergleichsübersicht hinzufügen oder wieder entfernen kann. Ob man dafür ein Mülleimer-Symbol oder ein Minus-Symbol nimmt

und und und. Also all diese ganz konkreten Gestaltungsentscheidungen, die sind damit noch nicht getroffen, sondern eine Anforderung legt einen Rahmen fest, rammt gewissermaßen Leitplanken ein, grenzen der Vernunft innerhalb derer man sich dann natürlich noch sehr viel konkretere und hoffentlich vernünftige Designentscheidungen

vornehmen muss und sie treffen muss. Wenn man Anforderungen festlegt, steht man auch vor dem Problem, dass man sehr viele Anforderungen definieren könnte, aus dem was man da beobachtet hat. Man hat ja hoffentlich auch eine ganze Menge beobachtet. Das ist unter Umständen so viel, dass man es nicht bewältigen kann und dass man es auch

nicht alles umsetzen kann, wenn das jetzt zum Beispiel Funktionalitäten direkt betreffen. Man muss die und die Funktionalität haben und jene und jene und jene. Das kann irgendwann so viel sein, dass es einfach zu viel ist. Das heißt, man muss in der Regel auch Anforderungen priorisieren, also entscheiden, welche sollen auf jeden Fall umgesetzt werden und welche nur mit einer geringeren Priorität. Man muss sicherlich auch immer wieder die

Entscheidung treffen, eine bestimmte mögliche Anforderung nicht zu stellen oder nicht umzusetzen. Es kann beispielsweise dann der Fall sein, wenn man bei Kontextinterviews oder ähnlichen Methoden zum Verstehen des Nutzungskontextes verschiedene Menschen mit unterschiedlichen

Meinungen befragt hat. Die kommen dann ja alle irgendwie auf den Tisch in der Diskussion und man muss schlichtweg entscheiden, welche Anforderungen man umsetzt und welche nicht. Also beispielsweise, wenn sie sich widersprechen. Manchmal hat man, wenn man so ein bisschen Fantasie walten lässt, dann kommt man teilweise auch zu relativ, wie soll man sagen,

etwas obskuren oder fragwürdigen Anforderungen, die dann auch im Rahmen der Diskussion natürlich wieder kassiert werden können und wieder über den Haufen geworfen werden können, sodass diese Anforderung letztendlich nicht umgesetzt wird. Also beispielsweise hat man beim Beobachten von Kundinnen und Kunden in einem Laden festgestellt, dass

sie dabei Musik hören. Man hat sie gefragt, warum machen sie das und dann ja, das entspannt mich und so weiter. Das könnte zu der Anforderung verleiten, zu sagen, der Online-Shop muss einen Music-Player integriert haben. Man kann aber natürlich genauso gut sagen, das müssen wir jetzt nicht auch noch machen, sondern wir gehen

davon aus, dass die Nutzerinnen und Nutzer ihre eigenen Abspielgeräte haben oder andere bewährte Möglichkeiten haben, sich Musik anzuhören, während sie unseren Online-Shop benutzen. Das als Beispiel dafür, wie man also nicht alle möglichen und denkbaren Anforderungen natürlich tatsächlich umsetzen muss. Wenn es darum geht, Anforderungen

zu definieren und man hat eine erste priorisierte und bereinigte, vermeintlich endgültige Liste von Anforderungen, kann es aber eben auch sein, dass man nochmal in die Phase 1 des User-Centered-Design-Prozesses zurückspringen muss. Vielleicht ja auch nur vereinzelt und punktuell, um mit Benutzerinnen und Benutzern nochmal ins Gespräch zu

kommen, um sich zu vergewissern, dass man jetzt auch tatsächlich die richtigen Anforderungen formuliert hat, dass da nichts fehlt, dass das irgendwie Sinn ergibt, dass auch keine Anforderung da besonders hoch beispielsweise priorisiert wurde, die dann aus Sicht der

Nutzerinnen und Nutzer möglicherweise dann doch nicht so wichtig ist und so hoch einzuschätzen ist. Das heißt, wann immer man zu einer Anforderungsliste kommt, am besten nicht gleich direkt zur Umsetzung schreiten, sondern sich nochmal vergewissern, in welcher Form auch immer, ob das jetzt wirklich eine Liste von Anforderungen ist, mit

der man sinnvoll in die nächste Phase, nämlich in die Erstellung von Gestaltungslösungen einsteigen kann.