From a local to global way of working: building a new Figma structure (Part 1)
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.
Where we started: moving from local to global
One of my first tasks as DAS’ Design Ops Lead was to rethink how our UX team works in Figma, recommend and build a new way of working for members across our 7 Hubs.
DAS has designers in Singapore, India, China, Argentina, Brazil, Kenya and Germany; over the past 4 years, each Hub Design team has developed their own styles and structures.
When DAS moved towards a Global UX Discipline at the end of 2021, we had to create a global way of working, and ensure future interoperability within projects.
First steps: coming up with a design process
The users to keep in mind were: Designers, Product Owners and Developers.
These were the first steps I took with these users:
- Reached out to all Design Leads across our Hubs to gather information about their “as-is” process.
- Conducted desk research on how big companies currently work (see References).
- Ran a workshop with key stakeholders to uncover what wasn’t working in the “as-is” situation, as well as their current needs. We clustered the needs and prioritised them based on importance and effort required.
- Analysed the workshop insights and drafted a proposal to present to the UX team for feedback.
- Iterated the proposal before documenting and presenting the decision to the team.
What we discovered
🙅 What doesn’t work:
- Too many files and files that are too big
- No one knows what the latest design is
- Lacking Master/Macro files
- Lacking context or introduction to the project
- No proper naming system for files and projects
- Lack of standardised documentation
- File covers and relevant information are not clear enough
👼 What works:
- Separating Design and Marketing files
- Communicating project status in the file covers
❓What we disagreed on:
- Keeping research inside the Figma file vs. outside the Figma file
- Putting a handover file for development in the same file vs. a separate file
- Storing material for critiques inside the Figma file vs. storing on Miro or FigJam
- Having the prototype for validation inside the Figma file vs. outside the Figma file
📎 Requirements:
When I asked what people needed from the new system, team members requested to take these points into account (ranked according to popularity):
- Templates: having a base template to start with to maintain standardisation
- Communicating progress: file covers to indicate where we are in the process
- Standardised format: a standard way to document design decisions, communicate user flows, specifications, etc.
- Unique source of truth: a master file to document designs that have already been developed
- Standardised naming: guidelines and conventions on clear screen and file naming
- Related work: links to all the relevant information to the project, such as research reports, kick-off Miro boards, JIRA tickets, amplitude reports, previous work on the topic, etc.
- Recycle Bin: to chuck the old explorations or discarded UIs
- Accountability: documentation on the responsible Developer, Product Owner and Designer, who made the last changes, etc.
- Sections required: pages for research and analytics, prototypes, handover files, design critiques, work on iterations, etc.
- Figma Enterprise: to have a space for each Product and the ability to give access rights to specific products
Now that we had our findings, it was time to build a new system. Continue on to Part 2 to see how we solved it.
Yara Digital Ag Solutions is always hiring! Check out our open UX and Design roles here.
Follow Inma Ortiz Montiel and Yara Digital Ag Solutions to get updates on DesignOps and how we build digital products for the agricultural ecosystem.
