Navigating design changes after the “Done” mark

Design and development are iterative processes. The harsh truth is that most critical design changes are made to already “Done” designs.

While Figma designs can be modified, it’s important to make changes carefully to prevent delays, misunderstandings, and added expenses.

Some hard lessons have been taught to me:

1. Provide a clear explanation of the changes: Don’t make any changes to sections that have already been approved. Make a separate section or add new frames to outline the proposed changes. Document the changes thoroughly. Ensure stakeholders understand what has changed between the old and updated designs.
2. Reason for the changes: Understand the change’s purpose. Are they to address critical user feedback, adjust to a change in business direction, or simply improve aesthetics? Knowing the “why” helps in prioritizing and understanding urgency.
3. Sync: To ensure everyone knows the changes, inform stakeholders and answer their questions. All parties should be on the same page.
4. Impact on Timeline: Assess the extent of the changes. Will they significantly alter the development timeline? It’s crucial to understand the potential delays these changes might introduce.

Figma frame statuses

Design consists of multiple, even hundreds of frames. For people to be able to see where changes have been made, I use a simple color system. The use of coloured emojis at the top of the frame makes it easier for people to identify areas where changes have been made.

• 🔵 Updated: Used when changes are made to an existing frame. As an example, copy has been changed, a component’s properties have changed, a button added etc. Used in conjunction with changelog, to describe applied changes.
• 🔴 Removed: Used when the frame is removed from the design. The opacity of the frame could also be decreased to 50% to emphasize the fact that this design is no longer present. These screens can be archived with the next major release if you use versioning for designs. Figma’s version history of the file should provide access to them.
• 🟢 New: Added a frame to an existing design.

Changelog

Changelogs, often used in software development to document revisions, can also play a pivotal role in design work. Communication is facilitated by:

1. Historical Record: Change log annotations provide a historical record of design adjustments made over time. This enables team members to trace back the evolution of design decisions, understanding the “why” behind each alteration.
2. Enhanced Collaboration: By documenting changes directly in Figma, all stakeholders — from designers to developers to product managers — can quickly grasp the latest updates without having to sift through lengthy email or Slack threads or attend multiple meetings.
3. Accountability: Clear annotations on what was changed, who made the change, and when it was done foster accountability. This transparency ensures that all modifications are deliberate and well-thought-out.
4. Efficient Reviews: Stakeholders can swiftly review and approve designs by focusing on the annotated changes, rather than reviewing the entire design from scratch. This speeds up the review process and reduces the potential for oversight.
5. Onboarding Efficiency: For team members new to a project, change log annotations serve as an invaluable resource. They can quickly catch up by reviewing the design evolution and the rationale behind various decisions.
6. Conflict Resolution: In cases where design decisions are challenged or questioned, the change logs serve as a point of reference, offering clarity and helping to resolve potential conflicts.
7. Time-saving: When revisiting a project after some time, designers don’t need to rely on memory alone. Change log annotations remind us of past design iterations, saving time and reduce redundancy.

The Changelog component is attached to my community file in Figma of Notes Kit for you to test.

Power of Figma’s Version History

Figma’s built-in version history feature is a powerful tool, not just for tracking and reverting changes, but also for streamlining design communication.

The version history provides a clear and chronological record of all changes made to a design file.

Mistakes happen. Sometimes changes don’t work as expected. With version history, you can easily revert to a previous state, ensuring no effort is wasted, and the design process remains uninterrupted.

Semantic Versioning

Semantic Versioning, often called SemVer, is a versioning scheme that conveys meaning about the underlying changes in a specific format: MAJOR.MINOR.PATCH. Each increment represents a different kind of change.

The use of semantic versioning principles for Sections and Frames can allow stakeholders to reference specific versions when providing feedback. Making it clear which iteration they’re referring to. This can reduce the back-and-forth and improve feedback loop efficiency. Example: Payments 1.0, Payments 1.1

A wonderful resource from Luis Ouriach on this topic.

As I have found in my experience, adding a version in the end of the Frame as well as a change log is really helpful when looking at changes over time. However, you shouldn’t let them drive you crazy.

Concluding

After using Figma for a while and working on large and complex projects at Bolt, I’ve realized that “done” doesn’t always mean it.

Adapting and modifying designs, especially when teams are actively working on them, can be both challenging and rewarding. It’s a dance of balancing the original vision with newfound insights, all while ensuring collaborators stay in the loop.

Personally, I believe that proactive change maintenance is crucial in Figma files. Not only does it preserve the integrity of the design, but it fosters a collaborative spirit, reminding us that design is an ever-evolving process.