2. Methodology

In this section, we present the methods and approach used to investigate how the gap between Figma design and code can be bridged through a plugin-based solution (see Problem Statement). The nature of this research is exploratory. It addresses a real-world problem that currently lacks a standard solution for bidirectional synchronisation of a design tool and frontend development.

Initial Research

We began with a literature review focused on existing Figma plugin development practices, as well as related work on UI/UX development workflows. A central part of our literature review was an extensive study on the web UI toolkit Kolibri. Although Kolibri is publicly available, our collaboration with Prof. Dierk König and Fabian Affolter provided us with vital insights into its structure and design philosophy for scalable and maintainable CSS structures.

Project Structure

The uncertainty around what is technically possible, combined with our limited prior experience in plugin development, made it necessary to work in small steps, test ideas quickly, and adapt the solution based on what we discovered. For this reason, we chose an agile approach, with weekly sprints to present progress, conduct sprint reviews, and plan the following week’s goals. We also used Notion to centralise administrative tasks and track progress. This structure helped us maintain a focused and adaptive workflow, allowing us to align implementation priorities with stakeholder feedback and avoid misallocation of time and resources.

Building the Plugin

From the beginning, the technical architecture of Kolibri Sync was guided by principles of incremental development. Key decisions such as the programming language and platform were made early, as these are difficult to change later in the process. JavaScript was chosen as the programming language, both due to its compatibility with Kolibri and our familiarity with it. This decision also aligned with the client’s requirements. Additionally, JavaScript is widely used in web-related projects at FHNW, making the project more accessible for future contributors.

With a focus on building only what was necessary at each stage, we kept the codebase clean and modular, allowing us to concentrate on core functionality and extend it gradually. When we worked on a new feature, we first verified the core functionality in a separate playground environment. For example, we tested how a Figma API call behaves before adding it to the main plugin. This helped us understand how the underlying functionality works without breaking the system. Once something worked as expected, we added it to Kolibri Sync. This made it easier to maintain stability and modularity.

We also wrote tests during development to make sure the core logic worked as expected. In the early stages of development, we focused on simple unit tests for smaller parts of the code. At a later stage, we added integration tests to check full features that rely on Figma’s API. These tests helped us confirm that all features integrated as intended. We chose to add these tests only once the implementation had become more stable and less likely to change in our source code.

To style our Plugin, we used Figma. Figma served not only as a design tool but also as a central research element. As the industry standard for UI/UX design (UX Tools, 2024), it provided an ideal context to examine the practical integration of design and development workflows. In the final iteration of our design process, we used our own plugin to style the interface and translate visual design decisions directly into CSS.

User Tests

Once the main features of the plugin were implemented, we conducted user testing to evaluate its usability. The goal was to identify what the plugin was lacking and to gather feedback on how usable it is within the context of UI/UX and web development workflows. These tests followed an exploratory approach, allowing participants to interact with the plugin freely with minimal guidance. We recruited three participants with different backgrounds: one engineer, one UX designer, and one full-stack developer with Figma experience. This diversity enabled us to observe how users from various roles approached the tool and interpreted its features. Feedback was collected through direct observation and note-taking. We prepared a set of predefined tasks in advance, but did not share them with participants. Instead, we encouraged participants to think aloud and express their impressions throughout the session. When a predefined task was missed, we would point out the task for them to complete.

Limitations

The scope and findings of this project are subject to several limitations. Our main goal is to synchronize design tokens in Figma with the codebase. Due to time constraints defined by the FHNW IP6 guidelines, which limited the project duration to six months, this thesis only covers color tokens. A significant portion of the project was spent overcoming a steep learning curve, as we had to familiarize ourselves with the Figma plugin architecture and API first. See the Playground Repository for an overview of our early experiments with Figma’s plugin architecture and API.

The plugin itself is also subject to technical constraints imposed by the Figma plugin environment, including limitations in UI rendering and sandboxing. Because Figma is under active development, we cannot guarantee long-term compatibility with future updates to its platform or API.