The Ins and Outs of Design System Ops
- Design System Ops is a way of operationalizing and standardizing design systems and its components
- It can help teams reduce inefficiencies, optimize workflows, evangelize design system, and make it easy to scale the system.
- Anyone can start Design System Ops, just find out who your users are, define the Design System Ops issue you want to get rid of, implement a solution, and measure its impact.
- A good tool for Design System Ops is UXPin Merge that helps you import UI components from your design system and use them to create prototypes in the design editor.
More Ops roles appear as companies and departments look for efficiencies and reduce operational costs. You’ve probably heard of DesignOps, but what do you know about Design System Ops?
We have based this article on UXPin’s 2017 webinar Design System Operations with keynote speaker Kaelig Deloumeau-Prigent, who was working on Shopify’s Polaris design system at the time.
Find out what design system Ops does and how you get started in your organization. We highly recommend our free eBook DesignOps 101: Guide to Design Operations, which covers DesignOps fundamentals.
Optimize your design system with UXPin–the world’s most advanced end-to-end design tool. Whether you’re a startup with a team of one or a multinational organization with thousands of employees worldwide, UXPin has a solution to meet your needs. Sign up for a free trial to explore what UXPin has to offer.
What’s the Purpose of a Design System?
A design system must provide designers and engineers with the tools to build and scale products quickly, coherently, and consistently.
More than a collection of components–a design system provides users with documentation, best practices, principles, and guidelines to ensure team members ship products that meet brand and usability requirements.
What is Design System Ops?
Design System Ops seeks to optimize the processes and standards for taking new design system components and templates from design to release.
The aim is to reduce “decision fatigue” with a frictionless delivery process through tools and protocols. This optimization allows the design system team to spend more time on creativity, innovation, and quick delivery rather than operational procedures and decision-making.
Why Operationalize Design Systems?
As UX and design system expert Nathan Curtis famously said in a 2016 Medium post: “A Design System isn’t a Project. It’s a Product, Serving Products.”
Design System Ops must reduce workflow inefficiencies to serve its users and products while bridging the gap between design and development. The goal is to implement tools and processes that ensure new releases mirror the original design’s fidelity, functionality, and usability.
Who is Responsible for Design System Ops?
A design system Ops manager must be someone experienced with design and development. They must understand both processes to identify and fix problems effectively.
Design system knowledge and experience are also essential. An Ops manager cannot optimize the operations without a fundamental understanding of building, managing and scaling a design system.
Unlike traditional DesignOps, which focuses on design, and DevOps, which focuses on development, design system Ops straddles these two disciplines providing support to designers and engineers.
How Design System Ops Supports Developers
To ensure releases meet design specifications, design system Ops spends a lot of time creating tools to support developers. The operations look at the end-to-end development process to find inefficiencies and provide solutions.
Here are some examples of how Ops supports developers:
Design Handoffs – Optimizing Designs for Performance
- Ops must define what happens to an image or asset from design to development. If they must convert an asset from PNG to webp, how do they do that–is there a tool, or do they do it manually?
- What’s the best way for engineers to load assets?
- What format do engineers use for assets (PNG, JPG, SVG, etc.)?
- Do developers optimize images during the build, or do they use a CDN?
- Standardizing and optimizing HTML and CSS markup for assets to deliver the best performance.
- How do engineers use fonts for various platforms, including the web, iOS, Android, etc.?
The Developer Experience
- Local development environments must be fast to set up so engineers can start building immediately. For example, creating a new project should be as simple as yarn start, npm start, or whatever your tech stack uses to initiate.
- Linter configuration–The standards and practices for writing code.
- Ops must answer the question, “how do you build a new component?” What steps must developers take to ensure maximum consistency and efficiency?
- Releasing updates should be effortless, preferably a quick single-button release–how does Ops implement such a process?
- Ops must assess how devs run tests locally and how long that process takes. If necessary, they look for tools and methods to streamline testing so engineers don’t waste time waiting for tests to run.
- Visual regression testing–how do changes to a component impact the design system, and how do devs test?
- How can Ops optimize and automate accessibility testing? For example, using tools to inspect code for ALT tags.
These are just some examples of the design system Ops approach to supporting engineers. The overarching theme is “how do we make reduce decision-making so engineers can ship releases faster?”
The design system team and its users should never have to ask, “how do I do this?” or “where do we find that?” Ops’ goal is to maximize design system efficiency and reduce time-to-market for releases.
Design System Ops–Where to Start?
1. Who Are Your Users?
To implement design system ops, you must start with user research. The first question you need to ask is what tools and languages are team members using?
- For developers: What is the current tech stack, and what IDEs do engineers use?
- For designers: How do UX designers create wireframes, mockups, and prototypes?
When Ops understands how teams work, they can find and fix inefficiencies. The goal is to find bottlenecks and roadblocks in the design system release process.
2. Define the Problem
Once Ops identifies an issue, it’s crucial to define the problem to implement the correct solution. Is there something wrong with the process, or is it a matter of better training?
3. Implement Findings
Once Ops finds a solution for a specific problem, they need to implement it. Implementation might include providing training, workshops to promote usage, updating documentation, etc.
4. Measure and Monitor Results
Design systems Ops uses various tools and metrics for monitoring and measuring a design system and its users. If you have a website for your design system, tools like Google Analytics can track clicks, downloads, and other metrics to see how people use it.
Ops also want to monitor critical metrics to identify issues and bottlenecks, including:
- Build time: How long does it take developers to build new components–from design handoff to release?
- MTTR (mean time to repair): How long does it take to fix design system issues?
- Quality: Error and rework rates. Frequency of usability and accessibility issues.
As Kaelig Deloumeau-Prigent mentions in UXPin’s Design System Ops webinar, “Success should be measured by the problems you solve rather than the tools you put in place.”
In other words, don’t be quick to fix something that isn’t broken. Design systems Ops isn’t about introducing tools; it’s about finding and fixing inefficiencies.
Optimize Your Design System With UXPin Merge
Bridging the gap between design and development has never been easier than with UXPin Merge.
Merge allows you to sync a design system hosted in a repository to UXPin’s editor so designers can build prototypes with fully functioning code components.