Process & Custom Plugin
Process & Custom Plugin
Process & Custom Plugin
Streamlining process for creating and managing product screenshots for customer support and marketing purposes, including automating part of the design workflow through building a custom Figma plugin for our team.
Streamlining process for creating and managing product screenshots for customer support and marketing purposes, including automating part of the design workflow through building a custom Figma plugin for our team.
Streamlining process for creating and managing product screenshots for customer support and marketing purposes, including automating part of the design workflow through building a custom Figma plugin for our team.
Project Type
ops • tooling • passion project
Tags
efficiency • scalability • quality
Roles
Varies
Association
Design Systems Manager
at
CallRail
in
2023
Background
We often include screenshots of our product to accompany support articles so that customers can see the relevant UI when it’s more helpful to answer their questions or help them learn a new feature. The UX team facilitates the creation of screenshots as a QA measure.
When the UX team creates product screenshots, we’re really creating curated hifi mockups specifically for the support articles or marketing locations their intended for. This is so we can ensure the ‘storytelling’ closely matches the use case and only includes dummy data safe to be seen publicly.
Background
We often include screenshots of our product to accompany support articles so that customers can see the relevant UI when it’s more helpful to answer their questions or help them learn a new feature. The UX team facilitates the creation of screenshots as a QA measure.
When the UX team creates product screenshots, we’re really creating curated hifi mockups specifically for the support articles or marketing locations their intended for. This is so we can ensure the ‘storytelling’ closely matches the use case and only includes dummy data safe to be seen publicly.
Background
We often include screenshots of our product to accompany support articles so that customers can see the relevant UI when it’s more helpful to answer their questions or help them learn a new feature. The UX team facilitates the creation of screenshots as a QA measure.
When the UX team creates product screenshots, we’re really creating curated hifi mockups specifically for the support articles or marketing locations their intended for. This is so we can ensure the ‘storytelling’ closely matches the use case and only includes dummy data safe to be seen publicly.
Phase 1
Initial problem
Prior to our current process, product managers would take actual screenshots of the product after changing content in a live page via their browser’s dev tool. This was of course tedious, slow, and created a lot of room for error. Additionally, making other adjustments such as adjusting chart/graph lines or other visual changes is either impractical or impossible using this method.
Additionally, as the head of our UI team, I needed to run QA checks on visuals that our product team was making public. But because screenshots are flat images, they can’t be easily edited. So all things considered, we need a whole different way of producing these “screenshots”.
And the last pain point to mention was that screenshot images were not so easy to updated later on as the product UI changed. Screenshot images were uploaded in various places with a fairly manual process for finding and replacing them with new files, not to mention that there might be multiple copies of the same image across different pages or even different sites altogether. We needed a way to keep track of them all and know which images to update and where they were each located.
Initial solution
I worked with our design ops manager to come up with a new process for facilitating product screenshot creation. Here’s an outline of what we came up with:
Requests for new screenshots route through Asana (our project management tool for the UX team), then assigned to a UX individual based on who would be most familiar with the part of the product included in the screenshot per the request.
This ensured that the most appropriate people were available to create the screenshots.
Organize screenshots in our new Screenshots Library file in Figma.
By collecting our screenshots in a centralized location that is public to the org and well-organized, making it clear which screenshots were in progress vs approved and ready to be used, it helped others teams check existing resources for before requesting new screenshots. It also helped the UX team stay organized and follow our new process more easily.
QA review by content and UI teams.
This ensured that each screenshot met craft and quality requirements for both UX content and UI design.
Upload screenshots to a digital asset manager (DAM) that allowed for CDN source links to be used anywhere we needed to show the images.
This was a game-changer for making sure we could easily find and update all instances of a given screenshot in 1 update, saving a ton of time and helping us update screenshots over time as they become outdated.
Hand off the URL to the image (CDN link) for the requester to use as the image source URL.
Using a single source for all instances of a screenshot, updatable from from one location made it drastically easier to keep our screenshots up-to-date.
Log screenshot metadata to Screenshot Library design file: screenshot name, description, tags, associated patterns, link to DAM page, and link to CDN image source.
Finally, this last step helped parity between the library in Figma and the digital asset manager’s online library. Because Figma is where our designers work and often where people might look first, it made sense to have all the associated info right next to each screenshot in the library. Additionally, linking to where the image is stored in the DAM made it easier to find if an update was needed. Linking to the CDN image also made it faster to share the latest screenshot image to be used elsewhere or to simply check the live asset to ensure it’s still correct.
Phase 1
Initial problem
Prior to our current process, product managers would take actual screenshots of the product after changing content in a live page via their browser’s dev tool. This was of course tedious, slow, and created a lot of room for error. Additionally, making other adjustments such as adjusting chart/graph lines or other visual changes is either impractical or impossible using this method.
Additionally, as the head of our UI team, I needed to run QA checks on visuals that our product team was making public. But because screenshots are flat images, they can’t be easily edited. So all things considered, we need a whole different way of producing these “screenshots”.
And the last pain point to mention was that screenshot images were not so easy to updated later on as the product UI changed. Screenshot images were uploaded in various places with a fairly manual process for finding and replacing them with new files, not to mention that there might be multiple copies of the same image across different pages or even different sites altogether. We needed a way to keep track of them all and know which images to update and where they were each located.
Initial solution
I worked with our design ops manager to come up with a new process for facilitating product screenshot creation. Here’s an outline of what we came up with:
Requests for new screenshots route through Asana (our project management tool for the UX team), then assigned to a UX individual based on who would be most familiar with the part of the product included in the screenshot per the request.
This ensured that the most appropriate people were available to create the screenshots.
Organize screenshots in our new Screenshots Library file in Figma.
By collecting our screenshots in a centralized location that is public to the org and well-organized, making it clear which screenshots were in progress vs approved and ready to be used, it helped others teams check existing resources for before requesting new screenshots. It also helped the UX team stay organized and follow our new process more easily.
QA review by content and UI teams.
This ensured that each screenshot met craft and quality requirements for both UX content and UI design.
Upload screenshots to a digital asset manager (DAM) that allowed for CDN source links to be used anywhere we needed to show the images.
This was a game-changer for making sure we could easily find and update all instances of a given screenshot in 1 update, saving a ton of time and helping us update screenshots over time as they become outdated.
Hand off the URL to the image (CDN link) for the requester to use as the image source URL.
Using a single source for all instances of a screenshot, updatable from from one location made it drastically easier to keep our screenshots up-to-date.
Log screenshot metadata to Screenshot Library design file: screenshot name, description, tags, associated patterns, link to DAM page, and link to CDN image source.
Finally, this last step helped parity between the library in Figma and the digital asset manager’s online library. Because Figma is where our designers work and often where people might look first, it made sense to have all the associated info right next to each screenshot in the library. Additionally, linking to where the image is stored in the DAM made it easier to find if an update was needed. Linking to the CDN image also made it faster to share the latest screenshot image to be used elsewhere or to simply check the live asset to ensure it’s still correct.
Phase 1
Initial problem
Prior to our current process, product managers would take actual screenshots of the product after changing content in a live page via their browser’s dev tool. This was of course tedious, slow, and created a lot of room for error. Additionally, making other adjustments such as adjusting chart/graph lines or other visual changes is either impractical or impossible using this method.
Additionally, as the head of our UI team, I needed to run QA checks on visuals that our product team was making public. But because screenshots are flat images, they can’t be easily edited. So all things considered, we need a whole different way of producing these “screenshots”.
And the last pain point to mention was that screenshot images were not so easy to updated later on as the product UI changed. Screenshot images were uploaded in various places with a fairly manual process for finding and replacing them with new files, not to mention that there might be multiple copies of the same image across different pages or even different sites altogether. We needed a way to keep track of them all and know which images to update and where they were each located.
Initial solution
I worked with our design ops manager to come up with a new process for facilitating product screenshot creation. Here’s an outline of what we came up with:
Requests for new screenshots route through Asana (our project management tool for the UX team), then assigned to a UX individual based on who would be most familiar with the part of the product included in the screenshot per the request.
This ensured that the most appropriate people were available to create the screenshots.
Organize screenshots in our new Screenshots Library file in Figma.
By collecting our screenshots in a centralized location that is public to the org and well-organized, making it clear which screenshots were in progress vs approved and ready to be used, it helped others teams check existing resources for before requesting new screenshots. It also helped the UX team stay organized and follow our new process more easily.
QA review by content and UI teams.
This ensured that each screenshot met craft and quality requirements for both UX content and UI design.
Upload screenshots to a digital asset manager (DAM) that allowed for CDN source links to be used anywhere we needed to show the images.
This was a game-changer for making sure we could easily find and update all instances of a given screenshot in 1 update, saving a ton of time and helping us update screenshots over time as they become outdated.
Hand off the URL to the image (CDN link) for the requester to use as the image source URL.
Using a single source for all instances of a screenshot, updatable from from one location made it drastically easier to keep our screenshots up-to-date.
Log screenshot metadata to Screenshot Library design file: screenshot name, description, tags, associated patterns, link to DAM page, and link to CDN image source.
Finally, this last step helped parity between the library in Figma and the digital asset manager’s online library. Because Figma is where our designers work and often where people might look first, it made sense to have all the associated info right next to each screenshot in the library. Additionally, linking to where the image is stored in the DAM made it easier to find if an update was needed. Linking to the CDN image also made it faster to share the latest screenshot image to be used elsewhere or to simply check the live asset to ensure it’s still correct.
Halftime break
Let's pause
If you’ve read this far, you might be thinking “Wow, I didn’t realize creating and managing screenshots could be so tedious.” And I’d agree with you. Managing a library of over 100 (and growing) public-facing images of a product’s UI that need to look realistic, tell a story, be as accurate and up-to-date as possible, and have appropriate dummy data…is a lot of work. But it’s important to help our users while upholding brand and quality standards for the business.
So with that said, let’s move onto the next segment of this process and tooling journey.
More complexity
As we tested the new process and workflows for creating screenshots, we discovered some new pain points:
While it was easier for other teams to request screenshots now that the work was offloaded onto the UX team, the new processes and involvement of a new tool (digital asset manager) added complexity that our UX designers were not adjusted to. The process of creating public-facing screenshots intended for specific uses cases was tedious enough. But there is added complexity related to organizing and tracking the associated details that we rely on to help understand why we have a given screenshot or what shouldn’t change in the future. Let me give you some examples as to why the organization and accompanying meta data are important:
Scenario: Let’s say you’re on the Marketing team and need a screenshot to showcase on the website. You already use the digital asset manager for visual brand assets like illustrations, but you find it difficult to browse and learned that the UX team manages a visual library in Figma that’s easier to use. So you make your way over to the file and land on the main page. If you’re unsure which screenshots are “approved” and “ready to be used”, you may unintentionally grab a screenshot that’s still a work-in-progress and not ready to be used publicly. You go end up using it, only to find out later from the UX team that the one you picked has some critical issues that needs to be addressed ASAP, creating a mild panic and temporarily disrupting other work for you, your team, and the UX team.
Scenario: You’re a UX designer tasked with creating a new screenshot that looks similar to an existing screenshot we already have. To save time, you make changes to the existing screenshot rather than creating a new one with slightly different requirements. The existing screenshot gets replaced with your new copy and all locations that screenshot is used across the Support and Marketing sites are instantly updated.
Later in the week, you get notified that there’s a problem with the screenshot you updated: it’s the wrong scenario for the one that you replaced. The user scenario associated with the screenshot request you were assigned to was similar to but had a key difference that needed to be considered when creating it. This oversight means you now have to revert changes to the one you replaced and still need to create a new one, separately.
Thankfully, these scenarios haven’t happened. But we have measures in place to prevent them. For example, keeping the library file well-organized and clearly labeled reduces risk that someone uses a screenshot that’s no ready. And including meta data such as the screenshot’s description helps designers understand exactly what use case the existing screenshot was created to serve, reducing chances of it getting updated in a way that no longer serves that purpose.
Halftime break
Let's pause
If you’ve read this far, you might be thinking “Wow, I didn’t realize creating and managing screenshots could be so tedious.” And I’d agree with you. Managing a library of over 100 (and growing) public-facing images of a product’s UI that need to look realistic, tell a story, be as accurate and up-to-date as possible, and have appropriate dummy data…is a lot of work. But it’s important to help our users while upholding brand and quality standards for the business.
So with that said, let’s move onto the next segment of this process and tooling journey.
More complexity
As we tested the new process and workflows for creating screenshots, we discovered some new pain points:
While it was easier for other teams to request screenshots now that the work was offloaded onto the UX team, the new processes and involvement of a new tool (digital asset manager) added complexity that our UX designers were not adjusted to. The process of creating public-facing screenshots intended for specific uses cases was tedious enough. But there is added complexity related to organizing and tracking the associated details that we rely on to help understand why we have a given screenshot or what shouldn’t change in the future. Let me give you some examples as to why the organization and accompanying meta data are important:
Scenario: Let’s say you’re on the Marketing team and need a screenshot to showcase on the website. You already use the digital asset manager for visual brand assets like illustrations, but you find it difficult to browse and learned that the UX team manages a visual library in Figma that’s easier to use. So you make your way over to the file and land on the main page. If you’re unsure which screenshots are “approved” and “ready to be used”, you may unintentionally grab a screenshot that’s still a work-in-progress and not ready to be used publicly. You go end up using it, only to find out later from the UX team that the one you picked has some critical issues that needs to be addressed ASAP, creating a mild panic and temporarily disrupting other work for you, your team, and the UX team.
Scenario: You’re a UX designer tasked with creating a new screenshot that looks similar to an existing screenshot we already have. To save time, you make changes to the existing screenshot rather than creating a new one with slightly different requirements. The existing screenshot gets replaced with your new copy and all locations that screenshot is used across the Support and Marketing sites are instantly updated.
Later in the week, you get notified that there’s a problem with the screenshot you updated: it’s the wrong scenario for the one that you replaced. The user scenario associated with the screenshot request you were assigned to was similar to but had a key difference that needed to be considered when creating it. This oversight means you now have to revert changes to the one you replaced and still need to create a new one, separately.
Thankfully, these scenarios haven’t happened. But we have measures in place to prevent them. For example, keeping the library file well-organized and clearly labeled reduces risk that someone uses a screenshot that’s no ready. And including meta data such as the screenshot’s description helps designers understand exactly what use case the existing screenshot was created to serve, reducing chances of it getting updated in a way that no longer serves that purpose.
Halftime break
Let's pause
If you’ve read this far, you might be thinking “Wow, I didn’t realize creating and managing screenshots could be so tedious.” And I’d agree with you. Managing a library of over 100 (and growing) public-facing images of a product’s UI that need to look realistic, tell a story, be as accurate and up-to-date as possible, and have appropriate dummy data…is a lot of work. But it’s important to help our users while upholding brand and quality standards for the business.
So with that said, let’s move onto the next segment of this process and tooling journey.
More complexity
As we tested the new process and workflows for creating screenshots, we discovered some new pain points:
While it was easier for other teams to request screenshots now that the work was offloaded onto the UX team, the new processes and involvement of a new tool (digital asset manager) added complexity that our UX designers were not adjusted to. The process of creating public-facing screenshots intended for specific uses cases was tedious enough. But there is added complexity related to organizing and tracking the associated details that we rely on to help understand why we have a given screenshot or what shouldn’t change in the future. Let me give you some examples as to why the organization and accompanying meta data are important:
Scenario: Let’s say you’re on the Marketing team and need a screenshot to showcase on the website. You already use the digital asset manager for visual brand assets like illustrations, but you find it difficult to browse and learned that the UX team manages a visual library in Figma that’s easier to use. So you make your way over to the file and land on the main page. If you’re unsure which screenshots are “approved” and “ready to be used”, you may unintentionally grab a screenshot that’s still a work-in-progress and not ready to be used publicly. You go end up using it, only to find out later from the UX team that the one you picked has some critical issues that needs to be addressed ASAP, creating a mild panic and temporarily disrupting other work for you, your team, and the UX team.
Scenario: You’re a UX designer tasked with creating a new screenshot that looks similar to an existing screenshot we already have. To save time, you make changes to the existing screenshot rather than creating a new one with slightly different requirements. The existing screenshot gets replaced with your new copy and all locations that screenshot is used across the Support and Marketing sites are instantly updated.
Later in the week, you get notified that there’s a problem with the screenshot you updated: it’s the wrong scenario for the one that you replaced. The user scenario associated with the screenshot request you were assigned to was similar to but had a key difference that needed to be considered when creating it. This oversight means you now have to revert changes to the one you replaced and still need to create a new one, separately.
Thankfully, these scenarios haven’t happened. But we have measures in place to prevent them. For example, keeping the library file well-organized and clearly labeled reduces risk that someone uses a screenshot that’s no ready. And including meta data such as the screenshot’s description helps designers understand exactly what use case the existing screenshot was created to serve, reducing chances of it getting updated in a way that no longer serves that purpose.
Phase 2
The new problem
As I mentioned, this process was becoming very tedious and difficult for designers to follow perfectly every time. The hardest part for the UX team was creating and logging the metadata for each screenshot while ensuring it’s consistent across Figma and the DAM.
I attempted to help by creating a detailed how-to guide within the Figma file so that our team could follow along step-by-step. But that only proved that the process was too complicated to be reliable in the first place. We needed to simplify, drastically. This is where things get interesting…in a good way.
The new solution
Automate the workflow
In a final attempt to streamline the process and create a much easier workflow for the tail end of this process, I explored ideas around automating any steps possible. This lead me to exploring the possibility of building a Figma plugin. Since our engineering resources were very tight, I knew it would come down to me. I do have experience in web development, but have never built a plugin for anything, much less coded something with an API. So this would be a set of firsts. However, remembering back when Figma launched Plugins, they wanted people to know it didn’t really require development experience. So I thought I might have a chance.
After watching Figma’s introductory video series on how to build a plugin, I was surprised at how quickly I was able to get setup with a new development environment and even build an sample plugin that actually worked! And not only that, but that plugin happened to perform most of the same tasks I thought I’d need for the one I wanted to build.
After hours of work, trial and error, and getting help from ChatGPT, I successfully completed my first Figma plugin! Complete with a custom branded web form, our UX team could began using the plugin to automate the following steps:
Applying standardized screenshot styling (border, rounded corners, and a drop shadow)
Converting their screenshot into a component
Naming the component what they entered into the form
Placing an instance of their screenshot component on the main library page of the file
Adding the metadata they entered into the form (title, description, tags, included major patterns, device, etc.) as a component instance directly below their screenshot
Wrapping the screenshot and metadata in an Auto Layout group
Renaming the group to match the screenshot’s title
Bringing the screenshot into view for the user automatically
Applying predefined export setting
The final steps left for the designer to perform manually were to:
Export the image using the applied settings
Upload the image to the DAM
Grab the CDN link
Hand off the link to the requester in the Asana ticket
Plugin demonstration
In the weeks that followed the plugin creation, I demonstrated how to use the plugin with the UX team during a couple of our all-hands meetings. Additionally, I recorded a video demo that the team can reference later in our Loom account.
Putting it into action
I am extremely pleased the say the plugin has been a success. The team has been utilizing and find that it works as intended. There were of course some bugs in the early releases that I needed to fix. But since then, it’s been smooth sailing.
Phase 2
The new problem
As I mentioned, this process was becoming very tedious and difficult for designers to follow perfectly every time. The hardest part for the UX team was creating and logging the metadata for each screenshot while ensuring it’s consistent across Figma and the DAM.
I attempted to help by creating a detailed how-to guide within the Figma file so that our team could follow along step-by-step. But that only proved that the process was too complicated to be reliable in the first place. We needed to simplify, drastically. This is where things get interesting…in a good way.
The new solution
Automate the workflow
In a final attempt to streamline the process and create a much easier workflow for the tail end of this process, I explored ideas around automating any steps possible. This lead me to exploring the possibility of building a Figma plugin. Since our engineering resources were very tight, I knew it would come down to me. I do have experience in web development, but have never built a plugin for anything, much less coded something with an API. So this would be a set of firsts. However, remembering back when Figma launched Plugins, they wanted people to know it didn’t really require development experience. So I thought I might have a chance.
After watching Figma’s introductory video series on how to build a plugin, I was surprised at how quickly I was able to get setup with a new development environment and even build an sample plugin that actually worked! And not only that, but that plugin happened to perform most of the same tasks I thought I’d need for the one I wanted to build.
After hours of work, trial and error, and getting help from ChatGPT, I successfully completed my first Figma plugin! Complete with a custom branded web form, our UX team could began using the plugin to automate the following steps:
Applying standardized screenshot styling (border, rounded corners, and a drop shadow)
Converting their screenshot into a component
Naming the component what they entered into the form
Placing an instance of their screenshot component on the main library page of the file
Adding the metadata they entered into the form (title, description, tags, included major patterns, device, etc.) as a component instance directly below their screenshot
Wrapping the screenshot and metadata in an Auto Layout group
Renaming the group to match the screenshot’s title
Bringing the screenshot into view for the user automatically
Applying predefined export setting
The final steps left for the designer to perform manually were to:
Export the image using the applied settings
Upload the image to the DAM
Grab the CDN link
Hand off the link to the requester in the Asana ticket
Plugin demonstration
In the weeks that followed the plugin creation, I demonstrated how to use the plugin with the UX team during a couple of our all-hands meetings. Additionally, I recorded a video demo that the team can reference later in our Loom account.
Putting it into action
I am extremely pleased the say the plugin has been a success. The team has been utilizing and find that it works as intended. There were of course some bugs in the early releases that I needed to fix. But since then, it’s been smooth sailing.
Phase 2
The new problem
As I mentioned, this process was becoming very tedious and difficult for designers to follow perfectly every time. The hardest part for the UX team was creating and logging the metadata for each screenshot while ensuring it’s consistent across Figma and the DAM.
I attempted to help by creating a detailed how-to guide within the Figma file so that our team could follow along step-by-step. But that only proved that the process was too complicated to be reliable in the first place. We needed to simplify, drastically. This is where things get interesting…in a good way.
The new solution
Automate the workflow
In a final attempt to streamline the process and create a much easier workflow for the tail end of this process, I explored ideas around automating any steps possible. This lead me to exploring the possibility of building a Figma plugin. Since our engineering resources were very tight, I knew it would come down to me. I do have experience in web development, but have never built a plugin for anything, much less coded something with an API. So this would be a set of firsts. However, remembering back when Figma launched Plugins, they wanted people to know it didn’t really require development experience. So I thought I might have a chance.
After watching Figma’s introductory video series on how to build a plugin, I was surprised at how quickly I was able to get setup with a new development environment and even build an sample plugin that actually worked! And not only that, but that plugin happened to perform most of the same tasks I thought I’d need for the one I wanted to build.
After hours of work, trial and error, and getting help from ChatGPT, I successfully completed my first Figma plugin! Complete with a custom branded web form, our UX team could began using the plugin to automate the following steps:
Applying standardized screenshot styling (border, rounded corners, and a drop shadow)
Converting their screenshot into a component
Naming the component what they entered into the form
Placing an instance of their screenshot component on the main library page of the file
Adding the metadata they entered into the form (title, description, tags, included major patterns, device, etc.) as a component instance directly below their screenshot
Wrapping the screenshot and metadata in an Auto Layout group
Renaming the group to match the screenshot’s title
Bringing the screenshot into view for the user automatically
Applying predefined export setting
The final steps left for the designer to perform manually were to:
Export the image using the applied settings
Upload the image to the DAM
Grab the CDN link
Hand off the link to the requester in the Asana ticket
Plugin demonstration
In the weeks that followed the plugin creation, I demonstrated how to use the plugin with the UX team during a couple of our all-hands meetings. Additionally, I recorded a video demo that the team can reference later in our Loom account.
Putting it into action
I am extremely pleased the say the plugin has been a success. The team has been utilizing and find that it works as intended. There were of course some bugs in the early releases that I needed to fix. But since then, it’s been smooth sailing.
Looking back
While there are still improvements to make, we’ve made a ton of progress creating repeatable action by implementing a thoughtful process that prioritizes quality and consistency while supporting the additional workload with better tooling and organization for a sustainable approach.
Looking back
While there are still improvements to make, we’ve made a ton of progress creating repeatable action by implementing a thoughtful process that prioritizes quality and consistency while supporting the additional workload with better tooling and organization for a sustainable approach.
Looking back
While there are still improvements to make, we’ve made a ton of progress creating repeatable action by implementing a thoughtful process that prioritizes quality and consistency while supporting the additional workload with better tooling and organization for a sustainable approach.
Future improvements
While the plugin helped remove some of the added complexity and workload created by the original solution, there’s still more complexity by having screenshot files and their metadata logged in 2 places that don’t sync with each other without us manually making updates. We could simplify things further by connecting our Figma plugin with the the API used by our digital asset manager tool, allowing both tools to communicate directly with each other to sync screenshot images and metadata on command. And who knows, maybe we’ll also find other ways to automate other tasks such as:
generating dummy data
syncing tasks from Asana
handing off final images
searching the library
organizing the library
connect with our Templates library (helps the UX team more quickly start new hifi mockups based on existing page templates)
Future improvements
While the plugin helped remove some of the added complexity and workload created by the original solution, there’s still more complexity by having screenshot files and their metadata logged in 2 places that don’t sync with each other without us manually making updates. We could simplify things further by connecting our Figma plugin with the the API used by our digital asset manager tool, allowing both tools to communicate directly with each other to sync screenshot images and metadata on command. And who knows, maybe we’ll also find other ways to automate other tasks such as:
generating dummy data
syncing tasks from Asana
handing off final images
searching the library
organizing the library
connect with our Templates library (helps the UX team more quickly start new hifi mockups based on existing page templates)
Future improvements
While the plugin helped remove some of the added complexity and workload created by the original solution, there’s still more complexity by having screenshot files and their metadata logged in 2 places that don’t sync with each other without us manually making updates. We could simplify things further by connecting our Figma plugin with the the API used by our digital asset manager tool, allowing both tools to communicate directly with each other to sync screenshot images and metadata on command. And who knows, maybe we’ll also find other ways to automate other tasks such as:
generating dummy data
syncing tasks from Asana
handing off final images
searching the library
organizing the library
connect with our Templates library (helps the UX team more quickly start new hifi mockups based on existing page templates)