Abstracting the Microsoft Outlook Design Process
How Abstract improved file organization and collaboration in our design team
As a designer, I’ve used various tools for file storage and team communication, but none have been very robust. I can think of countless times I’ve lost a file or spent hours looking for someone’s most up-to-date design — wasting precious time and energy.
Developers have had version control systems like Git for a while, but similar mechanisms for designers haven’t been available — until now.
Abstract is a tool built to help our designers to collaborate on projects. It provides our with team a central hub for our design work, helping us manage and maintain design components and files. Designers import Sketch files into Abstract once, and then we simply open the files from there.
A few years ago, Miles and Victor started using Abstract in the Outlook team and it has since been adopted in design teams across Microsoft. In this post, I’ll discuss how we use Abstract and will share with you our file structure, merging process, file maintenance practices, and some areas of our process that we think could be improved. This process works for a large team but we’re still figuring it out and would love to hear ways we could improve this.
Designing a project’s file structure
Our projects are divided by platform — Android, iOS, Mac, Web, and Universal (Mail and Calendar on Windows 10). Inside of these projects our files are divided into various sections of our app. Below is an example of our iOS file structure inside of Abstract where we separate our files into sections like “iOS UI-Kit,” “Mail,” and “Calendar” to keep the files running quickly.
First, Start Here is a file for new designers and external partners. It contains information about our design principles, how to use Abstract, exporting assets, and a few tips and tricks about using Sketch plugins.
Next, UI-Kit is the Sketch library, which contains all our components, typography, icons, and color. All screens in the design files use linked symbols from this library.
The UI-Kit is divided into two pages — one for symbols and another for all the design component sticker sheet. The latter includes detailed information about each element and an intuitive layout so we can quickly find what we’re looking for.
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.
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.
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.
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.
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.
Our process and UI-kit has been embraced by design teams across Microsoft as we design with a more open and collaborative approach. As Fluent Design evolves on mobile, we’ll see common elements through Microsoft products.
We’re still learning and are constantly looking for ways to improve our process. We’d love to hear how other teams are using Abstract in their design process and suggestions for how we could improve ours.
Feel free to share your ideas in the comments 💬.
To stay in-the-know with Microsoft Design, follow us on Dribbble, Twitter and Facebook, or join our Windows Insider program. And if you are interested in joining our team, head over to aka.ms/DesignCareers.
Written with 💙 and the help of Miles Fitzgerald and the Outlook Team.
