Master is the most up to date version of your design files stored in the Abstract cloud.
As designers, we have often thought about having one master file for a product, feature or experience. That is how other tools have treated the idea of master files or how we treated it in our previous use of cloud file storage. At Abstract, we are shifting that mental model by breaking that one file into multiple files. This allows for faster syncing time and transparency on who is working on what part of your product or feature.
Each designer on your team will sync these master files to their local computer using the Abstract app so that they can work locally on the files within Sketch or XD. When a designer has made the changes to the files and their work is approved or goes live in production, the designer will merge their changes to master. Abstract will sync these updates to all local computers of the team members working in the project.
Defining what files make up your master is fundamental to utilizing Abstract’s design workflow. Your master is made up of the file or files that contain the designs either currently in production or approved by your team.
For instance, if you are working on a mobile iOS banking app, your basic structure may look something like this.
Based on the sitemap above, these are the files that would be in your iOS app project:
- Home Screen
- Banking Accounts
- Transfer Funds
- Pay Bills
- Mobile Deposit
We suggest you set up your files in master to reflect the sitemap or information architecture of your product. You can also use pages within a Sketch file to create more hierarchy or structure in your project. For example, in the “Pay Bills” file you might have a page for “Auto Payment” designs and a page for “Manual Payment” designs.
Since files are organized alphabetically in Abstract, we encourage you to add a number to the file name to view your files in a specific order. Using your sitemap and numbering system, your project would be called “iOS app” and your master would look like the screenshot below.
Each design file should contain the most up to date (either in production or approved by design) artboards to show different flows and UI screen states for each section.
One of Abstract’s core strengths is managing and distributing your library files that contain reusable components. You can add library files to your project’s master by creating and importing a file and selecting Use as Library. Library files added to master usually contain symbols that you will need to update often during your day to day work on this product. Design teams using Abstract often have a Project Components.sketch library or Toolkits.sketch library which contains symbols that are made up of grouped or nested symbols. You can also place instances of large components in your artboards and then detach the symbol to continue working with it.
When building your master, you can also link library files from your design system projects. These linked libraries contain your atomic level symbols that are clearly defined and don’t often change – think colors, typography, icons, buttons, inputs, etc.
Since master is the source of truth for all of your design files in a project, it is protected from direct change. When you do want to update master and affect the source of truth, you’ll merge in the changes you made on one or your branches.
We’ve heard that merging feels like a big deal and knowing when to merge to master can be challenging. Let’s make it a little simpler.
If you’ve decided that your project’s master represents work that has been approved by design, then that will be your guide for when you will merge any of your branches in that project.
For example, imagine that you are redesigning the onboarding screens for the mobile iOS banking app above. When you have reached the point that your designs are finished, you should have the team lead or design manager review your work in Abstract. Once that work is approved, you can merge your branch to master.
When master is defined as “approved by design,” collections on master will represent the source of truth for patterns that the design team as a whole has agreed upon as a standard for the product or company.
You may have decided instead that your project’s master should represent designs that have been approved and have been fully developed and implemented in the live product. If this is the case, then you will only merge branches back into master after development has been completed.
Following the same mobile iOS banking app example, when your master is defined as what’s in production, you would not merge your branch with the onboarding redesigns until after engineering has completed their work and released the updates.
When master is defined as “what’s in production,” collections on master will represent how the designs look in the current implementation of the product, as users see it.