From a local to global way of working: building a new Figma structure (Part 2)

Published in

Yara Digital Ecosystem

7 min readFeb 14, 2022

Inma Ortiz Montiel is Yara Digital Ag Solutions’ (DAS) first Design Ops Lead. In her role, she makes sure designers have the time to design, while she handles everything else.

This is a continuation of From a local to global way of working: building a new Figma structure (Part 1).

As mentioned in the last article, as DAS’ new Design Ops Lead, I was proposing a new way of working on Figma for the UX team. Around the same time, we upgraded to Figma Organisation, which made things much easier for us.

Defining the general hierarchy on Figma

We set Yara as the “Organisation”, and proposed that “Team” corresponded with our Product teams, and “Projects” with various working areas within each Product.

SOIL 2.0 is one of DAS’ product teams (framed in pink). The purple frame indicates the three working areas (“Projects” in Figma)

Setting up working areas (or “Projects”)

Here is the framework for how designers and other users utilise Projects in our workspace:

Work in progress (“WIP”)

A WIP project is created when design work is ongoing, and a lot of analysis and explorative work is being done. We will share this with stakeholder such as Product Owners to review ideas, and with Engineers for temperature checks. Handoffs will also take place within this file.

Current state of our product (“LIVE”)

LIVE files are the single source-of-truth, and only show what has been built in the product. We divide each section of the product into individual LIVE files, to keep them specific to a feature of the product and its multiple variants.

Archived explorations and decisions (“ARCHIVE”)

Once design work in the WIP file has been developed, we can archive it. This helps with documentation and responding to future queries such as, “Why did we make this decision back then?” Moving WIP files to ARCHIVE also help ensure our day-to-day work is not hampered by the clutter of old files.

Splitting our WIP files using Figma Pages

🖼 Cover: an image to help the team identify the file.
ℹ️ How to navigate this file: a quick guide for developers and stakeholders that explains where to find the things they need.
❓About: a sheet with information relevant to the work being done.
💻 Ready for Engineering: final design screens and specifications ready to be shared with developers.
👆 Demo for Engineering: a prototype to inform developers about certain interactions.
🔍 Research / Analytics: all the research done on the topic and metrics available, including insights, notes, competitor references, screenshots from Amplitude, etc. Basically everything needed to start designing.
🕹️ Design Playground: all the iterations we explored during the project, with notes about why decisions were made along the way, for future reference. This is an open canvas to explore ideas, try out different patterns, get feedback, and iterate. This is also the page where the most collaboration happens, and is often flooded with comments from the team.
✏️ UX Writing Playground: where our UX Writers can play around with different versions of copy.
💬 Design Crit: materials required for a successful design critique and a place to get feedback.
🔙 Prototype for Validation: we only use this page when we create prototypes for the given design work. Prototypes are only needed to communicate a complex design or to test the concept with users.
✅ FINAL UI: where the final designs/user flows live. Frames on this page are organised based on user flows.
♻️ Recycle Bin: a back-up so we don’t destroy all our hard work.

Our proposed page structure (framed in pink on the left)

Starting new design work

This is the proposed step-by-step guide to starting a new design file on Figma:

Step 1. Duplicate template

Designers start the process by accessing the the WIP area of their product teams and duplicate the pinned WIP File Template.

Step 2. Activate relevant libraries

The next step is to activate the relevant design system library for the Product team, as well as the DesignOps library, which contains elements needed to structure their work.

These are some of the components provided in the DesignOps library. Designers can use this to make annotations in their work. Other components are frames, backgrounds, feedback notes, headers, flowcharts, etc.

Step 3. Change Cover information

Level 1 (yellow): no need to edit, refers to product/product vertical
Level 2 (pink): feature or part of the product that this work belongs to
Level 3 (orange): identifies the work being done clearly
Status pills (green): status pill indicates the relevant step of the design process

Step 4. Change “About” page information

Name of the work done and a description of the project.
General information: fill in details like start date, Jira ticket number, sprint, etc.
Related documents: add links to reference different types of documents. Add a title, a description and a link. Users can add as many as needed.
Team: identify the team members by adding their name, surname and role. Users can choose a preset picture or upload the real picture from the colleague.

Step 5. Follow the design process

The Designers work their way through a system of Figma pages:

There are specific pages for research & analytics screenshots, a playground to explore different ideas, a space to work together with the UX Writer, etc.

The whole design process — from inception, to handover to Engineering — is included in the Figma pages.

When moving from one page to the next, Designers need to go through a checklist to make sure all required steps are met.

For example, before giving researchers a prototype for validation, we have to indicate tasks we want the user to perform.

Framed in pink some of the checklists that we have in place

Step 6. Ready for Engineering

When the page Ready for Engineering is complete, Designers will share the file with Engineers. However, the Designers’ work does not end here. The WIP file is still in progress until the work is live in production.

Step 7. Move the truth to LIVE

When the work is live and the final user can see it, the Designer merges the final screens into the LIVE working area. This way, the entire organisation can track what the product currently looks like.

LIVE must be the single source of truth.

Step 8. Archive the WIP file

Once Step 7 is done, the Designer can drag the WIP file into the ARCHIVE working area for future reference.

Making sure Designers follow through

Because we all worked on this together, our Designers are interested in making it happen.

But to make sure the new process is implemented correctly we also:

Presented the solution several times in different channels
Created an open slack channel for questions related to this structure
Arranged bi-weekly meetings with each product design lead
Set up monthly DesignOps office hours
Created a Miro board where everyone can provide feedback

Miro board where I collect feedback for the new structure

What’s next?

Our Designers have worked with this structure for close to a month, and we have seen positive effects, such as reduced onboarding time, clearer project progress, and better interoperability.

As we’re always looking to improve, I have also gotten feedback such as:

“My prototypes for validation are very big. If I have it inside of the WIP file, I will have loading issues”
“Where can I store the marketing assets that I create immediately after the design work?”

We will continue trialling this system for a couple of months before gathering another round of structured feedback for the next iteration🤞

Follow Inma Ortiz Montiel and Yara Digital Ag Solutions to get updates on DesignOps and how we build digital products for the agricultural ecosystem. You can also get in touch with Inma on LinkedIn to discuss all things Design.