For Designers

If you're just starting out designing with Masala Design System, here's a checklist of everything you need to get up and running.

If you do not have access to Figma already, feel free to reach out to get the invitation.

Once you get the invite, sign up using your Innovaccer account to get access to Innovaccer org in Figma. It is highly recommended to add a profile picture so that it is easy to identify you across Figma.

You can invite the product managers, developers, and other stakeholders from your team to a particular project/file using the Share feature of Figma.

Make sure the access permission is set to ‘can view’ when sharing unless you want them to edit the file. Please note that editors are paid seats in Figma.

Guests are folks who are not part of our organization; however, you can still share your work with them. You may give them ‘can view’ or ‘can edit’ access but be wary that they are not part of Innovaccer Inc.

If you want to use the Masala Design System in your own organization in Figma, you can download the files from the community and then publish each of them as a library.

Note: You will not be able to get real-time updates in this case.

The root level in Figma is an organization which in our case is Innovaccer Inc. An organization can have many teams depending on how it operates. We have a predefined set of teams and projects to begin with.

Once you sign up, you will be able to see all the teams in Innovaccer Inc. You can easily become a member of a team by just clicking on the respective Join button.

When you join a team, the permission is set to ‘Can view’ by default. You’ll need to contact the owner or the admin of the team to get ‘Can edit’ access.

Projects help you group similar files. A team in Figma can have as many projects as you would want. However, to avoid overcrowding it is recommended to follow the predefined projects as shared earlier.

A project can have multiple files. You can create different files within a project as per the requirements. If a feature or workflow is too large or complex to fit in a single file, it should be in a separate file.

For example, the project InNote can have the following files-

A file should be tagged using a prefix, if needed, for easy identification. Tagging is also helpful when two or more files have the same name but serve different purposes.

InConnect can have the following files, for example -

It is recommended to maintain and respect file hygiene so that if someone visits your file they should be able to get a rough idea of the workflow.

In a single file, categorize parts of your projects into Pages as shown. This helps in keeping the file organized and easy to understand for others.

Example: Patient List - Filters - ICU Applied. This name indicates that the screen contains a list of patients. There are filters present to filter the list. The ‘ICU’ filter has been applied to that list.

In a single file, categorize parts of your projects into pages as shown. This helps in keeping the file organized and easy to understand for others.

You should have a separate page for cover, typically the first one. You can set a frame as thumbnail which acts as a cover for your projects outside the canvas for easy identification.

To ease this process, we are providing a Cover component in Design Library (can be found in Utility).

On top of this, you may also add frames for intro, personas, etc. in this page.

As the name suggests, this page acts as a playground for your project. Anything that you want to try out goes here.

If you need to show a short and quick workflow out of your project to an external stakeholder, this is the place. Keeping these sorts of prototypes in a separate page helps in keeping the main prototype (present in Page 1, Page 2, etc.) clean and organized.

Any local symbols/components you create in your file go in this page.

*=optional

Figma has started offering version control recently. You can create branches just like Abstract and request for review. This feature is not as expansive as Abstract though.

Just like Abstract, you should create a branch for -

This way the main file which is shared with the developers and other stakeholders, stays unaltered until the designs have been finalized and merged into it.

P.S.: Avoid making changes in your main file if you do not want the developers/stakeholders to act surprised of the changes every time they open the file.

Following good naming practices helps understand what a branch is all about at a glance.

A typical branching nomenclature is as follows -

{PREFIX} {ISSUE-ID or MODULE NAME} - {FEATURE NAME or DESCRIPTION}

Prefix make it easier to identify and understand the purpose behind your branch.

You can enable a specific design library by going to Assets panel and clicking on the ‘Open book’ icon.