TalkAbout

Anforderungen formulieren im User-centered Design

Von Julian Traut @J_Traut_Tweet auf Twitter
27. Februar 2019

User-Centered Design bedeutet, NutzerInnen in den Mittelpunkt unserer Arbeit zu stellen. Wir beschreiben unser Vorgehen in einer Artikelserie über ein fiktives Projekt beim fiktiven Logistikunternehmen ML. Jede der vier Phasen unseres Projekts steht im Mittelpunkt eines eigenen Blog-Artikels. Der erste Teil beschäftigt sich damit, den Nutzer-Kontext zu verstehen. Hier geht es zur Leküre.

In diesem Blog schreibe ich über die zweite Phase: Anforderungen formulieren. Die Links zu Teil drei und vier gibt es unterhalb des Artikels.

 


Anforderungen formulieren: Der Sache auf den Grund gehen

Mittlerweile haben wir nicht nur ein gutes Bild von den NutzerInnen, sondern sind auch selbst schon ein ganze Stück in die Tourenplanungswelt eingetaucht. Vor ein paar Wochen haben wir bei Begriffen wie Ladungsträger, Hauptlauf oder Dekonsolidierung nur große Augen gemacht und immer wieder nachfragen müssen. Mittlerweile bewegen wir uns schon deutlich sicherer. Eine Kollegin hat für alle Fälle parallel ein kleines Glossar angelegt, indem wir vor allem die spezifischen Begriffe unseres Kunden ML mit Bedeutungen festhalten. Als nächstes geht es darum, die gewonnenen Erkenntnisse zum einen zu vertiefen und zum anderen in konkrete Anforderungen zu überführen.

Schwerpunkte setzen

Bevor wir uns jedoch auf die inhaltlichen Knackpunkte stürzen, wollen wir aus den Erkenntnissen der letzten Wochen ein erstes Set an Usability-Zielen ableiten. In diesem frühen Stadium sind dies eher qualitative Schwerpunktsetzungen.

Im Workshop mit der Projektleiterin Annett Haders sichten wir nochmal die Bedürfnisse der Personas und legen fest, dass wir bei der weiteren Gestaltung besonderes Augenmerk auf die Durchgängigkeit der Planungsschritte und die Effizienz legen. Dafür dürfen wir die gute Erlernbarkeit des Systems im Zweifelsfall eher vernachlässigen. Alle zukünftigen NutzerInnen werden sehr kontinuierlich mit dem System arbeiten, das heißt wir müssen nicht so stark auf Merkbarkeit und Benutzerführung fokussieren, wie es für sporadische NutzerInnen notwendig wäre.

Mit diesen Gedanken im Hinterkopf widmen wir uns nun dem Inhalt. Gemeinsam mit Annett Haders gehen wir nochmal die Knackpunkte im BigPicture durch, clustern diese und priorisieren gemeinsam, welche der Themen wir als erstes angehen wollen. Wir schnüren kleine Themenpakete, und legen für jedes dieser Pakete fest, wie wir es bearbeiten werden.

Mehr Klarheit gewinnen

Ein großer Schmerz war die Übergabe der Planung zur Disposition. Hier wollen wir in einem gemeinsamen Anforderungsworkshop mit beiden Abteilungen noch etwas mehr Klarheit gewinnen. Gemeinsam mit zwei Planern und zwei DisponentInnen entwerfen wir zunächst ein Prozessbild, in dem nochmal die Schritte der Planung und der darauffolgenden Disposition auf die Zeit abgetragen sind. Hier gibt es schon einige wechselseitige Aha-Momente, weil ein solcher Austausch zwischen den Abteilungen schon sehr lange nicht mehr stattgefunden hat. Dann hangeln wir uns gemeinsam die identifizierten Prozessschritte entlang und formulieren erste Funktionen als Anforderungen an das neue System.

Abschließend widmen wir den spezifischen Anforderungen der Schnittstelle einen eigenen Slot. Schnell stoßen wir darauf, dass offen ist, wie wir dem Dispositionssystem in Zukunft Änderungen an bereits übermittelten Planungen übergeben können. Hier halten wir einen Klärungspunkt für den späteren Projektverlauf fest, wenn die Implementierungsdetails mit der ML-IT geklärt werden können.

Ein Sollbild entwickeln

Auch die anderen Themenbündel bearbeiten wir nach und nach. Einige Themen sind durch ein kurzes Interview mit zwei oder drei AnsprechpartnerInnen schnell erledigt. Für die Langfristplanung stellt sich jedoch heraus, dass wir das zukünftige Vorgehen komplett neu denken wollen. In einer kleinen Workshop-Serie wollen wir ein Sollbild entwickeln.

Stück für Stück klären sich die einzelnen „Blitze“ in unserem BigPicture auf. Wir nutzen die Gelegenheit und verfeinern das Bild weiter und erstellen ein Soll-BigPicture, dass plakativ die Änderungen am Prozess und die zukünftige Systemunterstützung darstellt.

Den Überblick erhalten

Als letzten Schritt in dieser Phase wollen wir die Anforderungen etwas stärker formalisieren. Wir nutzen hier nochmal alle bisher erzeugten Artefakte: Mit den Personas und Empathy Maps führen wir uns nochmal die Bedürfnisse der NutzerInnen vor Augen. Aus dem entstandenen BigPicture und den Prozessbildern können wir mittlerweile sehr gut die notwendige Systemunterstützung und die grundlegenden Funktionen des zukünftigen Planungssystems ableiten.

In dieser ersten Iteration identifizieren wir nur grobe Use Cases. Ziel ist es eher ein Gesamtbild zu erzeugen, als schon überall Inhalt und Tiefe zu bekommen. Entsprechend gibt es beispielsweise einen Use Case „Routenimport“, bei der wir bisher noch nicht mehr wissen, als genau dieses Stichwort. Andere Use Cases sind detaillierter: So hat der Use Case „Planungsabschluss Mittelfristplanung“ schon die drei konkreteren Epics „Konsistenzprüfung“, „Kennzahlenberechnung und Ausgabe“ und „Dokumentenerzeugung“.

Annett Haders ist ganz angetan, dass sie schon jetzt einen groben Überblick über das Gesamtvorhaben hat, auch wenn sie die vielen weißen Flecken noch etwas beunruhigen. Sie wünscht sich, bald auch konkreter Lösungen zu sehen. Diesem Wunsch kommen wir gerne nach, weil es auch uns in den Fingern juckt und wir gerne die vielen Ideen, die wir schon seit den Interviews im Kopf haben zu Papier bringen wollen.

In der nächsten Projektphase werden wir erste Ideen für das neue System entwickeln. Wie wir hier vorgehen, beschreibe ich im dritten Teil dieser Blog-Serie.

 


 

In unserer Blog-Serie über User-Centred Design beschreiben wir unser Vorgehen an einem fiktiven Projekt. Wir beschreiben jede der vier Phasen unseres Vorgehens in einem eigenen Blog-Artikel:

    1. den Nutzer-Kontext verstehen (Link zum Artikel)
    2. Anforderungen formulieren (Artikel oben)
    3. Ideen entwickeln (Link zum Artikel)
    4. Lösungen evaluieren ( Link zum Artikel)

    Kommentare

    Nützlicher, informativer und wissenswerter Artikel.     Ich bereite mich gerade auf die Prüfun RE@Agile Primer  bei IREB um ein Certified Professional for Requirements Engineering  zu werden. Für Agile Softwareentwicklung mit Scrum-Teams. Ich lese verschiedene Fachbücher, Internetseiten, Blogs, sehe Videos um tiefer in ein für mich wichtiges Thema einzutauchen.  Lesen wie RE-Prozesse nicht in der Theorie, sondern im Leben ablaufen ist für mich sehr interessant und sogar spannend. Ich freue mich auf den nächsten Teil.

    Ich kann leider Artikel 3 nicht lesen. Bekomme eine Mitteilung:

    Forbidden

    You don't have permission to access /blog/user-centered-design-ideen-entwickeln on this server.

    Apache Server at www.maibornwolff.de Port 443

    Liebe Viktoriya, herzlichen Dank für Deine Rückmeldung - es freut mich sehr, dass Dir die Blogs etwas bringen. Zum Link - puhhhh... danke für den Tipp, da war etwas falsch hinterlegt. Geht es jetzt?

    Alles OK. Ich lese gerne weiter.

    Neuen Kommentar schreiben

    Public Comment form

    • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

    Plain text

    • Keine HTML-Tags erlaubt.
    • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
    • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

    ME Landing Page Question