We, at Kaleyra Designs, currently follow Ship-Show-AskShip-Show-Ask
Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the option to continue shipping changes. There are three categories of changes in this method. They are **Shi... format for Design System Branching. We keep Decision Documentation for CommunicationDecision Documentation for Communication
Similar to how I Documenting Meetings, I use a simple Change log within Figma (Read: Changelog as a consistent communication tool) to track the design evolution from a design perspective. T..., and use Changelog as a consistent communication toolChangelog as a consistent communication tool
Changelogs are a great way of effective communication. It provides a clear idea on what is done, and why it's done. Also, it communicates to the user about the value the new feature adds / problem ....
For Ship, designer directly merge it to design system, and take care of feedbacks. If it's more complicated, the change will be added (and show) as a variant, and will clean up as we have more clarity. If the sophistication and impacts are high, we save it a s a new component, and discuss it in our bi-weekly 'Ask' meetings.
Source
- Ship-Show-AskShip-Show-Ask
Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the option to continue shipping changes. There are three categories of changes in this method. They are **Shi...