Von User Stories bis zum Produkt, wo und wann macht man Grafikdesign?

Wir machen unsere ersten Schritte in der Welt der agilen Entwicklung, und obwohl wir noch einen langen Weg vor uns haben, habe ich Schwierigkeiten, unseren Grafikdesigner in den Entwicklungsprozess einzubeziehen.

Der bisherige PO glaubte an einen Product definition => designer => DevelopersFlow. Der Designer arbeitete mit dem Produktmanager zusammen, um eine Präsentation mit genauen Bildern der App zu erstellen und sie zur Implementierung an die Entwickler zu senden. Dies führte zu einer enormen Verschwendung, da der Designer bei jeder Änderung viele Folien aktualisieren musste. Da er zuvor alle Bilder für die gesamte App erstellt hatte, gab es im Laufe der App-Entwicklung Änderungen am Design, die wiederum dazu führten, dass er viele, viele Folien änderte. Ein weiteres Problem war, dass die Bilder das erwartete Verhalten nicht erklären – was passiert, wenn ein Fehler auftritt? Mit welcher Animation soll ein Popup erscheinen? Dies verursachte viele Fehler im Zusammenhang mit dem erwarteten Verhalten.

Um diese Verschwendung zu vermeiden, habe ich den Designer gebeten, für jede Geschichte einen Satz Bilder zu erstellen, wenn der größte Teil des Bildes eine Skizze der App ist und nur die Teile, die sich auf die aktuelle Funktion beziehen, tatsächliche Bilder sind. Darüber hinaus habe ich den Produktmanager gebeten, die Akzeptanzkriterien zu schreiben, die das erwartete Verhalten definieren (einschließlich aller Verhaltensweisen oder spezifischen Fehlermeldungen).

Das war nur ein Schuss ins Blaue, und ich bin mir nicht sicher, ob das der richtige Weg ist. Ich würde mich über jeden freuen, der seine Meinung zu dem hier beschriebenen Prozess mitteilen kann, falls ich irgendetwas anders machen sollte.

"Als die App-Entwicklung voranschritt, gab es Änderungen am Design" - Was verursacht diese Designänderungen?
Wenn zum Beispiel eines der Features ersetzt wurde. Mit dem aktuellen Entwicklungsmodus erfordert eine Änderung an einem Epic oder einigen Geschichten nicht die Aktualisierung des gesamten Projekts, sondern nur der relevanten Elemente.
mögliches Duplikat von pm.stackexchange.com/q/10508/4271
@Ashok, viele Dinge führen dazu, dass sich das GUI-/visuelle Design im Laufe des Codedesigns ändern muss: Dinge werden im Voraus vergessen, Ideen funktionieren nicht gut, wenn der Imagination Funktionalität hinzugefügt wird, oder es wird festgestellt, dass anfängliche Annahmen/Anforderungen hatten Unrecht. Dies ist der ganze Grund für den iterativen Ansatz des agilen Designs und der Entwicklung: Es ist die Erkenntnis, dass Änderungen an den Anforderungen und anfänglichen Designs sowohl erforderlich als auch wünschenswert sind.

Antworten (4)

Der von Ihnen beschriebene Prozess ist ziemlich gut und passt ziemlich gut in die visuellen Designpraktiken von Agile-Scrum.

Hier ist der visuelle Designprozess, der für mich in mehreren Agile-Scrum-Projekten gut funktioniert hat:

Beginnen Sie 1-2 Wochen vor Beginn einer Iteration mit groben Wireframes. Lassen Sie Ihren Designer mit dem PO zusammenarbeiten, um die Wireframes zu erstellen. Versuchen Sie, die Wireframes auf die Funktionalität zu konzentrieren, die NUR in der Story behandelt wird – wenn Sie andere Elemente zu Ihrem hinzufügen müssen Wireframe für den Kontext, stellen Sie sicher, dass absolut klar ist, welchen Teil der Funktionalität die Wireframes abdecken und was darüber hinaus geht. Überprüfen Sie die Wireframes ca. 1 Woche vor Beginn der Iteration mit einem technischen Leiter oder Entwickler, um Feedback zu erhalten. Verhandeln Sie Story-Änderungen/Wireframe-Änderungen mit dem PO, nachdem Sie technisches Feedback erhalten haben. Hängen Sie zu Beginn der Iteration endgültige Wireframes und/oder visuelle Designs an die entsprechende User Story an. Die User Story sollte auf das visuelle Design verweisen. Die User Story sollte weiterhin Beschreibungen in den Akzeptanzkriterien enthalten wie UI-Elemente interagieren Während der Demo/Abnahme, Vergleichen Sie die Wireframes/das visuelle Design mit dem tatsächlichen Produkt. Besprechen Sie etwaige Abweichungen und passen Sie das Design an oder erstellen Sie bei Bedarf einen Fehler, um sicherzustellen, dass beide synchron bleiben.

Einige Wireframing-Tools sind interaktiv und können tatsächlich UI-Elemente anzeigen; Pop-ups, Modals, seitenübergreifende Navigation usw., um den visuellen Designkomponenten der Geschichte noch mehr Tiefe zu verleihen.

Wenn während der Iteration ein visuelles Design oder ein Drahtmodell geändert wird, stellen Sie sicher, dass die visuellen Assets aktualisiert werden, damit sie mit der Story übereinstimmen. Ich habe so viele Designer gesehen, die mit veralteten Grafiken arbeiten, die immer wieder in Geschichten verwendet werden. Dies schafft eine Menge Verwirrung für Entwickler.

Versuchen Sie schließlich, Ihren Designer in das Team einzubinden. Viele Designer können als QA-Ressource fungieren, indem sie sich das Arbeitsprodukt auf lokaler Ebene oder auf QA-Ebene ansehen und sicherstellen, dass es die Designkriterien erfüllt, bevor es zur Überprüfung an den PO geht.

Wireframing kann unglaublich einfach sein; Ich habe großartige Wireframes von einem Whiteboard gesehen. Es muss nicht immer schön sein. Darüber hinaus können Sie oft ein detailliertes visuelles Design für jede Geschichte vermeiden, wenn Ihr Projekt Designelemente wiederverwendet. Denken Sie daran, wenn Sie nach Bereichen suchen, in denen Sie die Effizienz steigern können.

Ich glaube, Sie können nicht genug betonen, wie wichtig es ist, dass jemand aus dem Entwicklungsteam in den Wireframe-Überprüfungsprozess eingebunden wird. Ohne dies ist es für Designer und Product Owner durchaus möglich, Wireframes zu entwickeln, die sowohl brauchbar als auch wertvoll sind, aber die Schwierigkeit/Kosten beim Erstellen nicht berücksichtigen.

Sie sind auf dem richtigen Weg.

Die beste Voraussetzung für das Grafikdesign ist eine Definition of Ready für eine User Story. Die Story wird vom Team als bereit für den Start der Entwicklung wahrgenommen, wenn:

  • Titel und Beschreibung sind angegeben
  • Akzeptanzkriterien definiert
  • Grafikdesign-Bildschirme angebracht
  • Story Points-Schätzung zugewiesen
  • [was auch immer andere Kriterien Sie definieren]

Eine Frage, die man sich stellen sollte, ist, ob alle Geschichten fertig gestaltet sein müssen, wenn sie herauskommen. Wenn nicht, kann es hilfreich sein, nur das Interaktions-/Usability-Design im Voraus zu erstellen und das visuelle Design für später aufzuheben. Dies ist möglicherweise nicht ideal, da es eine Geschichte über mehrere Sprints zieht, aber es könnte die Vorabüberarbeitung hochwertiger Folien ersparen.

Einer der größten Vorteile, die Agile (und alle anderen ähnlichen Ansätze) mit sich bringen können, besteht darin, dass eine oder zwei Funktionen (PO und Designer) niemals wichtige Entscheidungen alleine treffen sollten – oder diese Entscheidungen unnötiger Nacharbeit und nachgelagerter Arbeit unterliegen ändern - das ist einer der Hauptgründe, warum Agile Ihnen schneller bessere Produkte liefern kann :)

Agile ermutigt alle Schlüsselfunktionen, als einzelnes Team zu arbeiten.