Balance zwischen Anspruch und Realität
Die Analyse des Nutzungskontextes – einschließlich Umgebung, Verhalten, Bedürfnisse und Herausforderungen der Anwender– stellt einen großen Teil des UX-Designprozesses dar, damit Designer aus den gewonnenen Erkenntnissen Benutzeranforderungen erheben können. Diese Phase ist ausschlaggebend, denn ohne Verständnis für die Anforderungen besteht keine solide Grundlage für ein gutes UI Design. Bei zahlreichen Projekten sind UX Designer auch in der Lage, anhand der von ihnen gesammelten Anforderungen UI Screens zu gestalten.
Bei komplexen und umfangreicheren IT-Projekten mit mehreren Interessengruppen wird es für einen UX Designer jedoch schwierig sein, alle Anforderungen zu erheben und wertvolle UI Designs zu liefern. In solchen Fällen müssen die UX Designer mit RE effizient zusammenarbeiten.
Vielen UX Designern fällt das schwer. Andererseits haben Requirements Engineers auch Schwierigkeiten zu verstehen, wie sich UX und RE in einem agilen Umfeld ergänzen können.
Über das Was und Wie in einem agilen Prozess
Noch bevor die UX Designer mit ihrer Arbeit loslegen, erarbeiten, analysieren und dokumentieren Requirements Engineers die ersten Anforderungen. Die Quellen dieser Anforderungen können Interviews mit verschiedenen Stakeholdern, wie Kunden, Anwendern, Architekten und Entwicklern sein – um nur einige zu nennen. Kontextuelle Interviews, in denen ein Benutzer seine aktuelle Arbeitsweise zeigt und erklärt, stehen auch als Sammelquelle wertvoller Einblicke und Anforderungen zur Verfügung. An dieser Stelle sollte eine bis ins letzte Detail schriftlich festgehaltene Spezifikation nicht das endgültige Ziel darstellen. Das Bestreben ist es, eine solide Menge grundlegender Anforderungen parat zu haben, damit UX Designer eine Sitemap sowie einen ersten Low-Fidelity-Prototypen erstellen können. Sitemaps geben die Hierarchie und Navigationsstruktur einer Anwendung wieder. Low-Fidelity-Prototypen dienen als grober Leitfaden, um zu zeigen, wie und wo Inhalte auf jedem Bildschirm oder jeder Seite untergebracht werden. Diese Low-Fidelity-Prototypen können handgezeichnete Skizzen sein (Vorteil: Sie sind schnell und günstig zu produzieren und können unbedacht entsorgt werden, sollten Sie es sich anders überlegen), die später als computergezeichnete Wireframes verfeinert werden können (z.B. mit speziellen Tools wie Figma oder Axure). Sitemaps und Low-Fidelity-Prototypen vernachlässigen an dieser Stelle visuelle Details im Design. Kurz gesagt, liefert RE die Information, was im UI angezeigt werden muss und UX kann damit loslegen, zu überlegen, wie eine passende Design-Lösung aussehen muss, um den Anforderungen gerecht zu werden.
Die RE-Artefakte sind textuell, modellbasiert oder beides (z.B. in UML-Diagrammen). Die gängigste Visualisierung im RE sind Use-Case-Modelle. Das klassische Requirements-Engineering beinhaltete lange keine grafische Visualisierung der Benutzeroberflächen. Dies gestaltete sich insofern problematisch, als Gespräche mit den Kunden ineffizient werden konnten. Was ist damit gemeint? Zwei Interessengruppen könnten über eine UI-Lösung sprechen, aber ohne Visualisierung interpretieren beide möglicherweise, ohne sich darüber im Klaren zu sein, die Dinge unterschiedlich.
Ein Prototyp – auch wenn es sich um einen Low-Fidelity-Prototyp handelt – ist ein gutes und wichtiges Mittel, um die Pläne mit dem Kunden zu konkretisieren. Auf diese Weise können Missverständnisse vermieden und das Risiko unnötig langwieriger Diskussionen reduziert werden. Darüber hinaus helfen Ihnen diese Visualisierungen, zielgerichtete Interviews und Besprechungen mit den Kunden durchzuführen.
In den Besprechungen über die anfänglichen UX-Artefakte (erste Anforderungen, Sitemap, Low-Fidelity-Prototyp) mit dem Product Owner oder anderen relevanten Interessengruppen, arbeiten die Requirements Engineers und die Designer spezifischere Anforderungen aus. Dementsprechend wird der Low-Fidelity-Prototyp dazu verwendet, die Anforderungen durch enge Zusammenarbeit der Requirements Engineers und Designer mit dem Product Owner weiter zu verfeinern. Auf der Grundlage dieses Inputs kann der Prototyp auch weiter verfeinert werden. Somit hilft das Prototyping nicht nur dabei, die gängigen Anforderungen zu visualisieren, sondern zusätzlich neue Anforderungen zu erarbeiten: Das UX erweitert visuell das RE.
Die iterative Schleife aus Prototyping und Anforderungserhebung ist notwendig, und Teil des Spezifikationsprozesses in einer agilen Umgebung.
Diese Schritte werden wiederholt, bis Sie ein bestimmtes Anforderungsniveau und einen High-Fidelity-Prototypen, der dem gewünschten Produkt bereits sehr nahe kommt, erreichen.
Zu beachten: Neue Anforderungen und Konzeptanpassungen sind Teil des Prozesses und kein Grund zur Frustration oder gar ein Hindernis. Die enge Zusammenarbeit zwischen UX und RE kann diesen Prozess fördern, indem Kunden-Feedback durchgehend integriert und Anforderungen spezifiziert werden.
Während Requirements Engineers und die UX Designer Anforderungen erheben, Spezifikationen bereitstellen und Prototypen und UI Designs erstellen, wird auch das Feedback der Entwickler benötigt. Es ist wichtig, die Entwickler so früh wie möglich einzubeziehen.
Low-Fidelity-Prototypen sollten mit Entwicklern besprochen werden, da ihr Beitrag und Input zu Design-Anpassungen führen können. Diese Anpassungen müssen wiederum mit dem Product Owner und den Interessengruppen besprochen werden. Die technische Durchführbarkeit von Low- und High-Fidelity-Prototypen wird von den Entwicklern durchgehend überprüft. Anstatt den Entwicklern den Prototyp oder ein fertiges UI-Design vorzulegen, sollten diese stets auf dem Laufenden gehalten werden. Damit letztendlich die Frontend-Entwickler die ersten freigegebenen Funktionalitäten zur Umsetzung erhalten können.
Interdisziplinäre Zusammenarbeit an einem Projekt – denn der Kunde ist König
Das RE sollte seine technische und modellierte Dokumentation mithilfe von Visualisierungen in Form von groben Wireframes erweitern. Die UX-Designer hingegen können nicht nur Wireframes und Klick-Prototypen als endgültige Lösung bereitstellen, sondern brauchen diese, um Anforderungen im Kundengespräch zu ermitteln. Obwohl RE und UX unterschiedliche Disziplinen sind, können sie durch enge Zusammenarbeit und flexible Ergänzung Projekte erfolgreich abschließen, damit die Kunden ein Produkt erhalten, das in seiner endgültigen Fassung ihren Erwartungen und Bedürfnissen entspricht.
Dies wird am Beispiel von Kfz-Versicherungsportalen im Artikel „Versicherungsportale für Kunden optimiert“ näher beschrieben und illustriert.
Mehr Informationen: Liquid Enterprise – flexible Organisationen gestalten die Zukunft