Wie sollten wir UI-Designs an die Entwickler übergeben und ihnen ein Ticket zuweisen, um sicherzustellen, dass das entwickelte Design mit den bereitgestellten UI-Mockups übereinstimmt und gleichzeitig agil bleibt?

Ich habe das so oft mit Design erlebt. Es ist ein strukturelles Problem, wie Menschen und Teams organisiert sind. Jetzt möchte ich sagen, dass funktionsübergreifende Teams nicht agil sein müssen. Scrum erfordert sie, aber ich sehe nicht, dass Sie speziell Scrum verwenden. Das heißt, die Struktur von "Designteam erstellt Design und das Entwicklerteam implementiert" führt direkt zu dem, was Sie hier haben.

Wenn Sie ein Team von Designern haben, die ein Design erstellen, gibt es zwei Möglichkeiten. Erstens können sie ein Tool wie Photoshop verwenden, das Grafiken so anders als das Web rendert, dass der Versuch, sie perfekt zu übersetzen, ein Witz ist. Zweitens können Sie ein Tool wie dieses verwenden, bei dem der Designer lediglich eine HTML/CSS-Webseite erstellt.

Dann versuchen die Entwickler, es zu bauen, aber das Tool hat viele der HTML/CSS-Details in einem seltsamen Versuch verschleiert, die Designer vor unheimlichem Code zu schützen.

Die einfache Lösung, Designer sollten den HTML/CSS-Teil der App erstellen und damit fertig sein. Wenn sie das tun können, was Sie verlinkt haben, können sie die HTML- und CSS-Präsentation erstellen. Noch einfacher wird es, wenn Designer und Entwickler im selben Team Hand in Hand arbeiten.

Ein paar kurze Vorbehalte:

1. Eine häufige Ausrede, die ich gehört habe, ist, dass es zu technisch ist. Tut mir leid, aber ich muss BS anrufen. Ein bildender Künstler ist ein Experte für die Eigenschaften von Graphit und Farbe. Ein Musiker versteht, wie sein Instrument aufgebaut ist und wie es funktioniert. Es ist nur ein Medium und der Grafikdesigner muss das Medium verstehen, in dem er arbeitet.

2. Das heißt, es kann eine Anlaufzeit geben. Ich empfehle dringend Paarprogrammierung, um die Fähigkeit aufzubauen (und der Experte sollte der Beobachter/Helfer sein, nicht der Macher).

3. Eine andere Möglichkeit, die meine gesamte Antwort tatsächlich entkräften würde, besteht darin, dass die Plattform, auf der Sie entwickeln, eine ganze zusätzliche Abstraktion über der HTML / CSS-Schicht aufbaut, sodass Sie, obwohl sich am Ende alles daraus entwickelt, nicht wirklich darauf zugreifen können HTML/CSS. Ich habe das oft mit CMS gesehen. Diese können einige Lösungen annehmen, die weitaus kreativer sind als das, was Sie auf einem Q&A-Board finden, und ehrlich gesagt verdienen sie wahrscheinlich ein ernsthaftes Gespräch darüber, was dieses Framework für Sie auf den Tisch bringt. Im Allgemeinen funktioniert die Verwendung einer solchen Abstraktion jedoch am besten, wenn Sie streng innerhalb der voreingestellten Grenzen dieses Rahmens entwerfen.

Lassen Sie mich den Rahmen Ihrer Frage ein wenig herausfordern:

Warum haben Sie so spezifische Anforderungen , die sich für jedes Ticket ändern ?

Ist es wirklich notwendig, unterschiedliche Ränder zwischen Schaltflächen auf verschiedenen Seiten zu haben? Ist es notwendig, unterschiedliche Stile für Dinge auf verschiedenen Seiten zu haben? Ist es nicht die Aufgabe eines Designers, einen erkennbaren Stil für die gesamte Anwendung zu schaffen?

Ihr Designer sollte eine Stilrichtlinie für die gesamte Anwendung haben. Dort können sie Dinge wie Standardränder, gängige Auffüllgrößen, Bildgrößen und das allgemeine Aussehen von Schaltflächen in Ihrer App definieren. Welche Farben wann verwenden.

Ihre eigene Arbeit sollte nicht darin bestehen, zu glauben, dass es heute 7px sein sollte, weil es ein Montag ist und es gut aussieht. Es sollte 7px sein, weil der Styleguide sagt, dass diese Anwendung es mit 7px macht.

Sie müssen also nur die Abstracts und die Gestaltungsrichtlinie in den Tickets verwenden. Wenn Sie eine „Definition of Done“ haben, können Sie sie sogar dort platzieren, sodass Sie sie nicht in jedem Ticket buchstabieren müssen.

Der Punkt ist: Wenn Sie in jedem Ticket wechselnde Anforderungen haben, tut es mir leid, ja, Sie müssen sie buchstabieren. Aber Sie sollten keine sich ändernden Anforderungen haben, es sei denn, Sie möchten, dass Ihre App wie ein verrückter 13-Jähriger auf seinem ersten Espresso aussieht. Gutes Design hat Regeln. Schreiben Sie sie auf und geben Sie sie an Ihre Design-Implementierer weiter, damit sie sich an die Regeln halten können.

Agile lebt von der Zusammenarbeit zwischen Menschen, anstatt Mauern um jedes Team zu bauen und Dinge darüber zu werfen.

Die ideale Situation wäre, dass die Designer im selben Team wie die Entwickler arbeiten und ihre Designs erstellen, während die Software entwickelt wird, wobei die Technologie verwendet wird, um die Designs bereitzustellen. Auf diese Weise ist der Designer derjenige, der das Design tatsächlich umsetzt.

Wenn dies nicht möglich ist und die Designer in einem von den Entwicklern getrennten Team bleiben müssen, würde ich mich für eine Variante Ihres ersten Ansatzes entscheiden:

1. Die Designer stellen einen abstrakten Link bereit, der das Design für eine Geschichte/ein Feature zeigt. Dies wird so spät geliefert, wie es verantwortungsbewusst möglich ist, vorzugsweise kurz bevor der Entwickler das Design benötigt, um die Implementierung abzuschließen.
2. Bevor mit der Umsetzung des Designs begonnen wird, setzt sich der Entwickler mit dem Designer zusammen, um das Design zu besprechen (welche Aspekte konnten nicht im abstrakten Link erfasst werden, welche Teile müssen pixelgenau sein und wo hat der Entwickler Spielraum, um abzuweichen usw.)
3. Die Arbeit ist erst abgeschlossen, wenn der Designer bestätigt, dass der Entwurf wie vorgesehen umgesetzt wurde. (Wenn das Vertrauen wächst, könnte dies übersprungen werden)

Dies behandelt die Probleme, wie Sie den Ansatz auf folgende Weise durchgeführt haben:

• Indem das Design so spät wie möglich erstellt wird, sollte die Anzahl der Änderungen zwischen der Erstellung des Designs und seiner Implementierung begrenzt werden. Dadurch muss ein abstraktes Design seltener aktualisiert werden.
• Der Überprüfungsschritt sollte die Punkte erfassen, an denen der Entwickler vom Design abweicht, ohne den Designer einzubeziehen.