Common Component Framework Foundations — Atomic Design Principles

As I continue to tackle the ecosystem of engineering productivity using Gen-AI for application development in my organisation; several POCS, evaluation exercises and deep dives led me to conclude that simply injecting Gen-AI is not sufficient for any application development process.?

We have to abstract the problem to a broader level and make it a process driven solve as opposed to a Gen-AI only solve for the future; if it has to purposefully operate at scale, and per enterprise standards to provide for the desired engineering productivity results. Hence, I am starting to pen down my thoughts in a series of articles on how to eventually realize the full potential of engineering productivity in the realm of application development with Gen-AI more as a integrated accelerator. I will get to the overall ecosystem and ideas in future articles to come.?

It all begins with thinking basic, simple and foundations.?

My search for the foundational principles as one of the pillars for engineering productivity using Gen-AI;? to craft a design system built for scale led me to a pretty interesting article and deep dive on the Atomic Design Principles. Not that this is something new, and quite interestingly it existed for a while. However, as engineers super rushed in the daily hurdles of project delivery, engineering issue resolution, and tests — we often times simply focus on build components fit for the need of the project / product. In some cases, a bright mind would start re-using already built UI elements as hardbound re-use of code to fast track build to a certain extent.?

However; if we were to think about building a common components framework set for the needs and demands of a client, which is enterprise approved, CSS design system and web framework approved - imagine the power of how it could standardise the ways of working and speed time to build, time to market and time to deploy. I still do not claim for this concept to be novel and one of its kind idea — as it still exists in pockets if you go through many developer communities who have created design systems tailor made to their project only needs. However, here we are talking about a system that could be enterprise agnostic and not just for a certain set of projects.?

The atomic design principle was originally created by BRAD FROST (https://atomicdesign.bradfrost.com/) to solve for the modular architecture problem, and I strongly believe that this foundational thinking can serve as a solid pillar for creation of a robust distributable, enterprise grade design system operating at scale. Few excerpts from the original thinking state that In nature, atoms unite to create molecules, which in turn amalgamate to construct increasingly intricate organisms. To elaborate on this idea:

• At the core of all matter lie atoms, the elemental constituents with distinct characteristics defining each chemical element. While comprised of even smaller particles such as protons, electrons, and neutrons, atoms remain the fundamental units that retain their essence, unable to be further subdivided without loss of identity.
• Molecules, in contrast, emerge as amalgamations of two or more atoms intricately bonded together through chemical interactions. These molecular formations exhibit distinct properties distinct from their constituent atoms, imbuing them with tangible attributes and functionality surpassing that of individual atomic units.
• Organisms, the pinnacle of biological complexity, embody the orchestrated symphony of molecules functioning harmoniously as a cohesive entity. Ranging from humble single-celled organisms to the marvels of human physiology, these intricate structures represent a continuum of complexity, showcasing the remarkable diversity and adaptability of life forms.

As we try and build scalable applications and also try to orient our thinking towards building a common components framework for ease of engineering — the atomic design pattern serves as a pretty reliable concept to consistently evolve and scale the engineering ecosystem.?

Taking the same idea to foundational principles for composition of UI controls —?

Atoms are more analogous to individual components that can be built out

Molecules are composition of atoms which can be looked at as a feature — which is a combination of multiple operational components.

Organisms are collection of molecules which can be looked at as a section comprising of a full operational feature E2E.

Taking the above principle a step further can be looked at as a set of templates which can turn into many things —?

• Variations in design pages
• Variations in information architecture — in terms of menu navigation systems and panels
• Creation of boilerplate project structures when looked at from a perspective architectural patterns of a web framework like React or angular to be replicated for standardisation and ease of implementation and file structure creation - based on implementation and complexity of a product
• Common Services that are rhetorically used in all project implementations I.e. error handling, error logging, authentication protocols, middleware design patterns?

The basic construct of common components framework:

Why is this structure important?

• Implementing the above structure at the foundation of a common components framework can enable a maintainable, modular ecosystem ready to operate at scale. Primarily; when the design is compartmentalised — the issues remain isolated to the compartment which makes it easier to triage.?
• Additionally, there are multiple ways of looking at the same solve when this becomes a reality ready for consumption — the distribution mechanism can be via mono repos (https://www.atlassian.com/git/tutorials/monorepos) or polyrepos or a combination strategy.?
• I personally prefer a hybrid strategy based on complexity of the squads involved in a product team; because it eventually gives us the ability to isolate atoms, molecules, organisms and templates effectively to maintain versions, make updates seamless and not hard bound to the ecosystem for consumption and easy to maintain and triage in terms of any issues arising. Alongside opening up the ecosystem for democratic governed crowdsourcing of commonly used components with safe version control.?

In articles to follow, i shall start to pen down thoughts around organisation, consumption and distribution of components. Nonetheless, there are multiple ways of solving for this idea; but i will primarily focus on housing up the foundation and then start to power it up with various agents and accelerators for seamless usage with effective automation and Gen-AI.

More to come in article series II.