Component Driven Design: Efficiency and Scalability in Digital Product

How the Component Driven Design methodology helps tackle complex and large-scale challenges in digital product design through a component-based and teamwork approach.

Recently, my colleague Anna Rovira and I had the opportunity to give a talk at Friends of Figma under the name Beyond Design Systems. In it, we wanted to convey to the attendees learnings and best practices in product design based on our experience.

We focused the talk on 3 axes: Collaborative Teams, Scalability, or how to face large-scale challenges, and the Component Driven Design methodology. In this article, I will share some of the main concepts:

Component Driven Design vs Atomic Design

Based on our experience in recent projects, Component Driven Design works better than Atomic Design, mainly because the over-division proposed by Atomic Design often results in extreme granularity that makes it difficult to maintain order and correctly reuse certain elements.

In this sense, it is relevant to note examples of some of the most well-known Design Systems from major brands like Fluent, Material 3, Carbon… which in recent years have moved away from Atomic Design to embrace a CDD approach.

Benefits of Component Driven Design

1. It helps to propose consistent and scalable solutions from the start.
2. Facilitates the integration of new team members (reduced learning curve).
3. DRY (Do not repeat yourself). No more repetitions!
4. Establishes a common language between designers and developers.
5. Promotes more organized and coherent practices.
6. Defines clear guidelines for unit testing and its scope in each component.
7. Better feedback management.

What We Learned

There are many learnings extracted from working with Component Driven Design in our projects. Among the main ones, I would highlight:

• Short-term Autonomy: After the first sprint, we can already start delivering valuable content.
• Modularity offers infinite content: Any website can be approached as a “collage” of components. Once we have the pieces, we can build any story.
• Collaborative Teams: By involving all roles in all stages, we get it right faster and leave fewer loose ends.We gain speed:
• Prioritizing efficiency over effectiveness.Economize changes:
• When you apply a change in one instance, it reflects everywhere. 
  Some Interesting Questions

At the Friends of Figma event, several interesting questions arose. I'll try to share some that I remember and to which we responded:

One of the keys to CDD is the common language between profiles. If the component naming is not the same between Frontend and Design, who should change it?

We start from the fact that one of the “cores” of the methodology is teamwork. We understand that we should not reach this point if we have worked together throughout the project. However, if you find yourself in this situation, our recommendation is to apply this mantra: “We all row in the same direction.” The goal is to reach an agreement thinking about the team, not the individual. If it's easier to make a change on my part, I do it. Today for you, tomorrow for me.

It was mentioned that in the “initial” stages of sprints, you already do user tests. How do you do it without a design, etc.?

Sometimes the word “user test” creates an unnecessary aura of formality. To conduct a user test at certain points in the project, where we don't have very advanced content, just grabbing a pen and paper and going to a colleague's desk who is a user of the application (or sometimes we might even be interested if they are not), already provides us with a lot of information. We advocate for “guerrilla testing” with pen and paper to detect things before having anything defined.

I hope these reflections help you a bit.

PS: Many thanks to my colleague Anna Rovira who is a super star..? And to Clara and Iban from

Friends of Figma Barcelona for the opportunity ?? See you at the next event!Component Driven Development Design

One of the pillars of the talk was collaboration between profiles. And what better way to collaborate between profiles than to “appropriate terms” (joke ?). The origin of CDD is Component Driven Development.. but since the “D” also fit with “Design”, the design colleagues made their own acronym: Component Driven Design.

What is Component Driven Design?

It is a methodology that places components at the core of development. Something like componentization taken to its maximum potential.

Perhaps you also wonder: What is a component? What is the difference between a page, a slider, a button, and a token?”

There are different approaches. Personally, I stick with this one: “A component is a unit of information that works on its own.”

All the examples we see in this image ? are components.

Continuing with the definitions:

What is an agnostic component?

• It is a component that does not depend on its context. This means it will continue to function visually, usability-wise, technically, etc., in any context it finds itself in.
  What is a Singleton?
• A singleton is a component of which there is only one instance on the entire web.
  “A common language for functionalities”
• By using Component Driven Design as a team, what we achieve is that all profiles adhere to the same rules.
  If you want to delve deeper into the topic, Anna Rovira talks in detail about Component Driven Design in the article ?

Beyond Systems ? Before finishing this section, we spent some time entertained with a slightly “more practical” part. I won't bore you with details, as it's not something we're going to learn by reading a few lines of text, but in case you're curious… we saw how to create slots in Figma, what tools help us in our daily work with CDD, and how we use them interchangeably between profiles.

A Practical Case of CDD

We presented a real project with a clear objective: “Collaboration with the client for the creation of a Design System during the process of technological migration in their digital ecosystem.”

We faced a

considerable challenge that posed several threats that jeopardized the success of the project:⚙️ Combining Agile & Waterfall

• ⏰ Very limited times
• ? Very ambitious scope
• We needed a hero to rise to the occasion.

Spoiler: Our hero was us ?

We had two superpowers:

?️ Component Driven Design (CDD)

• ?‍♀️ Collaborative Teams
• We assembled a rotating team with representation from different profiles. Within the team, we incorporated key profiles from our client. Bonus track: Runroom also included the collaboration of two specialists to cover specific needs: the Chief Technology Officer and the Product Design Lead.

With this multidisciplinary team, which is the usual structure at Runroom, we started working on the project sprint by sprint.

As I mentioned, one of the main challenges was combining Agile & Waterfall. In this case, what we did was work in Agile throughout the process until the delivery of value, leaving a final level in Waterfall, where the client did the integration part asynchronously with the rest of the team.

The participation of all roles in all the team's rituals was fundamental for several reasons:

Each profile could contribute their technical knowledge to uncover unmet needs.

• Each profile acted as a different ‘User-Persona’. This allowed us to test live different ways to solve the detected needs.
• Cada perfil actuaba como un ‘User-Persona’ distinto. Esto nos permitió testear en vivo distintas maneras de resolver las necesidades detectadas.