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.

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.

I used AI to accelerate implementation, but working code was not enough. I still reviewed how new behaviour fitted into the wider product and technical model.

As change detection expanded, adding an item to an existing request also began creating a new comparison baseline. The functionality worked, but review showed the route did not yet use the same request-scoped protection as the rest of the workflow.

I revised the implementation so the plugin supplied the stored request secret and the server verified it before accepting the operation. This kept the security model consistent as the product became more complex.

Throughout the build, I used the same pattern: define the behaviour, use AI to accelerate implementation, then test and review the result against the product and system requirements before treating it as complete.

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 a functioning Figma plugin with the core request, review and approval workflow published, while the product continues to evolve around the harder trust problem exposed by the first release.

The direction is now broader than recording a decision. The product is becoming a way to maintain confidence in whether a recorded approval still applies to the design that exists today.

The most useful product insight came after V1 was already working. Recording approval solved the visible workflow problem, but it also revealed that sign-off is only trustworthy while it remains connected to the state of the work being approved.

Building the product also changed how I use AI in delivery. I treat it as an implementation accelerator, not as the source of product judgement. The behaviour, edge cases, trust model and final acceptance still need to be defined and reviewed against the product as a whole.