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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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
Make sure you're subscribed to our emails, so you don't miss an invite.