How to organize Projects in Abstract

A great time to establish a structure and system that scales with your team is when you’re setting up an organization in Abstract. At the file level, this might look like naming conventions for artboards, symbols, or file structure. At a higher level, agreeing on how you’ll use projects will impact how your teams will operate in the future. In this post, we’ll cover a couple of common ways that internal design teams and client-facing teams set up projects.

Types of projects

Projects are how we organize our files, branches, commits, collections, and feedback. They’re essentially an organizational layer for what you’re working on.

Team Projects

Each organization can create a Team Project to organize their work and initiatives. Some organizations use Team Projects to manage specific products or platforms, and others use them to separate client work. A Team Project is accessible to all members of their respective organization. You can also invite guests to Team Projects.

Private Projects

Private Projects are available for organizations on both Abstract’s Pro or Enterprise plans. A Private Project is only accessible to members or guests who have been specifically invited. Private Projects are a great way to work on client-facing work or a top-secret mission.

Personal Projects

When you join an organization on Abstract or set up a new one, a Personal Organization is created for you by default. Any Projects you create in this space are Personal Projects; you’re the only person who can access them. Since they’re limited to a single user, you can use Private Projects as a playground for testing new ideas and ways of working within Abstract. You can belong to as many Organizations as you’d like and carry your same username and work in your Personal Org with you in Abstract.

Using projects for internal design teams

With internal teams, we frequently see two main use cases. While there is no perfect way to set up Projects for your team, these two examples can serve as a good starting point.

Projects by Platform

One of the more popular ways teams set up their projects is by platform. For example, Abstract is available on two platforms today, as a desktop Mac Application and as a Web App. These platforms share some of the same symbols, which can be accessed through a Linked Library. Teams will keep iOS, Mac, and or other platform’s respective files separate in their own Projects. This method is a simple, repeatable structure, for an organization with a handful of products used across multiple application platforms.

Pros: Clear space for different platform variations of your product. Keeps most files and work in the same place without creating large files with variations of the product across multiple platforms. Consolidation and simplicity to help scale.

Cons: Potentially large project size depending on the product. Less granular organization at the project level.

Projects by Feature

For teams focused on driving a single product forward, we see projects structured by feature. This works really well for large teams that are each focused on different aspects of a product. It also provides a more immediate layer of orientation at the project level for the team and new users.

Pros: More granular organization at the project level. Potential to have smaller projects sizes, with more focused projects.

Cons: May require a discussion with your team about changes to your existing workflow, optimal naming conventions, and where/how you separate your files.

Projects by Client

For teams at agencies, we typically see clients invited to Private Projects as Guest Viewers. Users, external to your company, invited to a Private Project will only have visibility and access to that project. Internal team members you work with will be able to see all Team Projects and Private Projects they belong to as well.