Abstract - "Git for designers"

Most UI/UX designers are very familiar with Sketch or Photoshop files and their corresponding master libraries. These have their own way of creating and labeling groups and symbols.

However, when a project grows to a certain size and requires the collaborative work of (multiple) designers and developers, there can be a lot of "chaos ". Particularly then, such global designs require not only cross-team collaboration, but also, and most importantly, conventions.

A typical scenario illustrates this: three designers work together on a customer project that is soon to go into implementation. This means that not only the designers always need to be aware of each other’s status, but the front-end developers should also have access to the project at any time. Often the sketch files are sent via e-mail, dropbox or WeTransfer. A new version is created and edited with a changed name, e.g. file_v02, and then forwarded - until in the end there is confusion about which file is the current one. Even worse are the file conflicts that arise via Dropbox. Several people work on a design and save it simultaneously. As a result, some changes are only partially accepted or not accepted at all. Most people will probably recognize this…but...

...that's over now! The solution: Abstract. We explain what this tool can do and why this design workflow belongs to the latest-state.

If you know Git, you will quickly become familiar with how Abstract works. You get access via browser and a MacOS app. As a central cloud platform, it allows design teams to collaborate and manage designs and projects through a simple way of working. The tool hides the complexity of Git, so there is no need to type commands into a console. This makes Abstract especially designer-friendly and uncomplicated. Both Sketch and Adobe XD are supported. With the three words "version, control and share" (-www.abstract.com) Abstract shows on their homepage which advantages the tool offers.

FILE-CONTROL (BACKUPS AND MORE)

Abstract has a secure file management. After working on a design, the changes have to be committed, i.e. confirmed and updated. The work is stored locally in a temporary folder. After committing, the file is automatically closed and synced to the design team's computers and to the Abstract servers. This has two advantages. First, the local storage of the files ensures that work can be done offline and that no work is lost in case of an unexpected termination of the program. Second, the storage of the files in the cloud servers ensures that all files are still available even if a computer breakdown occurs.

VERSION-CONTROL

Abstract's versioning is probably one of the biggest advantages of the tool. Every change of a design is tracked automatically and must be committed. Access to older design versions is guaranteed and designers can feel secure in their work. If a change does not meet the customer's expectations, a new version can simply be created or an old one called up. In a kind of timeline all commits and thus versions are displayed in chronological order. Individual screens can be viewed and the versions can be compared using the "Compare" button of the Abstract interface.

CHANGE-CONTROL (REVIEWER)

Versioning ensures that changes can always be tracked.

1. The master file cannot be edited. Instead, individual branches are opened. In these branches it can be clearly and comprehensibly structured which part of the design is being edited. The following naming scheme is suitable for this purpose: Feature/ABC-12345 Header. "Feature" stands for the individual branch, "ABC-12345" for the ticket number, which is given in e.g. Jira, and "Header" is the topic of the design change. Such a consistent naming is absolutely necessary to create clarity, order and traceability.
2. If there are changes in the design process, we recommend using clearly defined project phases. With Abstract states it can be shown whether a branch is currently "Work in Progress", "Open for Feedback" or "In Review". As long as the design is being worked on, no feedback on the branch should be commented. If this is not the case, valuable comments can be lost. With the commit, the feedback of the screen design is also grayed out and easily overlooked. This can no longer happen when using statuses. Therefore, we recommend that you adhere to the project phases and set a time frame for when and how long feedback can be given to the respective branch.
3. If the status "in review" is assigned, persons can be explicitly appointed to take a look at the design. They can release the branch or deny approval. Only after the branch has gone through this process is it merged to the master file. This creates a "single point of truth" for designers and developers.
4. Change requests can therefore be assigned to specific parts of the design in the form of comments and annotations, and designers or contact persons can be mentioned with an "@". A little tip from our design/feedback process: comments that are actually implemented get a 👍, those that are actually implemented get a ✅. Change requests that are not considered in the design get a 👎 and comments that raise the need for a questionnaire get a question mark❓. This ensures that no comment remains unedited.

Our best practices have shown that a design flow with Abstract works best when these basic rules are followed. The clear project phases and strict allocation of roles ensure that everyone knows what the "Next Steps" are at all times. This way the flow is not interrupted and feedback phases are implemented faster - a high-performance platform for designers and developers.

As with Git, conflicts can arise in Abstract. If two people are working on a design and try to merge it into the master file, Abstract knows that this is not possible. At that moment, one of the designs, the more optimal one, can be chosen as the solution so that there is only one global design. Another way to easily solve conflicts or even avoid them is to fork into "child branches". Since a branch can only be used by one designer, a child branch of the parent branch can be opened. Here the design can be further developed, approved and then merged into the parent branch, while another designer can continue working with the optimized component.

Cross-team collaboration is an important part of today's projects, even across company boundaries. Abstract supports and facilitates the design workflow immensely. With a developer way of thinking and a designer-friendly environment, Abstract offers many advantages. The tool also supports the onboarding of new designers. The clear structure and delimited project phases help to create order where none existed before. We strongly recommend the use of Abstract.

We would be happy to consult you on UX design or design your website accordingly. We are looking forward to your request.