Component Driven Development, how it can change the game for you.
You would have already heard about CDD (Component Driven Development, this is how it will be addressed in this write up henceforth) via various sources and there are tech giants who do follow this devotedly. I will start off with a very short introduction and will also add some of the flavors you may add to your scenarios at your organization. For starters CDD is all about having presentation layer components which can be maintained and versioned separately so that you can seamlessly integrate them across different products at your organization. Now at different organizations and products you will have your own custom use cases. The question obviously from a leader’s perspective should be why should I invest on something like this, because the scale of investment from an effort and thinking per se is not going to be small.
Now lets take a step back and think as to what happens while building a product(s) and its features. You will be having a UX team working in tandem with a Product Design team, ironing out the workflows, wireframes, interactions and the requirement related documentations. We would also have Visual Designers giving brand related colors to those requirements. This once signed-off will be handed over to the engineering team (please note that ideally the engineering team is involved during the previous phase collaborating on the technical details necessary for the details discussed). Now the engineering (I am including the QA organization within the Eng. org ) team will be proceeding with the development using the LLDs, test designs, writing unit test scripts, code etc. This gets reviewed and eventually reaches production. Now in this scenario we can assume multiple teams are running in parallel and developing many similar code/components at different areas of the application and for different products within an organization. This could result in extra effort in hours (which in turn is dollars for the organization) and result in duplication of code affecting maintenance of the application(s) code. Also there is a risk of different interactions of similar components within the same application if not manually and centrally reviewed.
Now lets go back to CDD, here we are talking about a central repository which has collaboration from across the organization, with all the workflows we discussed in the previous paragraph happening at a single space. This will result in very granular to complex component being designed and developed and documented at repository which is central. These can be purely visual components, simple components, composite components, or components which can have business and may be reused across the codebase of different teams. The choice of how and what will depend on the scenarios at different places and that is the beauty of CDD. Now we have a repository with a documentation that is going to save the effort of UX, Product, and Engineering teams and also acting as the source of truth. With proper versioning this will also let you release different applications at different cycles. So basically we have improved speed of development and testing, increased documentation coverage of the code, made code maintainable, reusable, make your components and hence applications more accessible and in a way improved scalability too. This also helps in scenarios of micro front ends too. Included a very high level flow diagram too below
Couple of platforms you may refer to for this purpose is storybook or bit.dev. Storybook also provides Chromatic, which is an automated workflow platform. They also have an interesting feature for UI review. Both platforms are very actively used and Storybook has a very active community with lot of add-ons to be used across frameworks like Angular, React, Vue, etc. Storybook also let you create your own deployments and CI/CD integrations for people who prefer custom and also host the documentation of your choice. Addons for Storybook can be found at https://storybook.js.org/addons. Couple of my favorite add-ons are Storyshots (snapshot testing), Accessibility (A11y testing). There are many other cool add-ons too, if interested do check them out.
I would say if given the right thought and attention, this is something that could end up saving a lot of cost and effort and also streamline development and design process at a long term.
