Making design sign-off more trustworthy

Approval is usually treated as a message rather than a product state. A design might be accepted in a meeting, acknowledged in chat, or buried in a comment thread, but the decision is separated from the frame that was actually reviewed.

That makes the record fragile. Teams can see that somebody approved something, but not always which version of the work the decision referred to or whether the design has moved on since.

V1 kept the workflow inside Figma. Select a frame, add the review context and send a sign-off request. The reviewer receives the request with a direct link to the work and records a decision on a focused review page.

I deliberately removed unnecessary plugin interactions as the flow evolved. For example, selecting a frame in Figma now updates the request automatically rather than asking the designer to confirm the same selection with a second button.

The first build created a reliable approval record at the moment a reviewer submitted a decision. It did not yet answer what happened afterwards.

If the approved frame changed later, the recorded approval could still look current. The history was accurate, but the relationship between the approval and the present design was no longer trustworthy. That became the more important product problem.

I reframed approval as a lifecycle rather than a permanent badge. The product needs to remember the approved state, recognise when the source design no longer matches it, preserve the original decision and make the changed status clear.

That led to a simple rule: approval should remain part of the history, but it should not continue presenting itself as current once the approved design has materially changed.

Approval remains visible as part of the record. If the underlying design changes later, Signoffly does not delete or overwrite the earlier decision. It changes the approval state so the history remains intact while making it clear that the current design needs another review.

Change detection compares the current design against the baseline associated with the approved request. When the comparison no longer matches, Signoffly changes the status rather than silently leaving the approval untouched.

The interaction is intentionally lightweight. The designer is told that the approved work has changed, the original sign-off remains visible as history, and the workflow provides a route back to review rather than pretending the earlier decision still covers the new state.

Approval history also needed to remain useful outside the plugin. I added reporting at request and dashboard level so teams could review decisions without reconstructing the history from individual requests.

A request report brings multiple items and their approval states into one view, with filtering for Approved, Pending and Changes requested. Dashboard reporting uses the current search and filters, so the report reflects the view the user is already working with rather than forcing a generic export.

Reports can also be downloaded as PDFs for sharing, record keeping and stakeholder review. This extended Signoffly from capturing approval into maintaining a usable record of what happened afterwards.

I used AI to accelerate implementation as Signoffly grew, but working code was not enough. I still reviewed each change against the wider product, data and security model before treating it as complete.

For example, adding an item to an existing request created a new comparison baseline, but the first implementation did not use the same request-scoped protection as the rest of the workflow. I revised the route so the plugin supplied the stored request secret and the server verified it before accepting the operation.

I used the same pattern throughout the build: define the behaviour, use AI to accelerate implementation, then test and review the result against the product and system requirements.

The change-detection model forced several implementation decisions to become product decisions. Protected write routes needed a consistent request-scoped identity model. New items needed their own comparison baseline. Historical approvals created before baselines existed could not be treated as though they had the same evidence available.

Those choices affect what the interface is allowed to claim. Rather than inventing certainty, the product only presents drift tracking where the underlying approval has enough information to support it.

Signoffly is now a published Figma plugin supported by a web review and reporting experience, with request, approval, change detection and re-submission workflows connected across both surfaces.

The product has moved beyond recording a decision. It now keeps approval attached to the state of the design, makes later changes visible and creates a shareable record when teams need the approval history outside Figma.

Publishing Signoffly on Figma Community moved it beyond a portfolio-only prototype into a live product.

The most useful product insight came after V1 was already working. Recording approval solved the visible workflow problem, but it also exposed the more important question of whether that approval still applies after the design changes.

Building the product also reinforced how I use AI in delivery. I use it to speed up implementation, while product behaviour, edge cases, trust decisions and final acceptance still need deliberate review against the system as a whole.