At work, we have a design team that provides services to a variety of products, each with its product strategists and methods. As we put our heads down to get our start-up product in the market, we met our goal of launching and as a design team, we began to lift our heads and assess our current systems. I wanted to research and discover an improved way to work as a design team in sync with our development team focused on one product.
The Problem
Not only does our design team focus on multiple products, our development teams for our products often have responsibilities in other areas of the company. This emphasizes our need for effective systems and high streams of communication between design and dev. To do this, we have to look at the tools that our teams use and maximize each potential. The three tools we use most often include: Figma for design and prototypes, Jira for engineering tickets, Asana for project management across all affected departments (beyond design and dev).
The Current
There is nothing inherently wrong with our current systems and communications, but after our initial push to launch our product for marketing pages, blogs, and the web/native application, I found our current practice will inevitably reach issues if it went untouched.
In our current model, we have a Figma team for our product that made sense when we were in Alpha and Beta. We had a folder designated to Design Systems, the Brand, Marketing Assets, and the App itself. Although those are not specific to our product’s status, we have two folders that quickly become obsolete.
Our folder “Ready for Development” was used to house Figma files that were reviewed and approved and ready to go live. This was specifically for our Alpha prototypes for the website and blog. At the time we utilized files for a proof of concept (prototype) that included every page and interaction, and a separate file that highlighted each page. While it made sense to separate files for the dev team and our management team, this unintentionally created confusion when we update content.
In addition, we separated our desktop app and mobile app experiences into their files. This was due to the massive files (200+ screens) that we prototyped for a proof of concept as the app was soon to be developed. Having both devices on one file made the Figma experience slow and hard to navigate. Having two files to manage with multiple designers unintentionally left organization issues such as copy updates, layout changes, and folder locations.
Because we were in alpha, we didn’t directly experience an issue until we moved out of beta. Creating a new folder for beta files made sense at the time, but now our “Ready for Development” folder become outdated, but with our timeline, we didn’t have the time to update or manage that folder. Unintentionally, we now had a confusing folder structure, since everything that was “ready” was actually in the “beta” folder.
With the preparation of moving out of beta, we created “Post Launch Design” files, but with our limited emphasis on speed, we left that file in “Beta” without fully realizing the added confusion.
However, our Figma system only affected our design team. If we stayed up on our communication, we didn’t necessarily feel the impact of our folder structure.
In our current workflow, we develop new screens or updates with either new Figma files or new file layers within existing files. When we agree on the designs (after reviewing with the team and with developers), we move those screens to replace our app and web prototypes based on device type. Outdated screens are moved to an archive layer within our prototype file for safekeeping.
We experienced issues with this setup over time. Our dev team now had 5 files to review, each with extensive amounts of screens that they will need to sift through to find the ones they need at that moment. We did copy links to screens to add to their Jira ticket, but if those screens were pending review and somehow moved or deleted, then the link to Jira is broken.
We also received feedback from our dev team that having to swap between Figma files based on device type became a pain over time.
And since our system was not buttoned up, we as designers sometimes created one-off pages for our reasons, which ultimately became a source of confusion for other designers. Designers wouldn’t know which screens are approved, ready for approval, or if they are just “explorations” from others.
Being that there was no documentation on page layout decisions, designers were able to understand the reasoning for updated screens. It became difficult to know how to continue to iterate if some designers were not aware of past decisions or constraints.
Our current system slowly became confusing for design and dev.
The Process
After launching, we found an opportunity to reassess our Figma structure and how it can coexist with our current Jira and Asana workflows.
I read articles, watched YouTube videos, and mind-mapped several potential solutions to find a model that can work for our team structures: A design team that shares services across products and a development team that also shares focus on different areas of the business, but with a need to work together and effectively on minor and major product updates.
One of the main inspirations comes from this YouTube video from Figma that really breakdown a phenomenal Figma procedure for the company, Onfido
After all the inspiration, I organized our Figma folders to follow a Double-Digit label and organized our active files within folders such as, “Core Files,” “App Files,” “Website Files.” Moving outdated files to “Archive” so we don’t accidentally misuse old designs. Moving files that do not need dev attention to “Internal” or “Assets” so it does not get in anyone’s way.
The biggest addition to the system is the use of Work in Progress Templates for Figma files that are focused and specific to a Jira ticket journey
The benefit here is that our conversations around minor or major product updates can be constrained to one Figma file per Jira ticket. Now our Jira tickets have one associated link to Figma that will not break or get lost.
Note, we can utilize thumbnail covers for Figma to demonstrate Jira ticket numbers, the ticket name, and the status of the project at a glance.
Once a Jira ticket has finished its journey, we can then move our Figma file to an Archived folder since it's no longer active, and move the newly released screens to the appropriate source files. We now have one source per product (app and website) that includes different device types. This allows one file to be our source of truth, and the dev team needs to only reference one file for the app and only one file for the website.
The Solution
Our new workflow can make use of the Work in Progress Template as the main focus for a Figma file journey.
We create a new file per Jira ticket so that we have a direct connection to the Jira workflow while improving our connection to Asana by dedicating one link to Jira and one link to Figma per Asana card.
Any designer or developer can jump into a file and know the business objective, constraints, and affected screens. This allows designers to work as they can on one product without accidentally confusing it for another
Once the Figma WIP file is reviewed by the right people, the Jira ticket is complete, and the appropriate designs are live in the app or website, we can then finish the life cycle for that file. The Figma WIP file is moved to the appropriate “12 Archive Tickets” folder, and the screens that were updated or created are then copied to the source file for that product. This allows designers and developers to know exactly what is live or expected to be live at a given moment. The source file is only updated once the additions are completely final.
We can keep documentation of exploration, alternative designs, and records of constraints per file within the archived folder. If in the future a designer wants to review a certain flow or screen, we can review past designs and keep in mind any relevant constraints or dev factors.
