Abstract proof of concept illustration

How to pilot Abstract with your small design team

How to maximize your 14-day trial and thoughtfully introduce Abstract into your design workflow.
Design Ops

Note: If your design team is larger than 15, we recommend reaching out to our Sales team, who can guide Enterprise teams through a Proof of Concept.


A few weeks ago, we taught you how to pitch Abstract to anyone in our first post in a series we’re calling “The Champion’s Toolkit”. If you’ve already spread the good word of Abstract, the next logical step is to get a few folks on your team to start using it, together.

In this post, we’re sharing our best advice for piloting Abstract with your team. We’ll teach you how to maximize your 14-day trial and thoughtfully introduce Abstract into your design workflow. You’ll learn how to get you started and—most importantly—how to get everyone else on your team rolling with Abstract as well. By the end of your trial, you’ll be branching, committing, merging, and setting yourself up for a more collaborative design process.

T-15 day(s): Recruit your design friends

While Abstract is helpful for your personal design work, it’s a game changer for collaboration. Aha moments pop up as you’re working in Abstract:

“Cool! I can see what Shannon’s working on.”

“Wait, why did Andrew do that? Oh, right, okay, yeah – he explained it in his Commit message…”

“WHAT?!? KIMBERLEY DELETED EVERYTHING. Oh, what’s this restore button…?”

We recommend recruiting 1-2 fellow designers who are also design tool nerds excited about Abstract.

💡Pro tip: This is also the perfect moment to loop in the person who helps manage your Design System or shared libraries. Abstract makes their life a lot simpler.

T-10 day(s): Pick a project

To get the most out of your Abstract trial, you’ll want to start with a specific project (and specific design files) in mind. Look through your design ticket requests and choose 1-2 that follow the guidelines below.

Finite and new

Choose a project to work on in Abstract that has a clear beginning, middle, and end. While it’s tempting to jump into Abstract with two feet, you can learn the Abstract design workflow best when you’re not stuck wading through old explorations or overwhelmed by defining a new design direction.

Few stakeholders (and preferably not the cranky ones 😅)

We recommend choosing a project with a few stakeholders who are down to try something new. This means don’t start by pulling the redesign of your entire website into Abstract. Instead, start with a small update to the Account Settings page, or something similar in scope.

Learning a new tool is enough to ask, without the external pressure of tight deadlines.

Shared with the other trial participants

Pick a project that everyone participating in the trial can contribute to.

💡Pro tip: Dedicate a specific sprint to trial Abstract and make your plan beforehand. You’ll know at the end of your sprint whether the product is right for your team.

T-5 day(s): Understand how Abstract works

Once you’ve found 1-2 other designers and picked your project, it’s time to lay some groundwork to understand just how Abstract works. Before you kick off your trial with your team, all trial participants should:

✔ Watch the 60-min Abstract 101 Webinar

Test drive Abstract with sample files

  • Heads up, test driving requires that you begin your trial in order to have access to Abstract. You can wait until the morning of kick-off day to test drive, or you can watch the Test Drive YouTube playlist.

Once you finish these two items, you’ll have a great foundation to start your trial.

T-1 day(s): Cherry pick the library files and design screens you’ll import

Now that you know which project you’re going to be tackling with your Abstract trial, figure out which library and design files you’ll need to complete your project and locate them. You’ll need them when you start your trial for real.

If you’re anxious about bringing your design files into Abstract, rest assured that Abstract essentially creates a copy of your files within Abstract. Your original files remain untouched  wherever you originally stored them.

💡Pro tip: Only bring files over as you need them, not everything at once. In fact, we recommend creating new files for your trial, if possible, to keep the clutter down.

T-0 day(s): Kick-off Abstract trial at the start of your design sprint

Today’s the day! It’s time to sign up for Abstract. Once you do, you’ve got 14 days. On day one you should aim to:

 

Create your Organization

Download the Abstract macOS app

✔  Install all latest Sketch & macOS updates

✔  Invite your 1-2 fellow trial participants to join your new Organization

✔  Create your first project

  • Don’t worry about whether your first project is set up to scale perfectly with the rest of your team. Name the project for the platform of the project you’re tackling in the pilot, e.g. Website.

✔ Add your first files to your new project

  • You can either build brand new files (recommended) or import just the design screens you need. Make sure you name these files based on what they are, not based on who’s working on them, e.g. Account settings vs. Alden_Account settings page_V5_final.

Import your Library file(s) to the new project

  • Don’t worry about creating a separate Design System project just yet. For the trial, use your new project as the container for both your design files and your library files.

T+1 day(s): The Abstract design workflow

Now that your files, Organization, and team members are set up, you’re ready to try out the Abstract design workflow: Branch, Commit, Review, and Merge.

If you watched the Test Drive YouTube playlist, you’ll understand that in order to edit a design file in Abstract, you’ll first need to create a Branch. Do that, and then open your file in Sketch to edit.

Make some edits, and then click File > Save in Sketch. At the bottom of your screen, you’ll be prompted to commit your changes. Do it. Commits are like super-saves, but better. When you commit in Abstract, you’re creating a version of your files that you can return to. What’s more, you get to add context around the changes you made in your Commit summaries, which capture the thought process behind why changes were made.

Abstract commit

When you’re ready to get feedback from your teammates, request a review from them. They’ll be able to practice leaving you comments and annotations, and even approve your designs.

Got sign off from all trial participants? Merge your changes to Master.

T+3 day(s): Role play different use cases with Abstract

When you actually use Abstract with your team, you’ll have designers, engineers, stakeholders, UX writers, and more interacting within Abstract. Task each of your trial participants with acting out one of these scenarios.

✔ How would you get feedback from a non-designer stakeholder? Send them a Collection and use annotations to ask for specific feedback.

✔ You need to handoff your designs to an engineer. Send them a link with Inspect and Assets included.

✔ Designs are done, but copy needs some ❤️. Pretend you @mention your copywriter in a comment on the layer detail to get their input.

✔ You’re ready for your fellow designs to review your designs. Show them two design directions by creating a Collection for each version, and turning off auto-update on both.

T+5 day(s): Dive into Abstract, together

The thing about Abstract is that it’s made for collaboration. Nothing ever gets overwritten. There’s almost always a restore option (just be careful about deleting ❌). And you’re notified anytime one of your teammates impacts your work (by updating a Library file or updating Master by merging).

Try out some messy situations in Abstract, and see just how anxiety-free collaboration can be:

✔ If you like the direction your teammate is going, you can create a child Branch off of their Branch and riff off of their ideas.

✔ For fun, try updating a library file slightly. All of your teammates will receive a notification that tells them Library Updates Available. Never again will anyone have to export / import new library files when updates are made.

Merge your Branch to Master, and watch while your teammates are notified that there has been an update to Master.

✔ Pretend like that last merge was a mistake. Restore Master back to the Commit prior to your Merge.

T+10 day(s): Do a retro + clear up any misunderstandings

Did Abstract work for you? Did it not? At Abstract, we host post-mortems and ask:

  • What worked well?
  • What did not work well?
  • What we would do differently?

Here are some common misunderstandings first-time Abstract users face:

“Why can’t my teammates see my edits?”

At any time, your teammates can go into your Branch and see what kinds of design explorations you’re working on. Projects are open and transparent to all Organization Members. But your teammates won’t see changes to Master until you actually merge your Branch to Master.

“How do I export and save different versions of my Abstract files?”

Many people make the mistake of trying to treat their files in Abstract the same way they treated them before implementing Abstract. Where you used to export files and save different versions (e.g. Alden_Account settings page_V5_final), now you simply commit your changes in Abstract and a “version” is saved. Where you used to backup your files to Dropbox, Google Drive, or Box, now all your files, and your entire design workflow, live in Abstract and are backed up on our servers. You’re welcome to export an additional backup of your files if that helps you sleep at night.

“I don’t want to merge all my files together. I want to keep them separate!”

The language of “merging” can trip up some Abstract customers: When you merge in Abstract, you are not merging files together. Rather, you’re merging the changes you made on your Branch to Master. Your files keep their same architecture, and the changes to the file are merged.

T+14 day(s): Roll it out to the rest of the team

Once your trial team is confident that Abstract is right for your team, it’s time to roll it out to the rest of your teammates. Here are our recommendations for a thoughtful, frictionless rollout:

✔ Set up your Abstract Organization in a way that makes sense for the rest of your design team. Maybe you create projects by platform. Maybe you create a Design System project. Set up sections, where appropriate. The more you can do on the front-end to set up the Organization architecture, the better.

✔ After you’ve set up your Organization architecture, run your team through a demo of the work you did during your trial. Make sure to include your retro insights, with recommendations for how your team could best move forward with Abstract. Use our sample deck as a jumping off point.

✔ Need help getting buy-in? Take a look at our guide for how to pitch Abstract to anyone.

✔ Plan a natural transition time. Choose a window of time (we recommend a month) during which everyone can finish their last project, and naturally transition to Abstract with their next project. The less friction the move to Abstract causes, the more likely it is that your team will actually adopt it.

✔ Work through our “How we use Abstract” Worksheet with your design leaders. Thinking through the questions in this worksheet can streamline the Abstract roll-out.

✔ Create a Google Calendar event for “Abstract office hours” each week for about 45-min and invite your whole team. You can also create a Slack channel or email alias where your teammates can ask questions about Abstract.


Let us know how your trial and team onboarding are going on Twitter. You can also get help from fellow Abstract customers in our Spectrum community.

Read more of The Champion’s Toolkit

  1. How to pitch Abstract to anyone
  2. How to pilot Abstract for your small design team — you are here 📍
  3. How to bring your files into Abstract