Improved Integrated Enterprise Product Infrastructure with Knapsack

An comparison of typical product architectures when using either Knapsack or Storybook to manage design systems

Note: Gratitude to Andrew Rohman for mapping out these workflows and turning dozens of real-world customer cases into useful insights for others to use. If this topic scratches an itch, there’s a lot more where this came from on the Knapsack blog and in our LinkedIn posts.

Overview

The purpose of these design system architecture diagrams and explanations is to provide comparisons between design system platform solutions like Knapsack and non-platform solutions like Storybook. I’ll also dig into the specifics of why Knapsack enables the fusion of design, documentation, and code, making it the go-to design system solution for the enterprise environment. With these diagrams, I hope to show that Knapsack is best for comprehensive, enterprise-grade design systems while Storybook is more suited to agile, code-centric component development.

The diagrams below illustrate the typical architecture encountered when a product team implements a Design System (DS). I’ll provide a control example, Option 1, where there is no formal design system or design system platform, and use this option as a baseline to explain the differences. In each example I will highlight the interaction between the design ecosystem and the engineering ecosystem.

Option 1: Workflow with no Knapsack or Storybook

The diagram above is showing a typical scenario where there might be a disconnect between the design and engineering teams. While designs are created in Figma and documented in specs and guidelines, there is a question of how effectively these designs are translated into the engineering workflow, stored in Git, and ultimately delivered through CI/CD pipelines to end-user applications. The question marks highlight potential areas for improvement in the integration of design and development processes, specifically around the use of design tokens. Let’s break it down a bit more.

Design Ecosystem

Figma (the design source): In most cases, Figma is the main design tool where design assets are created and maintained. In this example, Figma is where the design assets are produced, but there is serious ambiguity regarding whether these assets are being effectively communicated to the engineering team.

Docs (Specs & Guidelines): Docs serves as documentation for design specifications and guidelines that the team follows. The connection to Figma is generally problematic in a ecosystem with no formal design system. There will be uncertainty about whether design assets from Figma are effectively documented and utilized and who has access to the docs. In our dozens of observations, the key problem is that engineering has little or no way to access or update the docs if they live in Figma.

Engineering Ecosystem

Git (Source Code): Git in this example is the repository where source code is stored and managed. Here, the interaction with design ecosystem is either non-existent or the transfer of design tokens or assets from the design team to the development team are done manually.

CI/CD (Code Delivery): Most teams have some version of a Continuous Integration/Continuous Deployment pipeline that automates the delivery of code to production environments. For digital product teams, the final output of the code delivery process is the end-user applications and/or website.

Recommendations

While, most product teams have some kind of library of design assets, not all have a formal design system. Small teams or low-complexity environments can work well withoiut formality. If you believe you don’t need a formal design system then consider these recommendations to make your workflow a little smoother:

• Improve Communication: Establish clearer protocols for transferring design tokens and assets from Figma to the engineering team. Handoffs are the weak links in teams, so extra attention needs to be given to thes transfers to prevent misunderstandings and potential rework.
• Integrated Tools: Consider using tools or plugins that facilitate better integration between Figma and development environments.
• Documentation: Ensure that design specifications and guidelines are thorough and easily accessible to developers, potentially using automated documentation generation tools. This requires some upfront effort and a clear line of communication, but it’ll save you lots of downsteam headaches.

Option 2: Workflow with Storybook only

The diagram above illustrates the architecture encountered when teams use Storybook, again, highlighting the interaction between the design ecosystem and the engineering ecosystem. I’ve listed the roles and outputs of these ecosystems below. While designs are created in Figma and documented in Docs, there is a question of how effectively these designs are translated into the engineering workflow, stored in Git, and documented using Storybook. Storybook serves as an intermediary, providing a visual and interactive way to document UI components, which can help bridge the gap between design and engineering.

Design Ecosystem

Figma (the design source): As mentioned above, Figma is the design tool of choice for most of the hundreds of conversations we’ve had with design teams. As expected, other design tools we see are Sketch, Adobe XD (soon to be sunsetted) and Framer X. Interestingly, the last option combines development with design by integrating code. Once again, the design tool is where design assets are created and maintained, but very often there is ambiguity regarding whether these assets are effectively communicated and handed off to the engineering team. I’ve yet to meet a team where there isn’t some friction between design and engineering. While that friction is ‘normal’, it’s not the standard we should tolerate.

Docs (Specs & Guidelines): There are dozens of ways teams can document their design assests. One of the most popular is to do this directly in Figma. Frontify, Zeroheight, Nuclino, Lucid and Bynder are some of the tools that focus more on design assets documentation. These host accessible websites that anyone can use to retrieve information and often feature version control. Most of these tools tend to focus on the development side, and offer ways of hosting and showing code. Integration with design tools is nonexistent; so designers will have to create an image of each design (and update), and manually (re)place them on the website. Some examples are Gitbook, VuePress, Fractal and Confluence.

Engineering Ecosystem

Git (Source Code): The repository where source code is stored and managed. Where you see the question mark on the diagram is where there is ambiguity for many teams. Specifically, the transfer of design tokens or assets from the design team to the development team is often done manually or without a closed feedback loop to confirm parity.

Storybook (Code Docs & Demos): The role Storybook plays is to make it easier to build and document UI components (somewhat in isolation), providing a visual representation and interactive demos. When maintained correctly, Storybook integrates with the source code in Git to create and maintain story files that document the UI components.

CI/CD (Code Delivery): As above in Option 1, the Continuous Integration/Continuous Deployment pipeline automates the delivery of code to production environments, which results in the end-user applications.

Recommendations

• Communications: As above, the biggest impact will always be improved communication. Whether it’s through governance or just repeating the message across all channels, you need to establish clearer protocols for transferring design tokens and assets from Figma to the engineering team and embedding these assets in Storybook.
• Integrations: Where possible, consider using the available API connections and/or plugins that facilitate better integration between Figma, Docs, and Storybook.
• Documentation: Ensure that design specifications and guidelines are thorough and easily accessible to developers, potentially using automated documentation generation tools that integrate with Storybook.

Option 3: Integrated product infrastructure with Knapsack

The diagram above shows an advanced setup where Knapsack plays a pivotal role in integrating the design and engineering ecosystems. Designs created in Figma are directly linked to Knapsack, which acts as a central repository for all design-related documentation and assets. Knapsack, in turn, integrates with Git, ensuring that the source code is always in sync with the latest design specifications and assets. Think of it as a central source of truth for both design and code. This setup helps streamline the development process, improve collaboration between teams, and maintain consistency across the product development lifecycle.

Here are some of the highlights of the Knapsack integrated solution:

• Connect and compare component implementations in Figma and code.
• Build prototypes and UIs with production coded components
• See changes to Variables, Collections and Modes applied to code in real-time

In this setup, product managers can know exactly what the team needs to design and build before they write the PRD. Designers and engineers in a hand-off meeting can know exactly what to expect in QA and cut out weeks of painful rework. Undervalued, but just as important, the brand managers can ensure consistent experience across the ecosystem, and see how changes or seasonal themes will appear to users with ease. Let’s take a closer look at how this works.

Design Ecosystem

Figma (Design Source): As in the above examples, we’re using Figma as the design source but this time Figma integrates directly with Knapsack to ensure that design assets, specifications, and guidelines are transferred seamlessly. This is a big unlock because there is no manual work required to sync Figma with the dynamic docs.

Knapsack (Shared Platform): Knapsack acts as a central hub that bridges the gap between design and engineering by providing various features and tools. Thanks to the integration, documentation remains up-to-date, while evolving with the design system. The key features of Knapsack’s platform are designed to life the admin weight off of the team’s shoulder’s and let the system do the work. Here’s what the platform stores, automates or delivers:

• Specs & Guidelines: Detailed specifications and guidelines for design and development.
• Code Docs: Documentation related to the codebase.
• Code Demos: Interactive demos of UI components.
• Brand Management: Tools to manage brand assets and ensure consistency.
• Tokens Admin: Administration of design tokens for consistent styling across platforms.
• Theming: Tools for creating and managing themes.
• Prototyping: Capabilities for creating interactive prototypes.
• Connection to Git: Knapsack integrates with Git to ensure that the documentation, design tokens, and other assets are accessible and synchronized with the source code.

Engineering Ecosystem

Git (Source Code): In the Knapsack integration, the repository where source code, schemas, and data are stored and managed is connected directly to Knapsack. Git pulls in documentation, design tokens, and other assets from Knapsack to ensure consistency between design and development.

CI/CD (Code Delivery):
As in Option 1 & 2, but because Knapsack has the advantage of managing “system of systems”, multiple apps can be managed from a single design system platform. Knapsack’s systems of systems approach helps large organizations build scalable and effective design systems. The platform allows companies to create an unlimited number of interconnected design systems that are flexible, consistent, and scalable.

Recommendations

• Leverage Knapsack’s Features: Make full use of Knapsack’s features like dynamic docs, code demos, and theming to enhance collaboration and efficiency.
• Regular Syncs: Ensure regular synchronization between Figma, Knapsack, and Git to keep all assets and documentation up-to-date.
• Training: Provide training for both design and engineering teams on how to effectively use Knapsack to maximize its benefits.

By utilizing Knapsack as an integrated platform, teams can ensure a more cohesive and efficient product development process. We generally see a range of 10–40% reduction in cycle times for teams using Knapsack. The bigger the product org, the more efficiencies. You can see why Knapsack is best for comprehensive, enterprise-grade design systems while Storybook is more suited to agile, code-centric component development.

The integration of Figma with Knapsack and Knapsack with Git ensures a seamless flow of information and assets between design and engineering. Knapsack serves as a centralized platform that maintains documentation, design tokens, and other essential assets, which helps in maintaining consistency and improving collaboration. This integrated approach enhances the efficiency of the development process by reducing redundancies and ensuring that both design and engineering teams are aligned.

Collaborative Design System Features

Knapsack enables contributions from non-technical users, promoting collaboration across diverse skill sets and enhancing product outcomes through multiple viewpoints. Storybook streamlines component development, testing, and code quality through code-based updates, catering to developers.

Central Source of Truth

Cross-functional teams often face trust issues due to disconnected single sources of truth. Knapsack advocates for central repositories, promoting collaboration, iterative approaches, and accurate understanding of the entire system.

End-to-End Platform

Managing your enterprise-grade design system with Knapsack is a collective effort with diverse perspectives leading to superior outcomes. Knapsack handles design system tooling so your team can focus on what matters most — delivering better products at scale. Teams dedicating resources solely to maintaining a custom Storybook setup can find it hard to justify the expense when it surpasses the software’s cost.

Cross-Functional at Scale

Knapsack is designed for large enterprise teams with diverse stakeholders, while Storybook is ideal for agile engineering teams that don’t require extensive documentation or design input. Knapsack is tailored for enterprises needing comprehensive documentation for a broader audience within their organization, while Storybook is best suited for quickly prototyping and building components in a code-centric environment.

All of this paves the way for a bright new future for digital production.