LightSketch: Design System
Building Product Consistency and Enhancing Cross-Functional Collaboration
-
Redefined product colour and UI component guidelines
-
Built the design system architecture based on Atomic Design principles
-
Strengthened communication and delivery processes between design and engineering teams
Project Duration
Oct 2023 – Dec 2024 (1 year 3 months)
Role
Product Designer
Responsibilities
Defined design specifications and enabled team collaboration
Company
Project Overview
01 | Objective
Due to inconsistencies in existing component styles, we initiated a design system to improve overall interface consistency and team collaboration. The goal was to create a reusable UI component library, enabling the engineering team to focus more on core logic development rather than repeatedly handling styling issues.
03 | Challenges
As the sole in-house product designer, I had to balance the dual responsibilities of supporting new feature design while building the design system—making time and resource management a significant challenge.
02 | Role & Deliverables
As the product designer, I collaborated closely with engineers and the product manager to introduce and implement the design system across the team. My responsibilities included defining the product colour system, designing UI component visuals and interactions, component testing, developer handoff, and ongoing version optimisation.
04 | Outcome & Impact
I introduced the design system alongside new feature design, collaborating with the engineering team to adopt Tailwind CSS. This approach successfully reduced component development and maintenance time while enhancing the integration between design and development.
Project Background
LightSketch is a web-based drawing tool developed by Ambright, a lighting manufacturer based in Munich, Germany. It is designed primarily for industrial designers. Ambright's proprietary "Printed Light" technology enables highly personalised lighting designs, and LightSketch serves as the digital entry point for this innovation.
Through LightSketch, designers can draw custom lighting shapes directly in a web interface. The system provides real-time cost estimates and automatically sends design specifications to Ambright's internal systems, where the relevant teams follow up with clients and coordinate production.
Image source: https://www.ambright.de/printed-light
Problems and Pain Points
Identified internal and product-level pain points through discussions with engineering and product teams.
Current Product Issues
1. Inconsistent Styles Across Similar Components
Although the product had a complete functional framework, the absence of a product designer in the early stages meant there were no clear UI guidelines. As a result, inconsistencies in component styling affected both user experience and development efficiency.
Inconsistent Colour Usage
For example, while CTA buttons were generally styled with a yellow background and white text, the lack of standardised colour values led to subtle variations between buttons—reducing overall visual consistency.
Inconsistent Component Styling
Buttons at the same hierarchy level used different colours, shadows, and borders. This not only confused users about the relative importance of actions but also increased maintenance and refactoring costs for the engineering team.
2. Poor Component Readability and Usability
Some UI components lacked clear visual states and actionable cues, leading to user confusion and interaction errors.
Unclear States
Toolbar buttons had indistinct visual differences between enabled and disabled states, making them hard to distinguish.
Insufficient Colour Contrast
Several components failed to meet WCAG 2.1 AA contrast standards. For example, yellow CTA buttons with white text lacked sufficient contrast, affecting both readability and accessibility.
Team-Level Challenges
1. Limited Resources and High Time Pressure
With limited manpower and tight timelines, the engineering team was responsible for both front-end interface development and complex back-end logic. Due to the lack of clear design references and support, they had little capacity to refine UI details—resulting in inconsistent interface quality.
2. Lack of Reusable Components Led to Frequent Rework
Before the design system was introduced, engineers had to build UI components from scratch for each new feature. This resulted in duplicated styles, maintenance difficulties, and inconsistent visual and behavioural patterns—further extending development and testing timelines.
Planning & Direction
Short-Term Goals
1. Prioritise MVP Components
Given the team's limited resources, we decided to prioritise supporting upcoming feature development and started the design system with core UI components that were immediately needed—such as buttons, headers, and toolbars.
Before building components, I redefined the product's overall visual style and colour system. Although the company had a basic brand guideline, the product interface and company website lacked visual consistency. Therefore, the first step was to unify the product's colour palette and typography system.
Current Company Website
Refined Product Interface
2. Technology Choices: Tailwind CSS and Three.js
To create reusable, flexible, and fast-to-develop components, we chose Tailwind CSS as the foundation for UI styling. Tailwind's utility-first approach offers a systematic set of CSS classes, allowing us to quickly customise and apply consistent design rules.
At the same time, to support both 2D and 3D visual requirements in the product, we integrated Three.js for graphics rendering alongside our UI components.
Long-Term Goals
1. Design System File Management Structure
We adopted the Atomic Design methodology to organise our design system files in Figma. Components were categorised into four main levels based on complexity—from foundational design elements to fully functional modules—enhancing maintainability and scalability across the system.
Figma File Structure
-
Foundation:
Includes design tokens such as colours, typography, spacing, sizing, and shadows. These form the visual foundation of the system.
-
UI Components:
Atomic elements built from foundational styles, such as buttons, input fields, dropdowns, and checkboxes.
-
Patterns (Composite Components):
Structures composed of multiple UI components, such as dialogs, toolbars, and headers. These have defined interaction logic and state behaviours.
-
Features:
Feature-specific compositions that combine multiple components and patterns, such as a user onboarding flow.
2. Component Version Management
With the introduction of the design system, we established a version control process to help the team track changes to component styles and maintain consistency between design and development.
Component Version History and Style Change Log
Whenever a component's style or logic was updated, I documented the corresponding version and change notes directly in Figma. This made it easier to review past changes, communicate updates across the team, and support future design reviews and version control strategies.
Design Output
Design Principles
To enhance overall product consistency, build a maintainable and scalable design system, and improve collaboration between design and engineering teams, I defined the following three core principles for this product's design system:
1. Maintain Consistent Product Style
The product structure was planned with a "LEGO logic"—starting from the smallest building blocks, such as design tokens (colour, typography, spacing), and progressively combining them into consistent UI components, which then extend to page layouts and feature modules.
Given the presence of many custom icons that couldn't rely on off-the-shelf libraries, I designed a custom icon set that aligns with the product's visual identity to maintain consistency throughout the interface.
2. Ensure Maintainability and Scalability
The system structure was based on Atomic Design, enabling components at every level—from basic to complex—to be modular and reusable. I also introduced a versioning system and naming conventions for components, ensuring that all updates could be properly tracked and that the system would remain flexible for future scaling or style adjustments.
3. Improve Design–Engineering Collaboration
By creating well-structured, standardised Figma variants, I enabled engineers to more easily understand component states and interaction logic. All components were delivered with real-use context, status variations (e.g. default, hover, disabled), and clear naming, effectively reducing communication overhead between design and development.
CTA Button Component Properties in Figma
Design Outcome
1. Starting with Colour and Typography Systems
Given that the company had an initial brand style already in place—and with limited project time—I prioritised optimising the existing colour palette, with a particular focus on addressing insufficient contrast issues to ensure compliance with WCAG 2.1 accessibility standards.
The colour system was defined with eight core colours, covering brand identity and interface functional colours—balancing visual style with usability.
Brand Colours
-
Beige (Primary):
Core brand colour used for primary actions, helping establish a consistent visual identity
-
Yellow (Secondary):
Used for highlights or secondary action cues, such as lamp placement indicators
-
Purple (Tertiary):
Supports emphasis and control interactions, preventing over-reliance on a single accent colour
Neutral Colours
-
Greyscale:
Used for foundational UI elements such as backgrounds, borders, and text
Indicator colour
-
Red (Danger):
Indicates errors or dangerous actions
-
Orange (Warning):
Signals potential risks or warnings
-
Green (Success):
Represents successful operations or completed states
-
Blue (Info):
Used for informational messages and contextual guidance
Select canopy dialog
Primary Colour (Beige):
Used for buttons and interactive highlights to enhance recognisability and maintain brand consistency.
Drawn lamp shapes and placement positions
Secondary Colour (Yellow):
Used in the 2D drawing interface to mark light tracks and placement points, making them easier to identify.
Canopy placement position
.png)
Warning (Orange) & Error (Red):
-
Error Colour:
Indicates design issues that cannot be manufactured, such as shapes exceeding fabrication constraints. -
Warning Colour:
Used for potentially problematic but still flexible designs. Users are encouraged to contact the company for further clarification.
Success confirmation dialog
.png)
Success Colour (Green):
Displayed after a task is successfully submitted, providing positive visual feedback.
Typography Guidelines
For typography, I retained the typeface already used in the company’s brand identity to ensure visual consistency across the product.
Based on common content hierarchy in the product interface, I defined seven font sizes to establish a clear typographic structure and usage rules.
-
Headings:
Used in 36px, 24px, and 18px sizes, adjusted based on hierarchy and context. All headings are set in bold to emphasise importance
-
Subheadings:
Set in 16px and 14px to distinguish sections and module-level titles. Also styled in bold to reinforce structure
-
Body Text:
Primarily set at 14px using regular weight for better readability and consistency across the system
-
Captions / Notes:
Set in 12px and 10px for secondary information or supporting content—designed to be readable without drawing excessive attention
2. UI Components and Product Pages
Object Settings Dialog
For frequently recurring setting dialogs across the product, I modularised their visual structure and defined unified styling rules using Component Tokens.
All dialogs follow the same set of tokens—such as border radius, shadows, borders, and spacing between fields. This allows us to make global visual updates (e.g. increasing corner radius or refining shadows) by simply modifying the tokens, without needing to adjust each component individually.
This significantly improves maintainability and ensures visual consistency across the system.
Stepper Component
Given the product’s functional complexity, I designed an onboarding flow to help new users quickly understand how to use it. A stepper component guides users through the process in three main stages, aligned with the product logic and learning curve.
Additionally, during the design submission flow, which requires users to enter multiple pieces of personal and company information, I used the same stepper component to break the form into manageable steps—reducing cognitive load and enhancing the overall experience.
Despite serving different use cases, both flows share the same stepper component, achieving both design reusability and a consistent guided experience.
Project Impact
Over the course of approximately one year, I established the foundation of the product’s design system—from colour and typography guidelines to a comprehensive UI component library. This system was gradually implemented and actively applied in new feature development. It not only improved consistency between design and development but also enhanced team collaboration and reduced future maintenance costs.
-
Improved overall product consistency:
Unified component styles and brand visual language to strengthen both user experience and brand identity
-
Established a reusable component library:
Modularised components through the design system, increasing development efficiency and flexibility for both design and engineering teams
-
Optimised team collaboration processes:
The design system served as a bridge between design and engineering, reducing repetitive revisions and communication overhead
Reflection & Learning
Bridging the Gap Between Design and Engineering
This project taught me that collaboration isn't just about handoff—it’s about establishing shared language early on. By co-defining logic, naming, and use cases with engineers, I learned to break down designs from a technical view, making implementation and discussion more efficient.
Designing for Flexibility
Supporting new features required flexible components. I learned that a good system balances consistency and adaptability. With Variants and Tokens, components could shift styles based on context—boosting scalability without sacrificing flexibility.
A Design System Is Iterative
A design system isn’t built all at once—it evolves. I introduced it gradually through new features, then scaled down. This "integrate as you go" approach aligned with the team’s pace and eased adoption.
