My work
From scattered files to a shared shipping system
While working on a scaling enterprise SaaS platform made up of multiple interconnected modules, I created The Product Design Release Protocol, a lightweight governance layer that made ownership, status and traceability visible across the Figma workspace.
The protocol gave Product, Design and Engineering a shared way to understand the work and move it forward with more confidence.
1. Challenge
To keep the case confidential, I use an airline logistics platform as a simplified example, with modules such as Flight Planning, Crew Operations and Boarding Management.
As the platform grew, Figma became much more than a design tool. It became a shared workspace where Product, Design and Engineering came to understand what was being built, what decisions had been made and what needed to move forward.
The files were not necessarily messy. The problem was that delivery context was scattered across them, so people had to reconstruct it from file names, memory, conversations and Azure DevOps references.
On top of that, data-heavy interfaces made the files slower to load and harder to navigate.
That was when I reframed the issue. This was not just a documentation problem. It was a delivery visibility and governance problem.
2. Approach
I mapped the actual path from request to release to understand who touched the work, which tools they relied on and where context could get lost between handoffs.
In Azure DevOps, Product Owners turned business requests into Feature Criteria, larger requirements broken down into related User Stories. Designers translated those stories into screens and flows in Figma, while Engineering used both tools to understand what needed to be built.
The workflow worked, but the context was split across tools and handoffs.
That mapping revealed the minimum signals each artifact needed to be trusted.
I translated that diagnosis into seven trust signals covering where the work belonged, who owned it, how it connected to delivery and whether it was still current and ready to move forward.
I was not adding more documentation. I designed the protocol to bring existing context closer to the design artifact and make it consistent.
I started with Figma’s left sidebar to make scope, hierarchy and status visible at a glance.
Because Figma pages have a flat structure, meaning you cannot create nested pages, I used naming, spacing and status icons to make each Feature Criteria page read as the parent of its related User Stories, mirroring the hierarchy in Azure DevOps.
The file name showed the release context, while each page carried its Azure DevOps Story ID and current status.
I created a reusable header component to bring the minimum context into each User Story.
Then I created color coded sections that matched the status system in the left sidebar, so readiness was visible directly in the working area.
Each User Story lived in one Figma page, with its header and a working section that matched its current status.
3. Outcome
Within three months, the protocol was used across two products and more than 24 release workspaces.
The main impact was continuity. Teams no longer had to rebuild delivery context when work changed hands, making it easier to pick up, maintain and move work forward across files, releases and designer changes.
4. Learnings & next
Governance only works when it fits the way teams already deliver.
This protocol worked because it surfaced the context teams were already using, instead of asking them to document more.
The biggest learning was that good DesignOps protects continuity, even when ownership or designers change.
I’m now turning this approach into a reusable DesignOps diagnostic framework to help teams identify where context gets lost and define the governance they actually need.
1. Challenge
To keep the case confidential, I use an airline logistics platform as a simplified example, with modules such as Flight Planning, Crew Operations and Boarding Management.
As the platform grew, Figma became much more than a design tool. It became a shared workspace where Product, Design and Engineering came to understand what was being built, what decisions had been made and what needed to move forward.
The files were not necessarily messy. The problem was that delivery context was scattered across them, so people had to reconstruct it from file names, memory, conversations and Azure DevOps references.
On top of that, data-heavy interfaces made the files slower to load and harder to navigate.
That was when I reframed the issue. This was not just a documentation problem. It was a delivery visibility and governance problem.
2. Approach
I mapped the actual path from request to release to understand who touched the work, which tools they relied on and where context could get lost between handoffs.
In Azure DevOps, Product Owners turned business requests into Feature Criteria, larger requirements broken down into related User Stories. Designers translated those stories into screens and flows in Figma, while Engineering used both tools to understand what needed to be built.
The workflow worked, but the context was split across tools and handoffs.
That mapping revealed the minimum signals each artifact needed to be trusted.
I translated that diagnosis into seven trust signals covering where the work belonged, who owned it, how it connected to delivery and whether it was still current and ready to move forward.
I was not adding more documentation. I designed the protocol to bring existing context closer to the design artifact and make it consistent.
I started with Figma’s left sidebar to make scope, hierarchy and status visible at a glance.
Because Figma pages have a flat structure, meaning you cannot create nested pages, I used naming, spacing and status icons to make each Feature Criteria page read as the parent of its related User Stories, mirroring the hierarchy in Azure DevOps.
The file name showed the release context, while each page carried its Azure DevOps Story ID and current status.
I created a reusable header component to bring the minimum context into each User Story.
Then I created color coded sections that matched the status system in the left sidebar, so readiness was visible directly in the working area.
Each User Story lived in one Figma page, with its header and a working section that matched its current status.
3. Outcome
Within three months, the protocol was used across two products and more than 24 release workspaces.
The main impact was continuity. Teams no longer had to rebuild delivery context when work changed hands, making it easier to pick up, maintain and move work forward across files, releases and designer changes.
4. Learnings & next
Governance only works when it fits the way teams already deliver.
This protocol worked because it surfaced the context teams were already using, instead of asking them to document more.
The biggest learning was that good DesignOps protects continuity, even when ownership or designers change.
I’m now turning this approach into a reusable DesignOps diagnostic framework to help teams identify where context gets lost and define the governance they actually need.
1. Challenge
To keep the case confidential, I use an airline logistics platform as a simplified example, with modules such as Flight Planning, Crew Operations and Boarding Management.
As the platform grew, Figma became much more than a design tool. It became a shared workspace where Product, Design and Engineering came to understand what was being built, what decisions had been made and what needed to move forward.
The files were not necessarily messy. The problem was that delivery context was scattered across them, so people had to reconstruct it from file names, memory, conversations and Azure DevOps references.
On top of that, data-heavy interfaces made the files slower to load and harder to navigate.
That was when I reframed the issue. This was not just a documentation problem. It was a delivery visibility and governance problem.
2. Approach
I mapped the actual path from request to release to understand who touched the work, which tools they relied on and where context could get lost between handoffs.
In Azure DevOps, Product Owners turned business requests into Feature Criteria, larger requirements broken down into related User Stories. Designers translated those stories into screens and flows in Figma, while Engineering used both tools to understand what needed to be built.
The workflow worked, but the context was split across tools and handoffs.
That mapping revealed the minimum signals each artifact needed to be trusted.
I translated that diagnosis into seven trust signals covering where the work belonged, who owned it, how it connected to delivery and whether it was still current and ready to move forward.
I was not adding more documentation. I designed the protocol to bring existing context closer to the design artifact and make it consistent.
I started with Figma’s left sidebar to make scope, hierarchy and status visible at a glance.
Because Figma pages have a flat structure, meaning you cannot create nested pages, I used naming, spacing and status icons to make each Feature Criteria page read as the parent of its related User Stories, mirroring the hierarchy in Azure DevOps.
The file name showed the release context, while each page carried its Azure DevOps Story ID and current status.
I created a reusable header component to bring the minimum context into each User Story.
Then I created color coded sections that matched the status system in the left sidebar, so readiness was visible directly in the working area.
Each User Story lived in one Figma page, with its header and a working section that matched its current status.
3. Outcome
Within three months, the protocol was used across two products and more than 24 release workspaces.
The main impact was continuity. Teams no longer had to rebuild delivery context when work changed hands, making it easier to pick up, maintain and move work forward across files, releases and designer changes.
4. Learnings & next
Governance only works when it fits the way teams already deliver.
This protocol worked because it surfaced the context teams were already using, instead of asking them to document more.
The biggest learning was that good DesignOps protects continuity, even when ownership or designers change.
I’m now turning this approach into a reusable DesignOps diagnostic framework to help teams identify where context gets lost and define the governance they actually need.
Fig. 1. An anonymized airline example showing how the release protocol translated product architecture into a repeatable Figma workspace hierarchy.
Fig. 2. As files accumulated more screens, versions and states, they became slower to load and harder to navigate.
Fig. 3. Mapping the path from request to release exposed where delivery context was split across tools and handoffs.
Fig. 4. Seven trust signals defined the minimum context each design artifact needed to stay traceable and ready to move forward.
Fig. 5. Naming, spacing and status icons turned Figma’s left sidebar into a delivery map that mirrored the hierarchy in Azure DevOps.
Fig. 6. A reusable header and color coded sections brought the same delivery context into each User Story workspace.
Fig. 1. An anonymized airline example showing how the release protocol translated product architecture into a repeatable Figma workspace hierarchy.
Fig. 2. As files accumulated more screens, versions and states, they became slower to load and harder to navigate.
Fig. 3. Mapping the path from request to release exposed where delivery context was split across tools and handoffs.
Fig. 4. Seven trust signals defined the minimum context each design artifact needed to stay traceable and ready to move forward.
Fig. 5. Naming, spacing and status icons turned Figma’s left sidebar into a delivery map that mirrored the hierarchy in Azure DevOps.
Fig. 6. A reusable header and color coded sections brought the same delivery context into each User Story workspace.