Planning the technical architecture of your design system

Introduction

As an enterprise software-as-a-service (SaaS) platform, we find ourselves in a lot of conversations with information security and architecture teams. These conversations usually center around where design system source code or other proprietary data is managed and if/when/how that data is connected to Knapsack’s cloud service, which connects design and engineering tools to create a collaborative workspace.

After dozens of these conversations with companies ranging from start-ups to the Fortune100, it’s clear that there is no consistent standard for design system architecture, even across the most effective product organizations. 

What we hope to offer in this article are some consolidated observations and considerations for your teams and stakeholders as you evaluate the current or future technical architecture enabling adoption and scaling of systems within your team’s digital production workflows.

Trends & Observations

These are our biggest takeaways and common themes from our conversations on design system technical architecture - and from our experience seeing how decisions play out over years.

Uncharted Territory

For most teams we speak to, this is uncharted territory - whether they recognize it or not. And Info Sec’s first tendency when something is new is to assume the worst. We often are presenting an entirely new type of solution, tangential to core product infrastructure and workflows, valuable internally and externally, and critical yet non-sensitive. 

Even applying familiar concepts and processes around SOC, cyber security, and policy enforcement can get confusing in the context of cloud vendors, design systems, and cross-functional collaboration. Many design system point solutions are not (yet) built for enterprise or are open-source / fully controlled internally. Comprehensive, enterprise-ready platforms like Knapsack are still rare, causing security and architecture teams to understandably tread carefully

So don’t be shocked or deterred if you hit some furrowed brows and suspicious questions at first. But trust that the points below can help guide a productive conversation.

A Different “Critical” than Product

Successful teams treat their design system as mission critical, meriting mission critical infrastructure. But they also handle design systems differently than core products (more on that below) so that they can effectively stand up, sustain, and scale their system practice - across all of the teams and organizations that stand to benefit - without hitting major (unnecessary) technical hurdles. This perspective is too often learned by way of challenges that arise long after decisions are made (in that uncharted territory).

Design system infrastructure should integrate tightly with product infrastructure and workflow and be aligned to enterprise architecture (particularly: code management & distribution), but the unique needs of the design system also merit different approaches to architecture and enablement that allow organizations to maximize their return on the investment in the very architecture we’re discussing.

Scope and Purpose

Whereas product infrastructure is fundamentally focused on enabling engineers to work securely with source code to develop and release applications, the purpose of design system infrastructure is much broader. To maximize ROI, the design system needs to engage and unify workflows for cross-functional and cross-departmental teams.

• Brand, Product, Design, Engineering, Marketing, QA, Copywriting, Compliance, Accessibility, and Leadership teams all need to share access, join workflows, and integrate systems to get the most benefit for the business
• External agencies and partners need access so they can stop remaking the same assets and focus on delivering better, more innovative work faster
• Recruits and new hires should be empowered to see how teams work and the culture they’re stepping into - and should get up to speed quickly using the same tools being used by the most effective teams delivering impact already

Treating system infrastructure exactly like product infrastructure by default likely sacrifices a major portion of the potential value - or requires significant additional technical overhead to re-enable these types of collaboration and connectivity.

Policy + Technology

At the end of the day, a consistent key to success we see is balancing technical and policy requirements. Many teams don’t have policies that explicitly cater to the specific scenario at hand - and all the considerations listed above. At the same time, technology systems and existing infrastructure likely weren’t built with these broad needs in mind. Coming to a solid consensus decision should involve a collaborative review of the considerations herein, as well as the questions below, and will usually involve either leniency (with context) on an existing policy or implementing new policies and standards to accommodate the improved ways of working to which the organization aspires.

Decision Framework

As always, a little preparation will help you navigate this decision process. We like to start with the following questions, which help outline the scope and potential for the system for your particular organization:

• What teams, people, or services need access to the design system internally and externally? Creating a clear map of your teams, potential users and contributors, and systems and platforms across design, engineering and product that could benefit from accessing or connecting their workflow with the system
  
• How sensitive is data and content in your design system? More often than not, we find that an audit reveals most system content - especially that which doesn’t require privileged access (e.g. through SSO) - is not sensitive to the business at all, and is ok to be managed on secure-but-not-locked-down systems, or even made publicly available.
  
• What tools, infrastructure, and technical capabilities exist that you will want to keep, leverage, and or integrate with? This often includes git repos, integrations with testing services or libraries like Style Dictionary, and more general elements like Figma and Jira. Always consider the product engineers’ priorities so you can plan for minimal disruption and smooth rollout of any change.

The Time is Now

Whether you’re starting from scratch or looking to improve an existing design system practice or platform, the effort likely feels pretty daunting. Maybe your organization is new to design systems and the nuance and nascency of the space is causing apprehension, or perhaps the sheer complexity and scale of your organization - or existing momentum even - is enough to hinder meaningful progress. 

If your organization isn’t getting what was hoped for out of your system practice, or you know there are opportunities for improvement to the cross-functional stack, don’t wait to start the conversation.

Conclusion

We’re confident that if you leverage the takeaways above from teams that have been through this journey and evaluate your organization’s needs using the key questions we’ve laid out, you’ll end up with a technical stack for your system that sets your business up for long-term success.

If you need help with that conversation, or you just want to learn more about trends in design system architecture, workflows, or change management, Knapsack and our partners are always up for a conversation with no strings attached.

Reach out to us at hello@knapsack.cloud