When establishing a design system from inception, it is imperative to acknowledge its perpetual evolution and maintain accessibility for developers and other product designers.
This blog will elucidate the methodologies I employ to navigate a continuously evolving design system through diverse forms of documentation & communication, incorporating examples based on the methods I've followed.
Thank you Michael Montmoril, Bernardo Arjonilla & Angel Salagado Ramos from the design team, for your valuable feedback and inputs for setting up this design system process.
component request board
Often, at the commencement of a new product, the visual style exhibits a degree of fluidity. The evolution of component styles and usage rules aligns with the initial designs crafted for the product. In such scenarios, there is a possibility for developers or even product managers to suggest reusable components that may not have been immediately apparent to the designers. Subsequently, these stakeholders may request the design team to create these identified components using the 'Component request board' so that those requests are not just lost in random discussions or meetings.
This board can be created in any project management software. Here, I've used Notion.
Template for creating a component request
The non-designers who are trying to approach this board might still find it vague to put in their request. Therefore, a template can be shared with them for requesting these components.
- Component Name
- Use Case: Context where the component will be used.
- Description: Description including its purpose, functionality, and mention any specific design considerations
- Design references if any
- Priority: indicate the priority level of the request: Low, Medium, High, or Urgent.
- Deadline
- Additional Notes: include any additional information or requirements
design system updates log
As the design system undergoes continuous evolution, it is essential to sustain regular communication with stakeholders, facilitating their ability to offer feedback and update components that may have become outdated. This information holds significance for product managers to incorporate into new feature releases and enables developers to remain current with the latest design iterations. The 'Update log' serves as a valuable resource in this context, providing stakeholders with a concise summary of the most recent modifications in the design system file.
This board again can be created in any project management software. Here, I've used Notion. Documenting the updates with date also brings more clarity on the timeline.
Excerpt from one of the update logs
component usage documentation
Several documentation tools can be integrated with Figma, but the most effective approach observed within the team I collaborated with was to have detailed explanations positioned directly alongside the components in Figma. This methodology proved advantageous, allowing developers to effortlessly access and comprehend both the components and their usage patterns in a unified manner.
Example of component and its usage documented on figma
Reviewing with developers
One method for enhancing the refinement of design system components and assessing technical feasibility involves consistently seeking feedback from developers. This can be achieved through regularly scheduled video meetings, as well as through an async approach. The establishment of a designated Slack channel for the design system fosters informal discussions that yield valuable insights for designers. Additionally, this channel serves as a platform for disseminating regular updates concerning the design system. For example, in my case, I used to share update log links in the channel to notify individuals of recent developments.
Testing developed components with storybook
I was introduced to Storybook by my frontend developers, who utilised it for the independent creation and interactive showcasing of components within an isolated dev environment. Storybook operates external to the main application, allowing the development of UI components in isolation without concerns about application-specific dependencies
and requirements.
Storybook proves to be beneficial for testing components that are part of the design system but have not yet been integrated into the application. This proves to be a time-efficient approach, expediting development.
Additionally, it facilitates quicker testing within sprint cycles, enabling the identification of design discrepancies well in advance of the main integration. Essentially, Storybook serves as a reflection of the design system, comprising coded components that can be utilised and reused as needed supporting modular development practices.
conclusion
The outlined procedures represent the overarching steps taken to navigate the continually evolving design system and establish an efficient means to document and communicate design decisions with developers and product managers. This framework promotes collaboration within the product team, supporting quality outputs.
