Handling Component Updates Between Prodia's Designers & Developers (Improving Communication and Version Consistency)
Design Operations, Design Documentation
Overview
Creating a workflow to manage design system updates with minimal friction and clear communication.
As our design system evolved, keeping components in sync between design and code became increasingly complex. Designers and developers faced misalignment, delays, and duplicated effort. I helped develop a collaborative workflow that supported component changes across both sides, starting from structured naming, versioning guidance, usage tracking, and a shared documentation source of truth. This effort reduced confusion, ensured smoother implementation, and laid a foundation for future design–engineering collaboration.
Following the restructure of our component library (you can read the first part here), we built a solid foundation for collaboration with the development team to create their own component library. This process began when the Prodia development team approached us with several concerns regarding their component development process:
Their library contained many duplicated components.
They often faced inconsistencies between iOS and Android components.
Components were named inconsistently, as developers named them based on personal preferences.
Many components were unnecessarily re-developed instead of being reused.
They needed help cleaning up their component library and turned to our Figma design system as a guide to achieve that.
As this was a new collaboration model at Aleph Labs Indonesia, we didn’t have a predefined best practice. Therefore, we had to experiment and refine our workflow to discover the most efficient approach.
As the person in charge for this task, I proposed an initial workflow and presented it to the design team for feedback. After adjustments based on our design cases, we finalized the workflow and shared it with the development team.
The workflow covers two main scenarios:
Creating New Components
Handling Component Changes
Additionally, we integrated a feedback loop to manage questions, suggestions, and comments between the design and development teams.
Creating New Components
Here’s a step-by-step breakdown of the process:
1. Design Finalization
Once a component is finalized (using the correct foundation, atoms, ensuring consistency with other existing components, and applying the correct layer & component naming), the design system maintainer will mark it as ‘Ready to Develop’ in Figma. This indicates to designers that the component is listed in the Component Development Sheet, and any updates must follow the Handling Component Changes procedure.
2. Data Entry
The designer inputs component data into the Component Development Sheet. This includes selecting the component type, inputting the component name, Figma library link, added-on date, and setting the design status to “Ready for Dev.” The designer PIC is also assigned, and additional notes can be included if necessary.
3. Complete the Data Entry
This process is repeated for all components marked as ready for development until the sheet is fully updated.
4. Development Review
The assigned developers (from both Android and iOS teams) will refer to this sheet to see all components that are ready for development. They’ll use the Figma library link to review component details and build their component library following the structure provided in the design system. They will also adjust the naming according to iOS/Android best practices.
5. Development in Progress
When a developer begins working on a component, they update the sheet, marking the development status as “On Progress,” adding the update date, and selecting the PIC. Once a component’s status is set to “On Progress,” no further design changes can be made to that component.
6. Completion
Once the component development is completed, the developer will mark the iOS/Android development status as “Completed” and add the status update date.
Handling Component Changes
Here’s a step-by-step breakdown of the process:
1. Checking Component Status
Designers must first verify the Component Development Sheet to ensure that the component isn’t currently in development.
2. For Small Updates
If the component is not in development and the update is minor — such as adding a new variant, a boolean property, or implementing changes that don’t affect features already shipped — the designer can make updates directly in the Figma component library.
After applying changes, the ‘Ready to Develop’ mark in Figma will turn to yellow. Designer need to add developer notes and mark the change as Done for the mark to turn back to green and they must log the changes in the component change log.
3. Component in Ongoing Development
If the component is in development, the designer should create the necessary changes as a new component in their local Figma file for the current epic. Once finalized, the component should be moved to the Figma component library under the “To Update” page and placed within a section named after the corresponding epic.
4. Sort by Development Sequence
The design system maintainer will then sort the section based on the development sequence for each epic & check if all the component creation rules have been followed.
5. Deprecating Old Components
As development time approaches, the design system maintainer will move the new component to the appropriate page in the library. The old component will be relocated to the “Deprecated Component” page and tagged with “[❌ Deprecated]” in its name. The changes must also be logged in the component change log
6. Updating the Development Sheet
After the new component is ready, a new row will be added to the Component Development Sheet, with the status marked as “New Update,” along with the added date and PIC
7. Developer Review
The developer in charge will review the sheet for new epic components and begin the development of the “New Update” components. They’ll access the component details via the provided links
8. Completion
Once the component development is completed, the developer will mark the iOS/Android development status as “Completed” and add the status update date.
Communicating Feedback, Questions, or Comments
If a developer encounters any issues related to a component, they can leave a comment directly in Figma and add the comment link to the Component Development Sheet, mentioning the design PIC. This makes it easier to track and manage comments effectively.
How the Solution Works
The workflow has been finalized and presented to the developers, but its impact is not yet visible. Currently, most developers are focused on feature delivery, so no one has been assigned as the point person for component development.
This workflow will be revisited when the developers have the capacity to start implementing it, allowing us to evaluate what works well and what needs improvement. The key takeaway is that we are prepared. Once the time for collaboration comes, we’ll have a clear plan ready to execute.
Throughout this process, I learned a couple of key lessons:
Discussion always brings out the unthinkable cases and reveals better ideas. Special thanks to Hillary Njo and Diana Daniela, my design seniors, who contributed insightful ideas and helped refine the workflow for this collaboration.
Documenting everything may be challenging, but it is crucial for smooth collaboration. It ensures everyone stays on the same page and allows us to track progress effectively.
