5.1 Discussion of Results
This chapter evaluates the outcomes of our implementation concerning the three primary goals (PG001–PG003) defined in the Solution chapter, each of which was designed to address specific pain points identified in Chapter 3.7. The following sections examine how well each goal was achieved in mitigating the pain points.to better
Summary of Key Findings
The findings from the three user tests provide an initial evidence base for evaluating the primary goals, although they are not sufficient for drawing definitive conclusions. The tests revealed recurring patterns that offer insights into how well the current implementation performs and highlight opportunities for improving usability. Drawing definitive conclusions regarding the extent to which the primary goals of this study can be achieved requires longitudinal case studies situated in real-world adoption environments.
Findings on Usability
Our user test results revealed the following key findings regarding the usability of our plugin:
Create
4.00
Import
3.95
Export
4.69
Create: The Create feature achieved an average score of 4.0, suggesting generally positive usability with notable areas for refinement. While selecting a variant count was highly intuitive, several interface-related tasks caused difficulty. Naming the base color was unclear to participants, as the editable field was not visually signalled as interactive. While the three-parameter palette generation was designed to simplify and clarify color creation, user tests revealed that its intended intuitiveness was not always achieved. In particular, the preview panel, intended to illustrate palette generation using
color-mix(), was not fully understood. Participants had trouble linking its output to the CSS method, due to both limited familiarity with modern CSS techniques and insufficient explanatory guidance from the help icon. Dark mode adjustment controls scored lowest in usability, indicating that the intended cognitive load reduction depends on clearer parameter labelling and interaction feedback. Most participants recognised the potential of the feature only after it was explained to them. The visual results of the color palette frame were clear for all participants. But the underlying structure of it was only partially understood at first. While the component frame was greatly appreciated, the variant frame confused all participants. However, once explained, it fulfilled its intended purpose of helping users understand the origin of their variant colors and even provided an unexpected benefit. Participants reported learning a new technique for creating structured variations directly in Figma. The findings of the Create feature suggest that the help icon should be improved in both discoverability and content to better explain the purpose and function of each parameter. In addition, the interface should make interactive elements more visually identifiable. Overall, the color palette frame appeared to have fulfilled its intention of being helpful in design workflows. Future implementation could explore alternative palette generation methods to evaluate potential alternatives for improved usability and flexibility.Import: The Import feature achieved an average score of 3.95, indicating moderate usability with certain friction points. The task “choose single target mode” significantly lowered the overall score, receiving an average of just 1.7. Two out of three participants were unfamiliar with what a mode was, partly because Figma’s mode feature is restricted behind a paywall and partly because modes were rarely used in their workflows. While the average understanding score of 4.7 confirms that the core Import function and workflow were understood, the requirement to manually select a mode was perceived as unnecessarily complex. An unexpected challenge for participants was caused by not understanding what Styles and Variables are. However, this gap in understanding is more related to participants' knowledge of Figma than to our plugin’s implementation, and therefore does not directly reflect on the effectiveness of the Import feature itself. These findings suggest that our intention to streamline the import process for our target users may still pose a pain point if the UI for the target mode parameter is not improved. Participants recommended pre-filling the mode selection when only one mode exists in the collection. An improvement in this parameter can potentially reduce cognitive load for novice Figma users.
Export: With an average score of 4.69, the Export feature performed best among the three core features. Most tasks scored 4.7 or higher. This improvement suggests that completing the Import tasks enabled participants to transfer that knowledge to Export, reducing cognitive effort. The structural similarity between Import and Export appears to have positively influenced usability. The one notable exception was the scenario where the color palette frame was selected as the source for CSS output. In this case, the understanding of the CSS
color-mix()output received an average score of 3.0. While thecolor-mix()syntax reflected the exact logic used to create the palette; most participants did not recognize this connection without explanation. This suggests that our intention of using the export as an educational bridge for modern CSS techniques was partially achieved. Strengthening the visual and textual cues that link the frame’s construction to its exported syntax could help close this gap.
Across all three core features, the usability tests revealed a clear need for stronger guidance and clearer visual cues. While the main workflows for Import and Export were generally understood, the structure of the color palette, which was intentionally designed to represent the color-mix() function, did not perform as intended. Instead, it created challenges and confusion for users. This indicates that the goal of helping designers translate what they see in Figma into meaningful implementation code was only partially met.
Help icons require improvement in both clarity and discoverability, and interactive elements should be made more visually identifiable. An onboarding flow before first use could address these gaps by introducing concepts such as modes, the role of the color-mix() function, and the link between the palette frame and the exported syntax.
Overall, the plugin was functional and well-received in principle, but its educational aspects require further refinement to achieve their full potential.
Findings on Primary Goals
PG001 sought to reduce bottlenecks and inconsistencies in the design-to-development handoff. It aimed to remove manual work, reduce the need for handoff documentation, and improve cross-functional collaboration.
Kolibri Sync addressed the underlying pain points of this goal (PP001 and PP002) by allowing CSS variables to be imported directly into Figma variables and styles and by producing structured, production-ready CSS output without relying on third-party tools. The import and export features share a consistent workflow, which allows participants to transfer knowledge between them. Our findings indicate potential to speed up handoff in scenarios where both sides of the workflow are already familiar.
However, the effectiveness of this connection between design and development workflows depends heavily on user understanding of Figma’s concepts (e.g., modes, variables) and modern CSS syntax. Without prior knowledge or onboarding, clarification may still be required, meaning some handoff documentation remains necessary. In addition, because variable names are derived directly from the Figma hierarchy, teams must agree on a shared naming structure in advance. Otherwise, the exported CSS may require adaptation to match existing conventions, reducing its immediate usability.
Overall, PG001’s objectives were partially met. The core technical capability for bidirectional synchronisation is in place, but its impact on reducing communication gaps and improving collaboration is constrained by knowledge barriers and the current absence of built-in onboarding. This workflow is most effective for teams in which designers and developers already share and adhere to a clear, agreed-upon naming convention for design tokens.
PG002 aimed to reduce manual work and errors in managing design tokens. This was addressed by automating the creation, import, and export of variables and styles between Figma and CSS codebases.
The related pain points PP003 and PP004 were targeted primarily by the CF001 feature. Usability testing showed that participants greatly valued this feature. It allowed them to quickly generate palettes and save them into ready-to-use collections, replacing the repetitive process of manually adding colors one by one.
In addition, the Create and Import features removed the need for manual entry, while the Import/Export functionality reduced the risk of human errors such as copy-paste mistakes. The table below summarises the most significant time savings observed in example scenarios.
Creating a blue monochromatic palette with five variants on canvas
~20 minutes (depending on creation approach)
~10 seconds (automated generation)
~ 20 minutes saved with our plugin
Save blue colors as Figma variables in a collection
~15 seconds per color variable (~1.5 minutes total)
Variants on the canvas are instantly saved in a collection
Eliminated manual repetition and saved ~1.5 minutes
Create dark mode palette from existing five light mode colors
30–45 minutes depending on design experience
Instant generation (palette created automatically, minor adjustments as needed)
Saved up to 45 minutes; reduced cognitive load
Translating 10 CSS variables into Figma variables
~3 minutes per variable (~30–45 minutes total)
~1 minute total
Saved ~29–44 minutes; eliminated repetitive copy-paste
Exporting 10 color tokens from Figma for dev handoff
~2 minutes per variable (~20–45 minutes total, prone to errors)
~1minute
Saved ~19–44 minutes; reduced error risk during handoff
While these improvements indicate that the key objectives of PG002 were achieved in principle for color tokens, the time savings shown are based on our own measurements in controlled scenarios. The scale of improvement in larger, real-world deployments remains outside the scope of this study and is open for further investigation. The same applies to the proposed impact of the hypothetical use cases outlined in sections 4.3.1, 4.4.1, and 4.5.1.
PG003 set out to determine the most suitable Source of Truth (SoT) for managing design tokens. Our investigation focused on identifying which platform offers the strongest foundation for maintaining design system consistency.
In our analysis of existing approaches (see section 3.7) showed that tools such as Supernova and Tokens Studio already treat Figma as the primary location for defining foundational design tokens. This industry trend indicates both technical feasibility and community acceptance of Figma’s role as a central SoT.
Our development experience with Kolibri Sync further supports this position. Defining all color tokens directly in Figma and then exporting them through the plugin reduced ambiguity and simplified the handoff to UI development. In user testing, participants confirmed that centralizing token management in Figma and synchronizing to code was the most efficient workflow they experienced. This suggests that a design-to-code workflow, with Figma as the starting point, is a practical and effective approach to SoT management.
However, positioning the SoT in Figma comes with notable limitations. At present, Figma does not provide built-in change tracking for design tokens (Figma, 2024). This limitation makes it harder to maintain version history or audit changes. In contrast, solutions like Supernova centralize the design system outside Figma, integrate documentation, and provide a direct design-to-code pipeline. Such an external approach can offer greater clarity and governance.
Based on our findings, Figma currently offers a strong foundation for SoT management in small teams. However, the optimal SoT may lie either in Figma, if its design system documentation and version control capabilities are expanded. Or in an external, dedicated platform that integrates tightly with Figma while providing clearer design system management features.
Problem Statement
This thesis set out to answer the question:
How can a synchronized workflow between Figma design systems and CSS codebase be established to maintain a clear Source of Truth (SoT)?
The development and evaluation of Kolibri Sync showed that our solution can streamline synchronization between design and code, improve efficiency, and reduce manual errors. Although the industry tends to work in a design-to-code workflow, our implementation stands out by enabling full bidirectional synchronization between Figma and CSS variables. Kolibri Sync managed to fill the practical gap by providing a Figma-native solution, without third-party dependencies.
Although the optimal SoT remains uncertain, our findings suggest that small teams and lightweight design systems benefit most when the SoT is in Figma, especially given when the fondation of the design choices is established in Figma. In this case, Kolibri Sync can reduce inconsistencies by exporting from Figma, providing developers with a reliable foundation and correct version to implement a design. The import function further reinforces Figma as the SoT by ensuring that changes made in code are synchronized back into Figma, keeping the source accurate and up to date.
For larger, more complex systems, an external SoT with stronger documentation and governance features may be more suitable.
Overall, this work delivers both practical insights and a proof-of-concept implementation that demonstrates how Figma design systems can be synchronized with CSS codebases in a way that supports bidirectional workflows and reduces dependency on external tools. While the results are promising, they are based on a small user test iteration and focus only on color tokens. These constraints leave room for further research in this field and improvement of our plugin.
Last updated