Keeping distributed UX teams in sync

Over the years there has been a great shift in the perceived importance of user experience within the world of software. There have always been a few companies who prioritized a consistently great experience for their users. Today though, most of the software industry accepts that a prioritized user experience and an intuitive user interface translate into increased market share.

Results of this change in perspective have been far reaching

Specialized design roles
There’s been a proliferation of new job titles appearing (UX Designer, Data Scientist, UI Designer).

New ways of working
Design sprints, lean ux, and others are changing design team workflows.

UX teams have become larger
To gain benefits from this new way of working while not becoming a bottleneck we’ve had to add more people to our ux team (ACL’s team has grown from 4 to 14 spread across multiple timezones over the past 5 years).

Growth challenges at ACL

As our UX team has grown, one of the challenges that we’ve come across is maintaining communication and consistency between designers. More than developers, designers are idiosyncratic — each one of us can have a different idea on how to solve the same problem.

It’s vital to set up a good system that allows all your team members to stay in the loop about design decisions. Make it as easy as possible to share their work, get feedback, ratify and test designs regardless if they are local or remote workers.

Suggested best practices

While each UX team is different, these are some of the best practices that we’ve found work for our team.


Use a version control system (VCS)

Using a VCS does so much to organize your team’s files it’s almost a no brainer. Along with avoiding the dreaded “finalversion1, finalversion2, reallyfinalversion” file naming issues. VCS’s make it extremely easy to share and view everyones’ work from anywhere in the world. Given that a (very simple) VCS is built into both Dropbox and Google Drive, you may already be using one.

Designer specific VCS’s are relatively new, but they can add a lot of value to your workflow — especially if you (like our team) use sketch for the majority of your design work.

Popular designer VCS’s

  • Abstract— the current leader in the field, Abstract has a slightly different workflow from Git but has a ton of features to help a distributed team work together. We use Abstract at ACL.
  • Kactus— an open source alternative to Abstract, Kactus can integrate with Github. The UI is not as polished as Abstract’s, but it may be a good alternative for teams wanting to centralize their design data with their developers code.
  • Plant — designed as a sketch plugin, Plant has a simplified view of version control (no branches) but a great approach to resolving conflicts.

Document your design decisions with a ‘pitch’ process

As your team grows, the number of previous decisions each designer has to consider during their process increases exponentially. Adopting a formal process where individual designers write “pitches” (short, standardized documents that describe a design guideline) to rationalize their decisions to the broader team can reduce that mental burden to remember old decisions. Pitches are also useful to formalize existing design patterns that are inconsistently applied across the platform.

Advantages of a formal pitch process

  • Minimize the need for time consuming, individual research.
  • Help keep all members of the team in sync on the current design guidelines in use.
  • Allow remote designers to play on the same field as in-office designers since written documents can be commented on, while in-office discussions can’t.
  • Give your team member an easy process to follow when other teams ask your ux designer to create a standard for a common interface (who should we put in the placeholder text for forms? Where should buttons be in a modal by default?)

This process doesn’t have to be complicated either. Here at ACL, we have a simple set of questions that we use for the majority of our UX “pitches”. Whenever a designer wants to standardize a design guideline across our platform they go through our pitch process.

Pitch process

  1. Fill out a short pitch document describing the proposed guideline.
  2. Share the proposed guideline with the UX team.
  3. The UX team reviews the pitch and provides feedback, comments and suggestions.
  4. Update the pitch based on the feedback received.
  5. When all concerns are addressed the pitch is approved by our two senior designers.
  6. Approved pitches are integrated into our design system.

This simple framework allows our designers to move forward much quicker by building on the team’s combined experience. Designers no longer have to search through email, Slack messages or remember decisions made in meetings that took place 3 months ago.

We’ll be sharing more details on our pitch process (and the template we use) in a later article.

After you’ve implemented a written approval process, it’s very little work to turn these pitches into design guidelines that document how and why your interface is designed the way that it is. But don’t stop at centralizing your design decisions — think about your mockups and prototypes too.


Embrace shared libraries

Abstract, Figma, InVision Studio, and almost every serious UI design tool these days has some kind of library as one of their primary features.

There’s good reason for this; being able to share design elements within your team saves everyone a ton of time and allows the efforts of your team to be organized. It’s too easy for team members to silo themselves and create slightly different versions of everything whether they be simple buttons or more complicated searchable tables. Shared libraries will prevent this from happening and let your team focus on designing a better experience rather than the same but different UI.

Your shared team library is a visual representation of the pitch documents your team writes. Both processes work in tandem to really tighten up the core elements that make up most of the interface in your project.

Here at ACL, our shared library resides in Abstract to take advantage of version control. Almost all changes to that shared team library end up having a pitch document attached to them. This ensures that everyone is on the same page on how and why a base level element will be changed. This brings us to the last point…


Sharing should become a long term habit

All of the best practices above are designed to do one thing: make it as easy as possible for team members to contribute. Although it may seem it easier and quicker for a single designer to forge ahead on their own, the long term benefits of keeping your team in sync can’t be overstated. Documenting pitches for the rest of the team and getting design elements built in a shared library takes extra time up front, but the long term benefits are totally worth it.

At ACL, one day per three week sprint the whole UX team dedicates a full day to UX initiatives. During the sprints themselves our senior designers set aside a percentage of their time for these initiatives. This removes some of the pressure around the“extra” work involved with these practices and helps to keep this vital information flowing through the entire UX team.


Hopefully the above practices and recommendations will help you think about ways to improve your team’s workflow. If you’ve taken a different approach and have a solid process to keep your team in sync, let us know. We’re always looking to improve as a team and would love to hear about it.