We are starting to look into developing a design system and I really like the Atlaskit implementation. One of the questions that has come up is what does the developer workflow look like with the design system? Does a developer develop the component inside the design system itself and then the component is consumed by other applications? Or, does the component get developed outside of the design system and then it is pushed to a common repo that the design system pulls from? Any details on what a normal workflow for a component is would be greatly appreciated! Thanks.
@agile.eric.d The answer is a little bit of both of what you described. At an early stages of the design system, there was a period of defining what the patterns and components are in the system before integrating them into applications. The process is pretty waterfall-y discover > design > dev > publish > integrate. We try to incrementally release these components as much as possible. However, sometimes a comprehensive requirements gathering and design is needed to ensure the components could scale to the use cases.
As the components get used by our consumers, they would find use cases that the existing components and patterns do not satisfy. So the design system team would work with the consumers of these components and patterns and work on contributing these cases back into the design system.
What are you building? I’m interested in what prompted these questions.
1 Like
@jcheung Thank you for the information. We currently have an application that is using JSPs for rendering pages, but we have started to introduce a few React components instead so that we can start moving toward a component based frontend.
Since the components currently live in this applications codebase but we want to begin building a design system, we weren’t sure what the workflow should look like - should we continue to develop the components in the applications codebase and then push them to a repo that the design system would pull from, or should the design system be the home for these components and development is done in that codebase so the application pulls these in as dependencies.
Thanks again.
If these are components you are developing for your own application and not ones to be shared across several applications, then they would reside within the scope of the application’s codebase. If they are to be shared across several applications then it makes sense to have them reside in separate repositories which are imported as dependencies.
1 Like
@agile.eric.d My general advice is to separate if you know for sure you need to share them across different applications. This will make sure your components can be consumed outside of your codebase. But there’s going to be overhead to set that up and maintaining the build.
1 Like