Overview
Kärlek: A System That Helps Lovable Build with Love
The Team
Contributions
Time Line
1 Sep, 2025
to
12 Dec, 2025
Project Outcomes
Problem
Lovable Needs Structure to Grow Further
As Lovable rapidly adds new features, its visual design has become increasingly fragmented. New additions feel disconnected from the brand, which can reduce user trust and make it harder for designers and developers to manage and scale the product. Additionally, limited focus on accessibility has led to gaps that do not align with industry standards. These challenges can be grouped into three core issues: slower workflows, inconsistent design, and accessibility gaps.
How might we design a flexible design system that adapts to a fast-growing startup’s evolving needs, while establishing a strong, consistent visual language, enforcing accessibility standards, and enabling an efficient product development process?
Process
Designing an Adaptive System for Lovable's Unique Requirements
We tackled this in three steps. First, we identified what was actually causing the issues. Next, we cleaned things up by removing unnecessary elements and creating standards. Finally, we built a UI system based on this new foundation and documented how to use it properly.
Creating an Orderly Record of Ambiguities
We began by breaking down Lovable's UI, collecting all the different styles, components, and colors we could find. We analyzed what constituted key design decisions versus what would have been mistakes. After summarizing insights from this analysis, we documented and organized an inventory that served as the foundation of our design system. By discarding ambiguities—such as similar colors or redundant button styles the remaining elements became our core design requirements.
Lovable's UI Invetory
Insights
33 button styles: It should be reduced for consistency, as many elements were highly similar and resulted from oversights or repetitive work, with style variations offering no real UX benefit.
Inconsistent color application: Some colors appear only once (e.g., yellow partner cards), suggesting potential oversights rather than intentional choices.
Light/dark mode inconsistencies: Button colors vary significantly between modes, and multiple primary/secondary colors make it difficult to establish unified CTA principles. Dark mode text and tabs (especially outlined tabs) have poor readability and need accessibility improvements.
Unstandardized hover states: Text and button color changes on hover are inconsistent. While minor, these accumulate and weaken overall design consistency.
Accessibility concerns: Many interactive elements were not fully keyboard-navigable, and the tab order was inconsistent and confusing across screens. Additionally, image alt text was unclear, vague, or non-descriptive.
Creating a Flexible Token Strategy
In the next stage, where we defined semantic tokens, I played a key role in mapping colors, spacing, and typography to meaningful values. For example, beige.100 was assigned as the secondary button background, and a spacing value of 10 was mapped to a medium gap. These mappings laid the foundation for component design, and I also helped define semantic colors that adapted to both light and dark themes.
At this stage, we removed color ambiguities by grouping highly similar colors into a single semantic color. For example, secondary buttons had three different hover colors across the website; we unified them into one, which reduced unnecessary button style variations.
Designing adaptable components that scale across layouts, modes, and varying requirements, with clear guidelines for how and when to use them.
After building a solid token foundation, we created the UI Kit using Auto Layout 5.0, where I ensured each component followed the correct layout, grid, and spacing configurations for responsiveness. We also refined the visual language by resolving inconsistencies for example, standardizing buttons to squircle corners for seamless nesting with parent components resulting in a more cohesive system.
For every component, we documented its usage to make it easy to understand and apply. The documentation was structured into three clear sections: the component anatomy, examples of where it should be used, and best practices. This was supported by global accessibility guidelines as well as component-specific accessibility notes, ensuring both design and implementation followed standards.
Component Anatomy
Component Usage Examples
Component Best Practices
Solution
Kärlek: Fast, Consistent & Inclusive
Fast.
Kärlek automatically supports Lovable’s light and dark themes using Figma’s appearance modes. Designing in one mode is enough, as components are consistently translated across both, saving time and ensuring visual consistency.
Consistent.
Inclusive.
And More Importantly Kärlek is Easy to Adopt
As a rapidly growing startup, Lovable has specific needs for adopting a design system particularly one that supports innovation, evolves alongside its products, and is easy for new users to grasp. Kärlek addresses these needs by emphasizing design values that foster flexibility, alongside clear policies and guidelines that make the system intuitive, scalable, and easy to adopt.
Flexible Structure
Our token system has a simple two-level hierarchy: raw values mapped to semantic context. Adding a new component is quick—just assign its semantic role and link to existing primitives. This makes the system scalable and fast to extend.
Always Evolving
The system is built on values of transparency, leveraging community contributions to maintain and evolve over time. This approach allows Lovable to develop Karlek as an open-source product.
Easy-to-Use
Clear documentation, usage guidelines, and practical examples make decisions easy and promote best practices, allowing even a first-day employee at Lovable to adopt the system correctly with ease.
Karlek provides designers and developers with a solution that lets them focus on what truly matters by handling repetitive tasks and offering a comprehensive, ready-to-use UI Kit. With its qualities of speed, consistency, inclusivity, and ease of adoption, Karlek enables the Lovable team to build products with more love.
Retrospective
Design System is a Product: You have to Sell it to Your Own Company.
Given the high cost of implementation and management, companies are often reluctant to adopt a design system. It’s our responsibility as creators to demonstrate that its benefits outweigh the costs. This pitch deck was our attempt to convince Lovable to adopt Kärlek, presented to peers acting as designers and developers from the company.
Show & tell your's product's story
When we presented Karlek to our peers, we received excellent feedback on the system’s comprehensiveness. The comprehensiveness wasn’t fully conveyed when we initially described it. As designers, it’s important that we effectively tell the story of the products we create.
Design values are key deciders
During the project, we struggled with standardisation—deciding whether to standardize components, colors, and styles or maintain flexibility was challenging. Ultimately, we revisited our design values and chose to prioritize user experience over strict standardization, keeping the system adaptable.
It is by logic that we prove, but by intuition that we create.
Let's Get in Touch