Realworld
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 of 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 tackle 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 that Atomic Design proposes often leads to extreme granularity that makes it difficult to maintain order and properly 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 an approach to CDD.
Benefits of Component Driven Design
- It helps to propose consistent and scalable solutions from the start.
- Facilitates the integration of new team members (reduced learning curve).
- DRY (Do not repeat yourself). No more repetitions!
- Establishes a common language between designers and developers.
- Promotes more organized and coherent practices.
- Defines clear guidelines for unit testing and its scope in each component.
- Better feedback management.
What we learned
There are many lessons learned 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 assemble any story.
- ? Collaborative teams: By involving all roles at all stages, we make quicker decisions 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
During the Friends of Figma event, several interesting questions arose. I will try to share some of those I remember and to which we responded:
One of the keys to CDD is the common language between profiles. In case of not having the same component naming 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 point is to reach an agreement thinking about the team, not the individual. If it is easier to apply a change on my part, I do it. Today for you, tomorrow for me.
It has been mentioned that in the “initial” stages of the sprints, you already conduct user tests. How do you do it without a design, etc.?
Sometimes the word “user test” creates an aura of unnecessary formality. To conduct a user test at certain points in the project, where we do not yet have very advanced content, just grabbing a piece of paper and a pen and going to a colleague's desk who is a user of the application (or sometimes it might be interesting if they are not), already provides us with a lot of information. We advocate for “guerrilla tests” with paper and pen 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.
You might 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 will 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 technological migration process in their digital ecosystem.”
We faced a considerable challenge that posed several threats that jeopardized the project's success:
- ⚙️ Combining Agile & Waterfall
- ⏰ Very limited times
- ? Very ambitious scope
We needed a hero who was up to the task.
Spoiler: Our hero was ourselves ?
We had two superpowers:
- ?️ Component Driven Design (CDD)
- ?♀️ Collaborative teams
We set up a rotating team with representation from different profiles. Within the team itself, 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 team 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 address the detected needs.