At Compare The Market, part of the Customer Experience (CX) team's mission is eliminating inconsistencies within the company’s ecosystem of offerings.

With product verticals tending to design in isolation and optimizing solutions for individualized goals, our experiences became inconsistent and disjointed over time. The collective set of our web experiences was characterized by a lack of cohesion; evidenced by fragmented implementations littered with a spate of unique design patterns and various visual styles.

Designers at Compare the Market are embedded within cross-functional teams dedicated towards specific product streams. To ideate and iterate more productively as we traverse between product domains, we benefit from having a single source of truth that provides a scalable design language to guide our crafting process.

For us, this single source of truth exists in the form of our design system — a centralized, evolving hub intended to provide the necessary tools and knowledge to empower designers in building solutions that would lead towards the end goal of a unified design language across our various product streams.

As an individual contributor to the shared Figma libraries maintained by the CX team, a recurrent issue I often revisit is exploring how we might reduce introducing additional inconsistencies to the product ecosystem as a result of siloed design.

Looking towards the areas where effort could be best invested to improve the usefulness and robustness of our design system, I’ve distilled my learnings into domain areas that have guided me towards being a more purposeful contributor.

Areas of Consideration

I think the essence of a design system’s core is as a scalable framework that drives decision-making through democratized access to useful examples and foundational knowledge about the constraints, rules, and principles applying to experiences at scale.

It should be a toolkit that fosters a productive and playful environment where designers can openly explore new product territories so iteration can happen quickly and confidently.

However, building a system that embodies the definitions above comes with its own set of challenges. There are certain problem spaces that I have had the opportunity to explore in order to contribute to the solidification of the system and highlight the ways it can help the team craft unified, meaningful solutions more effectively and efficiently.

These are a mix of usage, management and technical areas, and predominantly fall under the spaces of relevance, scalability and structural integrity.

Relevance

As teams continuously improve and innovate in their spaces, CtM’s design system also needs to keep momentum in order to remain relevant and ultimately, usable.

As an individual contributor, I participate in the standard duties of implementing new components, extending existing ones, and exploring potential additions. In working with other teammates to refine new components and patterns, I observed that relevance seemed to have a history of being under-considered as a result of perception bias.

When designing for a project, the relevance of components are often contained within the perimeters of the identified domain and predefined scope. As such, it can be much more straightforward to design and refine components that either resolve or dissolve the problems at hand.

However, the challenge with component relevancy in the context of a system versus a project with clear boundaries, is the need to account for nuances and variations that will allow relevance to scale beyond a set domain. 

The focus shifts from operating within the space of a closed context towards understanding how a component can be strategically built and distributed to serve multiple teams.

The degree of relevancy a component has is defined in part by the completeness of its build, its visual and functional properties, and how it adheres to the principles that form the DNA of the system.

I’ve found that relevance can be deconstructed in a number of ways, for example:

• The relevance of the components to the designers using the system, and whether it is fit for purpose and usable for current and future initiatives in its intended product domain.

• The relevance of the components in the context of a singular product stream versus its role in other, possibly unrelated product streams.

• The relevance of the system as a whole to the current and future-state of product experiences.

A key lesson that I’ve taken away is to not only build components that are relevant now, but instead strive to build component relevancy into the end-to-end build process of the component. To focus on challenging ourselves to construct components in a manner that allows for it to be relevant even in the future, when changes inevitably need to be made.

A valuable component is one that is relevant in the majority of reasonable contexts. It should have an appropriate degree of flexibility built into it to be able to account for permutations and variations comfortably.

Scalability

Scalability is a multi-dimensional challenge for our design system, as it needs to be able to be flexible enough to scale not only across devices (responsiveness) wherein differences in layout, content structure and interactive elements are abundant, but also be fit-for-purpose across an entire product ecosystem (adaptive to context).

With common features having a reach that spans multiple product verticals, it is material that decisions scale as each carries with it a potential to ripple out and affect a multi-layered web of experiences.

A lesson I learned early on from our then Design System lead is that the system itself is very much a living thing, keeping in mind our system should help designers craft solutions that converge and form a cohesive overarching experience.

Like a living organism, the system grows, and scalability becomes an increasingly important discussion so that the management and evolution of the system doesn't become an unmanageable overhead for the team.

Effectively strategies for managing scale and growth is pertinent to the team being able to sustainably direct energy to the perpetual need to keep iterating and upgrading to keep the system relevant and robust.

With the rate of change often outpacing our ability to integrate the necessary updates to the system, we struggle to scale quickly enough to have the number of components needed in multiple projects at a consumption ready standard.

Something that would enable us in scaling the system, and contributions to it more effectively and rapidly without necessarily compromising the quality of the system and its parts, is to have the ability to spread the system across teams. 

By reducing the immense load and dependency on a single point of contact, as is the current situation, we will be better placed to progress from a centralized model to a federated one. The intention driving the pivot to a distributed model of contribution comes from the fact that we had a growing team, and a design system far exceeds the scope and ownership of a singular solitary guardian.

A design system is a shared resource and should be respected as such, without failing to recognise that product teams are used to having total ownership of their spaces and clearly defined boundaries. 

One of the most deeply rooted blockers in our design system’s growth was the perceived cost of contribution. Often judged as an optional investment because of its reputation for having low immediate returns despite a high resource cost, product verticals were hesitant to let their team resources bear the brunt of the rigor needed to evolve a local feature into a design system-quality component. 

In the long run, when the frequency of opt-outs add up, the comprehensiveness and quality of the design system itself suffers. Caught in a negatively-geared spiral, the system would not be able to scale, and the outward effects on this on the design team is a downward trend in adoption and usage. 

In a scenario like this, where the gaps between designs living in project files and the usable components in our global library file are continuously widening, eventually we will end up back at square one: siloed designs and experiences falling out of sync.

Structural Integrity

Drawing upon atomic design principles, the composition of our design system leverages structured fundamentals, with flexibility introduced at higher levels to allow for needed variations and customizability within the system.

When viewing the system as a whole, and factoring in the need for scale, the importance of structural integrity comes into play as we consider the rippling effects of changes to a system.

Structurally sound components are able to help its user comprehend and understand the underlying patterns at hand, as well as the logical make-up and ordering of layers.

I’ve noticed that some of the most meaningful contributions towards our design system have also been the most usable. Geared towards architecting components in a way that is easy to understand, considered in its coverage of use cases, and honors the integrity of any master pattern it inherits from or is part of.

From working with our design system, I’ve found that components constructed with structural integrity in mind are far more extensible than the average component. It allows for updates to be made in the future without necessarily causing breaking changes in the wider system. The component can withstand alterations and extensions far more gracefully as future growth is already anticipated for.

An example of this is the product card component — in building a base template well, we allow for new parts to be introduced into the bucket of lego blocks that can be supplanted in place of the basic template placeholder.

In the same vein, local components can be switched in to test out work-in-progress artefacts and new ideas. Structurally sound components encourage deeper exploration in design more productively, and allows designers to focus their attention on crafting the parts that matter most or require the bulk of their attention.

With structurally sound components, the robustness of the design system is vastly increased, with decreased maintenance overheads (often in the form of hotfixes when a flaw is identified) and less breakages in project files. The inherent benefit of a system like that lies in the opportunities it unlocks. In particular, it allows us to move faster, and think bigger, which makes it possible for teams to consider and refine experiences at scale.

Going back to the example of our product cards, prior to building what is effectively a templating system, when collaborating with other designers in the team and ideating on different content presentations within the card, relying purely on auto-layout already improved our workflows a lot. 

But when it came to swapping elements out and having to make adjustments to the local component, it would take us minutes whereas with the templating system, a structurally sound template could help us to craft a card from pre-built default component blocks in as little as 20 seconds.

By being able to move this much quicker, we are then enabled to explore the experiences of other product verticals in conjunction with the one(s) currently in focus, so that we can make decisions with longer longevity.

In Summary

In a team where designers are often working in collaboration, and having to leverage each other’s work, there has been many moments of growth for me as I learned to navigate the waters of being a meaningful contributor to a shared system that ultimately helps fellow designers in our work to create a closer bond between diverse product landscapes, so that we are moving ever closer to cohesion at an organizational scale.

Systems are composed of interrelated parts, with vast dependencies sometimes creating very complicated chains of connection between elements. Because of the interdependent nature of the system’s parts, changes that are made to a single element will often ripple out changes that affect the wider whole.

By making more considered choices when constructing components so that they are appropriately abstracted and extensible, we are able to better evolve components as needed, and clearly communicate the changes back to the system in a way that resonates, thus helping to keep components relevant and practical over a longer lifespan.