Similar to how I Documenting MeetingsDocumenting Meetings
### Basic Principles
1. Have a clear objective for your meeting notes.
2. Keep your notes concise without losing important information.
3. Use tools like [Toggl](https://toggl.com/track/) for time..., I use a simple Change log within Figma (Read: 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 ...) to track the design evolution from a design perspective. This log consists of a small component with a title (for version number and date) and a text-field (for bullet notes). The primary focus of this log is not on design changes or designers' efforts but rather on tracking common decisions and understanding shifts. (Read: Focus on Outcome, not OutputFocus on Outcome, not Output
Output is measured based on scope, cost, and time. Where as Outcome is measured based on behaviour, satisfaction, and Impact. (Impacts like ROI, Market share, etc., might be lagging indicators.)
A...)
We follow a two-number version system like XX.YY, where YY increments for any changes in design systems or minor tweaks (aligned with the concept of Ship and Show in 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...). The XX part changes only when it's based on a decision we took (not necessarily a fork, but may involve significant changes from developers).