Grundlage jedes User Interfaces und jeder zu gestaltenden User Experience sind die Anforderungen. Also das, was man – der User – mit dem Ding, das wir – die Agentur – bauen dann tatsächlich tun können soll. Im Idealfall hat das wenig damit zu tun, was einzelne Entscheider persönlich finden, sondern damit, was die Nutzer wirklich wollen.

Wie Anforderungen bei uns ankommen

Ein paar Beispiele aus den letzten 12 Monaten:

• Powerpoint mit Bullets wie „Inhaltskatalog nach Genre filtern“
• Productbacklog Listen (Hallo Scrum!) mit Einträgen wie  „Vertiefung der Inhaltsvielfalt“
• Übersichten mit „Functional requirements“, die z.B. das hier anfordern: „Der Nutzer hat Zugang zu Listen, die eine Auswahl von Filmen erlaubt und die durch das System oder den Nutzer befüllt werden können.“
• Listen mit sehr vielen User Stories, wie „Als Benutzer möchte ich Inhalte einer Kategorie auf visuell ansprechende, informative und schnelle Art navigieren können.“
• Use Case Dokumente mit unzähligen Use Cases à la „Wenn der Nutzer den Navigationspunkt 1 auswählt, präsentiert ihm das System eine Übersicht über alle verfügbaren Unterkategorien.“
• Handschriftliche Zettel, auf denen die Funktion „TV sehen“ in Relation zu einem Gerät wie z.B. dem „Smartphone“ gesetzt wird
• …

Anforderung an Technik ≠ Nutzungsanforderung

Alle diese Anforderungsbeschreibungen haben gemeinsam, dass Sie – auch wenn in der reinen Notierung augenscheinlich nutzerorientiert (User Stories) – in aller Regel das wiedergeben, was ein System technisch können soll.

Jetzt ist per se nicht dagegen zu sagen, Anforderungen an das technische System zu formulieren, auch Anforderungen aus Sicht des Marktes, einer Organisation, des Gesetzgebers oder der Fachabteilung sind relevant. Die Frage ist nur: wann im Projektzyklus ist der richtige Zeitpunkt für welche Art der Anforderung?

Der Nutzer weiss doch gar nicht, was er will

Wird zu früh auf nicht nutzerbasierte Anforderungen gesetzt – und das sind die oben genannten alle – ist die Gefahr enorm hoch dass technische Machbarkeit oder gefühlte funktionale Differenzierung vom Wettbewerb die Basis für das Produkt / den Service bilden. Und nicht mehr das, was die Nutzer eigentlich brauchen. Oder wer hat damals wirklich 1000 Speicherplätze für Telefonnummern in seinem Nokia Knochen gebraucht? Eben.

Klar, ein Produktmanager hat ein Gefühl dafür was Nutzer brauchen könnten, vielleicht sogar qualitative Mafo-Daten dazu, die ihm die Top10 Funktionen vorgeben. Es ist gut und fair einen Teil der Anforderungen aus Sicht der Produktverantwortlichen zu definieren, aber bitte nicht alle. Echte potentielle Nutzer und professionelle  „Anforderer“ haben erfahrungsgemäß unterschiedliche Auffassungen darüber, welches Feature wann und in welcher Ausprägung besonders wichtig ist. Als Funktion ausgedrückt, weiss der Nutzer nicht unbedingt, was er will. Aber hinter jeder Funktion steht ein Bedürfnis, das kennt der Nutzer und das kann man ihm entlocken.

Lasst uns den Nutzer also bereits bereits in der Phase der Anforderungsdefinition mit einbeziehen – das geht schneller und ist günstiger als gemeinhin angenommen (meine Kollegin Anja Lange hat das anhand eines Beispiels hier sehr schön erläutert). Und außerdem hat es einen äußerst positiven Nebeneffekt: bei der Diskussion mit Stakeholdern können HiPPO Entscheidungen minimiert werden.

Es heißt dann immer seltener „Ich finde aber, das Feature ist am wichtigsten“ – dafür um so öfter „Klar kann man das weglassen, interessiert ja eh keinen.“