The Business Behind a Design System

As Qik grew, more teams were building more experiences in parallel. That growth brought opportunity, but it also made something increasingly difficult to ignore: we were spending time solving problems that had already been solved elsewhere in the organization.

The same component could exist several times in code under different names. Styles were implemented locally by individual teams. Something that looked consistent in Figma could become fragmented by the time it reached the app.

These were small decisions with a growing cost. Every duplicate needed to be built, reviewed, maintained, and eventually updated.

Cobalt, Qik’s Design Language System, gave us a way to address that problem together.

Giving the vision room to grow

My UI lead deserves the credit for leading the design system itself. The expertise, care, and persistence behind Cobalt’s foundations were central to what it became.

My responsibility was to help that work gain the support it needed.

Early on, I contributed my experience to the direction of the system. As the initiative developed, my role increasingly involved connecting its value to business priorities, bringing the right people into the conversation, and helping secure resources.

Consistency mattered to us, but leadership also needed to understand the practical cost of fragmentation. Repeated components meant repeated development effort. Local styles made updates harder to coordinate. Differences between design and code created additional corrections and maintenance.

We framed Cobalt around those consequences and the opportunity to make better use of our teams’ time.

Making room for that investment took patience. Resources were shared with immediate product commitments, and support had to be built across teams with different responsibilities. Part of my role was navigating those conversations and finding a path that allowed us to demonstrate value in phases while continuing to deliver for the business.

Bringing frontend into the project

For Cobalt to create value in the app, frontend needed to be part of shaping it.

That partnership brought important questions into the open. How should components be organized? When should something be shared? Where did the structure in Figma differ from what made sense in code?

Our roundtables made those differences tangible. An audit identified components that had been developed multiple times, sometimes with different names in design and development. Switch and toast examples each showed four implementations.

Seeing those examples helped make the cost of fragmentation concrete. It also gave the teams a shared problem to work on.

We had to understand each other’s decisions, including the reasons a flexible component in Figma might require a different structure in code. Those conversations were essential to building a system that both disciplines could use and maintain.

My role was to help create the conditions for that collaboration, connect the work to shared priorities, and support the team as it worked through decisions that crossed organizational boundaries.

How Cobalt is built

Cobalt brings together several connected layers.

Design tokens establish the shared visual foundations used in design and code. Core components turn those foundations into reusable interface elements. Pattern Library provides a place to organize reusable compositions, while templates support recurring needs across product experiences.

Documentation helps people understand how to use the system, and changelogs make its evolution easier to follow.

The Core Library serves products across Qik, including accounts, payments, lending, investments, and engagement. That shared reach is where the investment begins to compound. A well considered solution can support several teams and experiences.

The architecture also continues to evolve as the team learns from implementation. One of the roundtables explored moving from tokens defined for individual components toward tokens organized by category. The aim was to reduce the maintenance burden and help designers and developers make appropriate choices with greater independence.

For me, that willingness to examine and improve the system is part of its strength. Cobalt has to remain useful to the people building with it.

Earning support through results

We moved forward in phases, using concrete improvements to build confidence and make the case for further resources.

Qik Pro became the starting point for Cobalt’s implementation. It gave the team a product context in which to begin applying the shared foundations and demonstrate their value.

The Quick Wins presentation documents the migration from local app styles to design system styles, alongside implementation work spanning eight months and five product teams working in parallel.

Some of the clearest results came from a focused improvement to visual assets. By consolidating Cloud and Symbol assets into two reusable components, the team reported removing 192 images and 3,764 lines of code.

For those assets, implementation time fell from eight minutes to twenty seconds.

That was a specific improvement, but it made the broader opportunity easy to understand. Reuse could remove meaningful amounts of repetitive work from everyday delivery.

These results gave us a stronger basis for the next conversation about investment. Each phase helped us show what the team could accomplish and why it was worth continuing.

Building the ability to keep improving

As Cobalt developed, the work naturally expanded beyond the initial libraries.

Naming conventions, governance, accessibility, versioning, testing, and adoption all became part of the conversation. A system used across teams needs clear ways to evolve, and people need to understand how they can contribute to it.

Some of this work remains ongoing. Developer workshops, component accessibility, and further migrations are part of the next steps. That continued effort reflects the responsibility of maintaining a capability that other teams depend on.

For the team, it created an opportunity to influence how Qik builds products at a much broader level. Decisions made within Cobalt could support several product teams, and improvements could have a life beyond any single release.

Growing beyond the app

Cobalt began with the needs of the Qik app, but we started to see opportunities for its foundations to support other parts of the business.

We began adapting the system for the web. Marketing also started using it for emails and social media posts, while Human Resources brought it into internal communications.

Each context had different needs. A product interface, a marketing email, and an internal announcement serve different purposes. Expanding Cobalt meant carrying a recognizable visual language across those experiences while giving teams room to adapt it to their work.

For me, that expansion was a meaningful sign of the system’s value. Teams outside product design and development were finding a use for what we had built.

It also broadened how I understood my role as an enabler. Supporting Cobalt meant helping more teams access its foundations and creating space for it to grow beyond its original scope.

What started inside the app was becoming a shared language for how Qik presents itself to customers and communicates with its own people.

What I am most proud of

I am proud of the system our team built. I am equally proud that we helped create the organizational support for their work to take hold.

It required technical expertise, but also trust between disciplines, difficult conversations about priorities, and enough patience to earn support through successive results.

My contribution was to help connect those pieces: support the people leading the work, make its value visible to leadership, bring frontend into the effort, and keep opening space for the next phase.

Cobalt gave Qik a foundation for building with greater consistency and less repeated effort. As it expanded into web, marketing, and internal communications, that foundation became useful to more of the organization.

The most meaningful outcome was seeing the team’s expertise become a capability that other teams could build on.