✅ Creating UI design mockups, assets and prototypes.
✅ Getting feedback on designs from various stakeholders.
✅ Ideating on concepts by using sketches, wireframes and FigJam.
✅ User testing.
Don’t Use For...
⛔️ Feature documentation. There might be some exceptions, but stick with Notion for anything documentation related.
⛔️ Task management. Use Asana instead.
⛔️ File sharing. Store files on Google Drive instead.
Why we use it
Figma is web based and easily accessible even without signing up for an account. Its real time collaboration is currently unmatched. Stakeholders can review designs in real time and leave feedback in the tool directly. Figma is usually pretty fast and also perfectly suited for building and managing design systems. It also has a version history feature which is very useful when multiple people work on a large file.
How we use it
The DRI usually creates a project for the client in Figma. Then, everyone involved will be added to the project (designers, copywriters, QA engineers, client). Designers get editing rights while others usually don’t. Projects can usually include multiple files, as some clients will have multiple projects.
A project usually consists of multiple pages, which can be accessed using the left hand side navigation. It’s up to the DRI or the designer to define the structure of the pages. This could be:
- Desktop Designs
- Mobile Designs
- Scrap Work
In general, the ‘Components’ page is where all the UI content layers will be defined. Most projects have a Components page. The ‘Scrap Work’ page usually stores older mockups that the designer experimented with.
The ‘Components’ page is usually very important as lots of a website’s components will be children of a master component. Master components are usually stored on this page. UI Assets, such as icons will be master components. They are usually exported from the Figma file and uploaded to Google Drive so that everyone can access them at anytime.
Product design projects are usually more complex and involve a separate file called a ‘Design system’ file. This is where all UI master components are usually stored. Design system files are much more thorough and store lots of UI information such as color definitions, typography or grid details. A good example is Element451’s design system file called ‘Bolt UI’.
In some cases, depending on the complexity of the project, the designer might use different indicators to highlight the status of a design.
This is not mandatory and should be agreed upon between the designer and the DRI. In the case above, the yellow marks a screen that is in progress, while the green marks a design that has been approved. We also recommend the Figma plugin ‘Is it done yet?’ for marking the status of a design.
Using the ‘Comments’ feature, we also use Figma to receive client feedback or ask for details on how a feature might work. Some clients prefer not to use Figma for that, so emailing/slacking them might be a better option.
Copywriters can work together with designers on a Figma file. Copywriters can leave comments and designers can implement the suggested copy in the designs. Sometimes, this is done during the development phase to save time.
Same goes for QA, as engineers will often review designs in Figma and report issues using the comment feature.
Typography, colors and grids are defined by the designer early in the project. Figma calls these definitions ‘Styles’ and they can be viewed when not having an element selected. These will be useful when developing the site.
Once the designs have been QA’ed and are approved by the client, the project moves into the development phase.
- Group designs in ‘Pages’. It can be difficult to navigate through many screens at once, so guide the visitor through the designs by giving them context.
- Define styles early in the project and adjust them as needed. Apply the styles to all UI elements as much as possible.
- Create components and reuse them as often as possible. Designing consistent UI is key.
- Give layers clear names whenever possible.
- Get designs reviewed / QAed before moving into development.
Ty’s training with Liam
Rules of Thumb
- Try to always use components for handling repeated elements that are the same. Try to never repeat a large group of elements – use a component instead.
- Use auto-layout by default for handling any sort of layout needs. Most container elements should use auto-layout.
- Try to never use raw colors – use shared color styles instead
- Try to use shared text styles as much as possible
- When components share lots of attributes, create sub-components to consolidate their shared bits, or make them variants
- Don’t make elements that act as the background of a frame/group. Instead, use the Background property of the frame/group and layer all the backgrounds you want.
Figma create a feeling of total freedom that you can keep creating more and more elements without restriction. However, if your file gets really big, you will run into performance and memory issues, and Figma may start crashing on you.
To avoid this...
- Try to have very few elements that contain lots of small elements. For example, if you have a pattern of dots, you can construct that by making thousands of dot elements, or you could use a repeating background image. The background image will be much faster.
- Try to avoid components that are extremely deeply nested, or have complex nesting chains that extend across too many files.
- When you know you are not going to come back to a part of a file (scratch work) feel free to delete that stuff or move it to a new file.