I led the creation and adoption of the Panenka Design System, establishing semantic tokens, reusable Figma components, and documentation while advocating for consistent usage across teams—streamlining handoff and cutting days off design and development time.
(2024)
While using Tailwind CSS UI Kit, our team faced significant designer and developer inefficiencies. Designers struggled with Tailwind’s scale-based approach (e.g., grey-700), which made styles difficult to reuse or maintain across projects.
Meanwhile, developers encountered multiple implementation methods, inconsistent mappings between Figma and Tailwind, and extra code review overhead. These challenges led to longer design and development cycles, reduced component reuse, and inconsistent user experiences across our internal backoffice tools.
To address these challenges, we built the Panenka Design System — a unified foundation that bridges design and development. Our solution included a function-oriented design library in Figma, where tokens like text-primary and bg-surface replaced scale-based Tailwind variables (e.g., grey-700), enabling more intuitive, consistent application of styles. On the engineering side, we developed a component library in code aligned with these tokens, ensuring a seamless handoff between Figma and implementation. The system was documented through a centralized style guide outlining usage principles, accessibility standards, and interaction patterns.
We began with an audit of existing backoffice screens to identify visual and functional inconsistencies, then established semantic color and text tokens in Figma and code, moving from Tailwind’s scale-based naming to a more intuitive, function-oriented system.
Components were prioritized by impact and frequency, with designers and developers paired to co-create each one through focused component sprints. Final components were built in code, added to Storybook, and documented with clear usage guidelines, creating a scalable foundation that aligned design and engineering while ensuring consistent experiences across internal products.
Through this project, I learned that launching a design system is only the beginning. True success comes from ongoing maintenance, advocacy, and iteration. Design systems are living products; they evolve as the product and team evolve. I realized how important it is to continually nurture both the designer and developer experience, gather feedback, and refine components so the system remains useful, adopted, and scalable over time.
Developer
I led the creation and adoption of the Panenka Design System, establishing semantic tokens, reusable Figma components, and documentation while advocating for consistent usage across teams—streamlining handoff and cutting days off design and development time.
(2024)
While using Tailwind CSS UI Kit, our team faced significant designer and developer inefficiencies. Designers struggled with Tailwind’s scale-based approach (e.g., grey-700), which made styles difficult to reuse or maintain across projects.
Meanwhile, developers encountered multiple implementation methods, inconsistent mappings between Figma and Tailwind, and extra code review overhead. These challenges led to longer design and development cycles, reduced component reuse, and inconsistent user experiences across our internal backoffice tools.
To address these challenges, we built the Panenka Design System — a unified foundation that bridges design and development. Our solution included a function-oriented design library in Figma, where tokens like text-primary and bg-surface replaced scale-based Tailwind variables (e.g., grey-700), enabling more intuitive, consistent application of styles. On the engineering side, we developed a component library in code aligned with these tokens, ensuring a seamless handoff between Figma and implementation. The system was documented through a centralized style guide outlining usage principles, accessibility standards, and interaction patterns.
We began with an audit of existing backoffice screens to identify visual and functional inconsistencies, then established semantic color and text tokens in Figma and code, moving from Tailwind’s scale-based naming to a more intuitive, function-oriented system.
Components were prioritized by impact and frequency, with designers and developers paired to co-create each one through focused component sprints. Final components were built in code, added to Storybook, and documented with clear usage guidelines, creating a scalable foundation that aligned design and engineering while ensuring consistent experiences across internal products.
Through this project, I learned that launching a design system is only the beginning. True success comes from ongoing maintenance, advocacy, and iteration. Design systems are living products; they evolve as the product and team evolve. I realized how important it is to continually nurture both the designer and developer experience, gather feedback, and refine components so the system remains useful, adopted, and scalable over time.
Developer
I led the creation and adoption of the Panenka Design System, establishing semantic tokens, reusable Figma components, and documentation while advocating for consistent usage across teams—streamlining handoff and cutting days off design and development time.
(2024)
While using Tailwind CSS UI Kit, our team faced significant designer and developer inefficiencies. Designers struggled with Tailwind’s scale-based approach (e.g., grey-700), which made styles difficult to reuse or maintain across projects.
Meanwhile, developers encountered multiple implementation methods, inconsistent mappings between Figma and Tailwind, and extra code review overhead. These challenges led to longer design and development cycles, reduced component reuse, and inconsistent user experiences across our internal backoffice tools.
To address these challenges, we built the Panenka Design System — a unified foundation that bridges design and development. Our solution included a function-oriented design library in Figma, where tokens like text-primary and bg-surface replaced scale-based Tailwind variables (e.g., grey-700), enabling more intuitive, consistent application of styles. On the engineering side, we developed a component library in code aligned with these tokens, ensuring a seamless handoff between Figma and implementation. The system was documented through a centralized style guide outlining usage principles, accessibility standards, and interaction patterns.
We began with an audit of existing backoffice screens to identify visual and functional inconsistencies, then established semantic color and text tokens in Figma and code, moving from Tailwind’s scale-based naming to a more intuitive, function-oriented system.
Components were prioritized by impact and frequency, with designers and developers paired to co-create each one through focused component sprints. Final components were built in code, added to Storybook, and documented with clear usage guidelines, creating a scalable foundation that aligned design and engineering while ensuring consistent experiences across internal products.
Through this project, I learned that launching a design system is only the beginning. True success comes from ongoing maintenance, advocacy, and iteration. Design systems are living products; they evolve as the product and team evolve. I realized how important it is to continually nurture both the designer and developer experience, gather feedback, and refine components so the system remains useful, adopted, and scalable over time.
Developer