The rest of the files represent different parts of the app — Onboarding, Mail, Calendar, Search, Settings and more. Separating each category helps us avoid slow files and lag while we work. It’s also an advantage when merging designs, because when we create new features we often only need to touch certain parts of the app, which in return means fewer conflicts

Stepping through the design process

The first step is to create a branch, which takes all the Sketch files in the master and creates a replica. Think of it like duplicating a folder. To identify the branch, we assign a simple label to the piece that we’re working on, appending the appropriate title after the label. We typically use labels like “Feature,” “Kit,” or “Exploration” to describe the project. At Outlook, we’re encouraged to try new ideas and change anything we think can be improved — that’s when we use a tag like “Exploration.” These labels give other team members some context and help them to find and understand what we’re working on. Creating a branch is a huge advantage because it means that multiple designers can work on the same files and later merge them back into the master.

Branch labelling example

In the new branch I create a new file from within Abstract. I name the file something like “Working,” which helps others to know where the latest iterations are. Then I can copy artboards from other files into this one — it helps to visualize a flow or change an existing screen.

Create a “working” file

A Sketch file opened from Abstract contains a little floating dialog with the option to Preview & Commit. It saves work to the server and allows others on the team to see any changes. Commit doesn’t affect the master, it just updates the branch. In my team, we like to follow the general rule of committing work once a day. Before I commit changes, I add a descriptive note that outlines the changes I’ve made. I always have access to every change, so if necessary, I can revert a change or look through the previous versions of a file.

Commit daily

Once a design is complete, it’s time to tidy the layers and merge the design to the master files. Make sure the layer names are accurate and the order follows what you see on the screen (from top to bottom). This should be repeated for every screen. I can either create another new branch labeled [Kit] and copy in the new screens to the appropriate file, or I can re-create these screens from scratch using the latest library components. The reason I start a new file is to bring in only the main screens to the master. I can always revisit the old branch in the Abstract archive later. It’s a little time consuming and discourages us from merging features more regularly. We’d love to hear from anyone who has suggestions for improving the merge process.

Below is a demonstration of how we can create a branch and use the UI components from the library to design screens in our app. It is this combination of Abstract and our component library that allows us to work quickly and efficiently while giving full transparency and visibility to the team. We’re working from the same files and our new files are available to everyone.

Image description: Building Outlook screens using our UI components.

Before selecting the merge button, I can request a review from anyone on the team. We look out for linked symbol layers, correct naming, duplicate symbols, and changes in the library. Reviewers usually leave feedback in the comments section of Abstract or on specific artboards, keeping everything in the same place. Once reviews are complete, we merge the design and archive the old branch.

Best practices for maintenance

My team shares the responsibility to update the kit with their features and I lead to work to keep the Sketch files healthy and continuously improve and update the kit—particularly to account for operating system updates or for major design overhauls.

Designers can give feedback on the kits at any time, raising issues or initiating conversations about potential improvements. We track this feedback in a GitHub issue, allowing anyone on the time to contribute. Below is an example of the kinds of feedback we tracked for the UI-Kit, including removing duplicate icons and adding color overrides to all icons.