We’ve optimised IDAGIO’s Figma files✨
Since the start of this year, IDAGIO’s super-powered product design team has doubled in size. We’re a varied bunch, with experiences ranging from huge multi-nationals to tiny agencies and everything in-between.
Prior to the arrival of our new colleagues, team processes had been quite flexible — discovery and handover phases could be completely different for two different designers, because communication across a smaller unit was way easier. But with the wider organisation growing, and with the news that we’ll be switching from platform-based to fully-integrated feature teams in the coming weeks, we figured the time was right to get down to some serious process optimisation. Step one? Figma. ✨
Why optimise Figma?
We made the switch from Sketch to Figma back in January and since then have been sharing, prototyping and GIF-ing with gay abandon. At the six month mark (and with some newly minted designers on board) we felt we had a few issues to fix:
Product managers, developers, and other stakeholders were feeling a little lost in new files and projects.
A big factor in making the change from Sketch was the ability Figma gave us to make our design documents living, breathing artefacts that both PMs and developers could handily reference. From on-boarding new hires to acclimatising internal stakeholders, we figured following the same file structure every time would help smooth out the wider product team process. This way no matter which designer was introducing someone, the introduction would be the same.
Information was labelled and organised differently every time, making it difficult for people to find what they were looking for.
Some designers split out ‘final’ pages to better serve PMs or developers. Developers would get frustrated with disparate naming conventions. Sometimes research was included in the Figma file, other times it would be split it into a separate document — and we hadn’t decided upon a consistent place to store these. We needed clarity.
Our files didn’t spark joy. 🧹
This one doesn’t sound like much, but between developers still mourning the loss of Zeplin, and PMs not being able to link directly to their favourite screens, we felt like we had some serious PR work to do.
The process
A couple days later, on a scorching hot Thursday in July, we found ourselves gathered in front of this:
That’s right: being the good product designers we are, we whiteboarded our design files. Why? We wanted to make sure we captured each individual designers’ creative process:
- Any structure should support how we each worked as individuals
- The final structure would represent how we all worked
- Maybe we could get some fresh eyes on each others’ processes?
The session followed a simple format: grab a stack of post-its and list out the key phases you would expect to be part of a Figma file (e.g. ready for development, researching, playgrounding).
Once we’d captured a rough set of requirements, we did another round of post-its asking what each of these phases needed to capture. This helped us fill in the detail required on each page, and understand a little more deeply where our individual processes aligned and diverged.
We finished by asking what things could make the file helpful/joyful for a developer, PM, or external stakeholders. These files were as much for other members of our team as they were for us, so we wanted to consider what would be valuable to them as well. Sometimes designers have little tricks — colour coding things, or adding notes — to give clarity to our thinking and those same tricks make everything 1,000,000% better for all concerned.
The results
We distilled these notes into a first version of our template file, containing only the phases we’d decided on during the workshops:
And based on the information gathered in the session, the pages broke down like this:
🎟️ Ticket info
Goal of page
Figma displays files as a grid of thumbnail images that show first page of the file. This means that sometimes — even if you know the correct file name, you might struggle to find the right file (praying to the Figma Gods for another layer of folder organisation to maybe help us out on this one 🤞).
Contents (what we’re putting on this page)
File snapshots
Along with a link to the ticket resource folder (containing spec docs, external materials, research etc.), and giving the page a more practical name (‘Ticket info’), we’re adding a clearer snapshot of the project that might help guide external users towards the contents of the file more easily.
Clarity around file readiness
Between a JIRA ticket and our awesome powers of communication, we’re hoping the state of a design never gets lost. But sometimes terrible things happen, and we figured this would be an easy way to indicate to developers, freelancers, and anyone new to the project (or even our future selves) that designs are either blocked or good to go.
✅ Master [all platforms]
Goal of page
To clearly communicate the source of truth of this specific feature or project at the time of implementation to everyone in the organisation.
Contents (what we’re putting on this page)
Screens and any relevant specifications for all platforms. Screens should only be included here if they are 100% ready for development (including copy).
Who uses it?
Developers, designers, PMs, and other stakeholders.
📜 Archive
Goal of page
We’ve been around since 2015 and so far haven’t been um…*perfect* at documenting the history of our feature development. By adding this page, we’re hoping to preserve some of the decisions that might otherwise not have remained in the institutional memory.
Contents (what we’re putting on this page)
The “Master” screens from any past iterations.
Who uses it?
IDAGIO product designers from the future. 👽
👬 Buddy review
Goal of page
We want to get better at sharing and checking our work outside of design crits. Roll on ‘buddy review’, which effectively acts as a staging environment for designs.
Contents (what we’re putting on this page)
The page will sometimes be empty, but rather than pointing teammates to undefined pages or playground areas, this page can act as a consistent stopover for wireframes and mockups on their way to the master page.
Who uses it?
Designers who need a little advice and those who give advice.
⚽ UI Playground
Goal of page
Possibly the lengthiest debate of the workshopping session was the inclusion of a UI Playground: our team is chock-full of amazing all-rounders, but if we had to pinpoint a weakness, it’s probably that we’re not deeply visual. We hoped that by giving this part of the ticket process its own page, it might help all of us develop our UI skills a little more.
Contents (what we’re putting on this page)
Explorative mess, whatever the designer(s) needs to realize their creative vision.
Who uses it?
The designer(s) working on the project.
👀 Prototypes
Goal of page
A staging area for prototypes. Designers can use Figma’s in-built prototyping tools, or other software — but references to it should be made here. Similar to the ‘buddy review’, it keeps the prototype screens separate from the explorative work, so they’re easier to find and update as needed.
Contents (what we’re putting on this page)
All screens included in prototypes.
Who uses it?
The designer(s) working on the project.
⚙️ Wireframes
Goal of page
Nothing particularly life-changing here, just a space for some good ole’ fashioned wireframes.
Contents (what we’re putting on this page)
Wireframes!
Who uses it?
The designer(s) working on the project.
🚶Users and contexts
Goal of page
To provide a high-level overview of relevant flows to act as a reminder and reference about how the feature fits into the IDAGIO experience. It should NOT include any key details and decisions made around the feature itself, nor about research (these should sit in a separate document in a GDrive folder and should be linked on the ‘Ticket info’ page). We did this with the aim of keeping the source of truth consistent.
Contents (what we’re putting on this page)
Graphical elements pertaining to user findings and information about the current flow, or any cross-platform flows which might be of help.
Who uses it?
The designer(s) working on the project.
👩💻Competitive research
Goal of page
To show research into how other people have solved the same or similar — in all or some aspects — problems.
Contents (what we’re putting on this page)
Screens and flows from competitors, be they direct, indirect, or not actually in the same industry. These should also be added to a platform-specific collection (outside of this feature) once completed, which would hopefully make it easier for other designers to re-use and reference these screens in other projects.
Who uses it?
Designers, possibly PMs.
Oh, and a couple of those ‘helpful/joyful’ things we decided on:
Listing pages backwards
We were getting feedback that developers wouldn’t see to the ‘Master’ page at the bottom of the list because on smaller screens it could be hidden by the layer divider. By presenting pages in reverse order, the most important page is always on top (even if you’re on a teeny-tiny screen). We’re waiting with fingers crossed for the Figma Gods to somehow automatically integrate a title page so that our master file can actually be on top 🧡
2. Emoji errywhere 🎉
This one might seem a little frivolous, but we’ve gotten feedback from developers that it’s hard to instantly guess what might be on each page. We’re not anticipating many people in our organisation to dive into pages like ‘Users and contexts’, but maybe a thoughtfully placed emoji can help break some of that initial cognitive dissonance?
…OK, look, fine: it’s also because Figma supports emoji now and we wanted to jump on board 💁🚂🎉
What next?
We’re still working on implementing the notes from question two of the whiteboarding session (the items we need to see on these pages). We’re also planning on improving developer handover, creating a unified cross-product checklist, and possibly looking to the API to help us out on some of the trickier corners of our workflow.
This is part one of our series on our internal product design processes here at IDAGIO. We’ll be optimising a few areas of our process in the coming months. Stay tuned for more deep dives into how we’re improving developer handover, integrating with the shiny new Figma API, and aligning our research process.
