Die meisten UI-/UX-Designer sind eng vertraut mit ihren Sketch- oder Photoshop-Files und den dazugehörigen Master-Libraries. Sie haben eine eigene Art, wie sie ihre Gruppierungen und Symbole anlegen und benennen.

Nimmt ein Projekt jedoch eine gewisse Größe an und erfordert es die kollaborative Arbeit von (mehreren) Designern und Entwicklern und es kann zu viel “Unordnung” kommen. Gerade dann erfordern solch globale Designs nicht nur teamübergreifende Kollaborationen, sondern vor allem Konventionen.

Ein typisches Szenario zeigt das: drei Designer/innen sollen gemeinsam an einem Kunden-Projekt arbeiten, das bald in die Implementierung gehen soll. Nicht nur sie benötigen also immer den aktuellen Stand des jeweils anderen, sondern auch die Frontend-Entwickler sollten jederzeit Zugriff haben. Häufig werden die Sketch-Files via E-Mail, Dropbox oder WeTransfer versendet. Eine neue Version wird erstellt und mit geändertem Namen z.B. file_v02 bearbeitet und anschließend weitergeleitet - bis letzten Endes Verwirrung herrscht, welche Datei nun die Aktuelle ist. Doch noch schlimmer sind die Dateikonflikte, die über Dropbox entstehen. Mehrere Personen arbeiten an einem Design und speichern dieses gleichzeitig ab. So werden manche Änderung folglich nur teilweise oder gar nicht übernommen. Wer kennt das nicht? Doch…

…damit ist nun Schluss! Die Lösung: Abstract. Wir erklären, was dieses Tool kann und warum dieser Design-Workflow zum latest-state gehört.

Wer Git kennt, ist schnell mit der Funktionsweise von Abstract vertraut. Über den Browser und einer MacOS App bekommt man Zugriff. Als zentrale Cloud-Plattform ermöglicht es Design-Teams durch eine einfach Arbeitsweise zusammen zu arbeiten und Designs sowie Projekte zu managen. Anders als bei Git müssen hier keine Befehle in eine Konsole eingegeben werden, wodurch die Komplexität versteckt wird. Das macht Abstract besonders Designer-freundlich und unkompliziert. Sowohl Sketch, als auch Adobe XD werden unterstützt. Mit den drei Wörtern “version, control and share” (-www.abstract.com) zeigt Abstract auf ihrer Homepage, welche Vorteile das Tool bietet.

Abstract verfügt über ein sicheres File Management. Nachdem an einem Design gearbeitet wurde, müssen die Änderungen committet, d.h. bestätigt und aktualisiert, werden. Die Arbeit wird lokal  in einem temporären Ordner gespeichert. Nach dem Commit wird das File automatisch geschlossen und auf die Computer des Design-Teams und in die Abstract Server gesynct. Dies hat zwei Vorteile. Zum einen wird durch die lokale Speicherung der Files sichergestellt, dass offline gearbeitet werden kann und bei einem unerwartetem Abbruch des Programms keine Arbeit verloren geht. Zum anderen ist durch die Speicherung der Files in den Cloud Servern gewährleistet, dass auch bei einem Zusammenbruch des Computers alle Files weiter zur Verfügung stehen.

Abstracts Versionierung ist wohl einer der größten Vorteile des Tools. Jede Änderung eines Designs wird automatisch verfolgt und muss anschließend bestätigt werden - mit jeder Änderung entsteht folglich eine neue Verison. Der Zugriff auf ältere Design-Versionen ist garantiert und Designer können sich sicher in ihrer Arbeit fühlen. Sollte eine Änderung nicht den Vorstellungen des Kunden entsprechen, kann einfach eine neue Version geschaffen oder eine alte aufgerufen werden. In einer Art Timeline werden alle Commits und somit Versionen zeitlich geordnet angezeigt. Einzelne Screens können angeschaut und die Versionen mit dem “Compare” Button der Abstract Oberfläche verglichen werden.

Durch die Versionierung wird sichergestellt, dass Veränderungen stets nachvollzogen werden können.

1. Das Master-File kann nicht bearbeitet werden. Stattdessen werden einzelne Branches eröffnet. In diesen kann klar und nachvollziehbar strukturiert werden, welcher Teil des Designs bearbeitet wird. Dafür bietet sich eine Benennung wie folgt an: Feature/ABC-12345 Header. “Feature” steht hierbei für den einzelnen Branch, “ABC-12345” für die Ticket-Nummer, die in bspw. Jira vorgegeben ist und “Header” ist das Thema, worum sich die Änderung des Designs dreht. Solch eine konsistente Benennung ist zwingend notwendig um Klarheit, Ordnung und Nachvollziehbarkeit zu schaffen.
2. Fallen Veränderungen im Designprozess an, raten wir dazu, klar abgegrenzte Projektphasen zu verwenden. Mit den Abstract-Stati kann angezeigt werden, ob ein Branch momentan “Work in Progress”, “Open for Feedback” oder “In Review” ist. Solange an dem Design gearbeitet wird, sollte kein Feedback auf den Branch kommentiert werden. Ist dies nicht der Fall, können wertvolle Kommentare verloren gehen. Mit dem Commit wird auch das Feedback des Screen-Designs ausgegraut und leicht übersehen. Mit den Status kann dies nicht mehr passieren. Deshalb empfehlen wir die Projektphasen einzuhalten und einen Zeitrahmen festzulegen, wann und wie lange Feedback zu dem jeweiligen Branch gegeben werden darf.
3. Wird der Status “in Review” vergeben, können explizit Personen ernannt werden, die einen Blick auf das Design werfen sollen. Sie können den Branch freigeben oder die Zustimmung verweigern. Erst wenn der Branch diesen Prozess durchlaufen hat, wird er auf das Master-File gemerged. So entsteht ein “Single Point of Truth” für Designer und Entwickler.
4. Änderungswünsche können also in Form von Kommentaren und Anmerkungen bestimmten Partien des Designs zugewiesen und Designer bzw. Ansprechpartner durch ein “@” erwähnt werden.
   Ein kleiner Tipp von unserem Design-/Feedbackprozess: Kommentare, die umgesetzt werden, bekommen ein 👍, die tatsächlich umgesetzten ein ✅. Änderungswünsche, die nicht mit in das Design einfließen, erhalten ein 👎 und Kommentare, die Fragebedarf aufwerfen ein❓. So wird sichergestellt, das keine Kommentar unbearbeitet bleibt.

Unsere Best-Practices haben gezeigt, dass ein Design-Flow mit Abstract am Besten funktioniert, wenn diese oben genannten Grundregeln eingehalten werden. Durch die klaren Projektphasen und die strikte Rollenverteilung wird sichergestellt, dass jeder zu jedem Zeitpunkt weiß, was die “Next Steps” sind. So wird der Flow nicht unterbrochen und Feedback-Phasen schneller umgesetzt - eine performante Plattform für Designer und Entwickler.

Wie bei Git können in Abstract Konflikte entstehen. Arbeiten zwei Personen an einem Design und versuchen dieses in das Master-File zu mergen, weißt Abstract darauf hin, dass dies nicht geht. In diesem Moment kann eines der Designs, das optimalere, als Lösung gewählt werden, so dass es, wie bereits erwähnt, nur ein globales Design gibt. Eine weitere Möglichkeit, Konflikte einfach zu lösen oder gar zu vermeiden ist das Forken in “Childbranches”. Da ein Branch nur von einem Designer verwendet werden kann, kann ein Kinder-Branch des Eltern-Branches eröffnet werden. Hier kann das Design weiterentwickelt werden, genehmigt und anschließend in den Eltern-Branch gemerged werden, wo der andere Designer nun mit der bspw. optimierten Komponente weiterarbeiten kann.

Teamübergreifende Zusammenarbeit ist ein wichtiger Bestandteil heutiger Projekte, auch über Unternehmensgrenzen hinweg. Abstract unterstützt und erleichtert den Design-Workflow dabei ungemein. Mit einer Entwickler-Denkweise und einer designer-freundlichen Umgebung bietet Abstract viele Vorteile. Auch das Onboarding neuer Designer wird durch das Tool unterstützt. Die klare Strukturierung und abgegrenzten Projektphasen helfen Ordnung zu schaffen, wo vorher keine war. Wir können Abstract weiterempfehlen.

Der Vergleich zu anderen Tools hat gezeigt, dass Abstract auch bei großen Projekten Sicherheit für die Designer und Zugriff für die Projektinvolvierten gewährt. Ähnliche Programme, dazu zählen u.a. Figma, Kactus und zeplin.io verfügen über gleichartige Funktionen und können als Alternative zu Abstract gesehen werden. Je nach Vorhaben empfiehlt sich die individuellen Möglichkeiten der Plattformen anzuschauen und sich für das Tool zu entscheiden, dass Sie am Besten unterstützt.

Gerne beraten wir Sie rund um das Thema UX-Design oder gestalten Ihre Webseite entsprechend. Wir freuen uns auf Ihre Anfrage.