Design System as Product Infrastructure

From Figma to an implementable foundation

Sisloc already had visual patterns defined in Figma, but turning those patterns into reusable components required more than reproducing interfaces.

The work came to include decisions about:

The stack included Vue 3, Vuetify 3, Vite, and Storybook.

Tokens organized into three layers

The system began with two token layers:

primitive → semantic

During implementation, it became clear that some values belonged specifically to components. The structure evolved into:

primitive → semantic → component

The architecture came to include primitive colors, semantic tokens for text, feedback, borders, typography, and elevation, as well as component-specific tokens for Button, Input, Select, Modal, Snackbar, Chip, and Tabs.

Anticipating conflicts before they happened

Another problem appeared before many overlays even existed: how could dropdowns, sticky elements, modals, tooltips, and notifications avoid a z-index war?

Instead of defining isolated values in each component, I created a semantic scale:

This turned a normally local CSS decision into a system architecture rule.

The Stepper exposed this mindset shift most clearly. Early implementations tried to solve its geometry by alternating between SVG, clip-path, shadows, pseudo-elements, and negative margins.

But there was a deeper problem. The model mixed two independent concepts: step state, with active, completed, and upcoming, and step position, with start, middle, and end.

This led to states such as completedEnd and upcomingEnd. The names appeared to represent state but were actually combinations of state and position.

Redesigning the model

Instead of adding more exceptions, I reorganized the component into independent dimensions.

A completed final step no longer needs a specific state such as completedEnd. It is simply state = completed and shape = end.

State began to control appearance, while position controlled geometry.

A clearer model simplified implementation

The geometry was also rebuilt. Instead of simulating the shape with clipping and shadows, I used an explicit SVG path.

The change came from rereading the design itself: visually, the steps did not overlap. There was space between them.

The final component exposed a simple API:

<SislocPath
v-model="active"
:steps="steps"
:interactive="true"
/>

The most important lesson was not to keep correcting the wrong structure with more CSS. Component architecture came first, followed by geometry, states, and presentation.

DataTable organized through composition

DataTable was another important architecture exercise. Instead of turning everything into a single component, the solution used composition:

The table API uses props, emits, and slots to support customization without creating new variants for every need.

The implementation also included three-state sorting and partial selection using the checkbox’s native indeterminate state.

In Kanban, frames did not define the architecture

Kanban Card presented the opposite problem. In Figma, elements such as Card, Tags, Footer Bar, and Assigned Users appeared as separate frames.

It would have been easy to turn each frame into a component. But visual separation does not necessarily mean reuse.

I analyzed the structure and treated those parts as regions of a single component because they belonged to the same Card model.

To reduce approximations during implementation, I used the Figma API to inspect frame dimensions and element positions programmatically.

Card behavior also began to derive from state instead of independent visual variants:

const taskState = computed(() => {
if (!props.task) return 'empty'

return props.taskOverdue
  ? 'overdue'
  : 'scheduled'
})

This represented scheduled, overdue, or missing tasks without duplicating the component.

Accordion consolidated an API contract

Accordion helped consolidate a contract across API, state, behavior, and presentation.

The component supports controlled use and internal state, with aria-expanded and focus behavior built in.

Select defined the boundary between Vuetify and the Design System

In Select, changes to border-width and font-size affected Vuetify’s internal notch calculation. Understanding that behavior made it possible to define where the base component should own mechanics and where the Design System should control appearance and API.

AI in the process

The system that began to emerge

The workflow brought design and implementation closer together:

Figma specs inform tokens and implementation decisions. Components expose contracts through props, emits, and slots. Storybook serves as a development and documentation environment.