Building one design language across mobile and web

Konek was growing quickly.

Checkout. Consumer payments. Merchant experiences. Mobile. Web. Different teams solving different parts of the same ecosystem.

I led the design of Konek’s design system to make sure all of those experiences could grow without feeling like separate products.

But I didn’t want to build another giant Figma library.

I wanted to build a system for designing Konek.

The product was growing faster than the system

Early on, a lot of our decisions lived inside individual product files.

That works when the product is small.

It becomes much harder when the same patterns need to work across checkout, consumer payments, merchant experiences, mobile and web.

A button wasn't just a button anymore.

It needed to understand different sizes, states, themes, layouts, content and platforms without designers recreating it every time.

The business needed to move faster.

Design needed to make that possible without letting the product fragment.

Consistency wasn't the real problem

It would have been easy to define colours, typography, spacing and build a component library.

But consistency alone wasn't enough.

The system needed to answer a harder question:

How do we give designers flexibility without giving up control?

Too rigid and designers detach components.

Too flexible and the system stops being a system.

That tension shaped almost every decision I made.

Building the foundation

I started by pulling the product apart.

Colour. Typography. Spacing. Radius. Icons. Inputs. Buttons. Navigation. Feedback. Authentication. Payment patterns.

Instead of treating those decisions as properties buried inside individual components, I moved them toward a shared foundation using Figma Variables and reusable tokens.

That meant the system could inherit decisions instead of repeatedly recreating them.

Change the rule once.

Let the product follow.

One component. A lot of possibilities.

As the library grew, I became increasingly conscious of variant explosion.

Every new scenario could become another component.

Another property.

Another branch.

Another thing designers had to understand.

I started using Figma Slots to approach component architecture differently.

Instead of predicting every possible combination, components could expose controlled areas where designers could insert the content they needed while keeping the underlying structure intact.

The component could bend without breaking.

Flexibility without detaching

That became one of the principles behind the system.

A designer shouldn't have to choose between:

using the design system

or

designing the right experience.

Slots let us create components that could adapt to different Konek experiences without immediately reaching for detach.

Variables kept foundational decisions consistent.

Component properties exposed the things designers actually needed to control.

The system provided the rules.

Designers still had room to design.

Mobile and web are the same system

Konek wasn't being designed for one viewport.

The same language needed to work across mobile experiences and responsive web products.

So I approached responsiveness as part of the component architecture rather than something designers solved afterward.

Spacing, typography, layout behaviour and component structure were designed to adapt across different contexts.

That allowed us to share more of the system while still respecting the differences between mobile and web.

One design language. Different surfaces.

AI should do the boring work

A lot of design-system work is surprisingly repetitive.

Resize an icon.

Check the spacing.

Rename the layer.

Update another instance.

Repeat.

Those details matter.

But I started questioning why designers needed to spend so much time manually maintaining them.

That's where AI became useful.

AI became part of the system

I started using Figma AI for the repetitive work surrounding the library.

One example was icon sizing.

Rather than relying on designers to repeatedly resize and position assets across components, I explored using AI-assisted workflows to make that behaviour more systematic.

The goal wasn't to have AI make design decisions.

It was to remove the repetitive work surrounding those decisions.

So designers could spend more time on the parts that actually required judgment.

AI became the librarian too

There was another problem nobody sees in the final interface.

Layers.

A design system can look incredibly organized from the outside while being complete chaos underneath.

Frame 482

Group 19

Vector 27

That might not matter when one person owns the file.

It matters a lot when other designers need to understand it.

I used Figma AI to systematically rename layers throughout the system, creating clearer naming and hierarchy across components.

It's probably one of the least exciting applications of AI I've worked on.

And one of the most useful.

Designing components that understand context

The goal became making components do more of the thinking.

Slots provided flexibility.

Variables carried foundational decisions.

Component properties exposed intentional controls.

Responsive behaviour helped patterns move between mobile and web.

AI handled pieces of repetitive maintenance.

Together, those decisions meant designers didn't need to rebuild the logic every time they used the system.

The intelligence lived closer to the component.

A system for designers and engineers

The design system couldn't end in Figma.

Ultimately, these decisions needed to become software.

That meant thinking about components in a way that could translate more naturally into implementation: shared tokens, predictable properties, reusable structures and clear states.

It also changed conversations with engineering.

Instead of handing over isolated screens, we could increasingly talk about the underlying rules:

What is fixed?

What is configurable?

What is inherited?

How should this respond?

That creates a much healthier relationship between design and code.

What changed

Konek moved toward a shared design foundation across mobile and web.

Instead of solving the same UI decisions independently across products, designers could work from reusable components, variables, tokens and interaction patterns.

Slots gave components more flexibility without requiring endless variants.

AI helped remove repetitive maintenance like layer organization and parts of component setup.

And responsive thinking became part of the system rather than something added at the end.

But the biggest change wasn't visual.

It was that the system started carrying more of the work.

What I took from it

Building Konek's design system changed how I think about product design.

I started the work thinking about components.

I ended it thinking about infrastructure.

The best design systems don't just document what has already been designed.

They encode decisions.

They create constraints.

They remove unnecessary work.

And they give teams more room to focus on what hasn't been solved yet.