- Design Systems Ops
- The Nuggets translation Project
- Translator: L9m
- Proofread by: JasinYip, Shenxn, Ruixi
Great products require good communication in development and design. No matter who you are, at the end of the day, we all make software products. With the design system, communication will become much easier.
But who will bridge the gap between design and development?
I call these enablers Design Systems Ops.
Design Systems Ops is part of a Design team who needs to know the Design well enough and understand what they are trying to conceptualize. At the same time, Design Systems Ops needs to understand engineers’ requirements and define methods, which will help Design Systems to ship and scale. In some ways, a Design Systems Ops is a translation of two worlds.
Most companies have problems
In most organizational process structures, the process from concept to user is so disjointed that when the product is finished, it is very different from what the designer intended.
The signal (concept) is interfered with (inefficiency) and becomes progressively weaker, and the product ends up in a very low reduction. This failure has a huge impact on a company’s ability to create high-quality products and wastes huge business opportunities.
What does a design system do
Style guides, pattern libraries, design systems, and so on all help to normalize practices and design patterns around a common design language. And language barriers are the cause of most inefficiencies.
Start with color naming, objects, conventions, components, and so on, and go to the best and most trivial experiences, such as animation timing or circular Angle values for form elements.
A good design system can make design decisions faster. (e.g. “What color should call to action be?”). This allows designers to spend more time on user flow and exploring multiple concepts in the same amount of time.
A good design system is also the only source that helps the development team find designs during the development phase. This is great for consistency, because all call-to-actions will behave the same.
Some design systems also use code to communicate design patterns. These design systems prove their value from concept to prototype to implementation. When companies follow this approach, it can be very helpful for productivity and resilience.
A design system is not a project, it is a product, a service product — Nathan Curtis
However, some design systems don’t get the credit they deserve and are relegated to the honor roll of design patterns that are far removed from the actual production code. This is because the partial investment of several designers and engineers is not enough: a design system is not simply a project, it is a product (or as Nathan Curtis says: “A design system is not a project, it is a product, a service product.” ). In order for the design system to show value at different stages of the delivery process, it requires proper planning, user research, and methodology (and a lot of love). The teams that create the best design systems target design systems as living design systems.
Introduce Design Systems Ops
The gap between viable design systems and other design systems is huge. This is mainly due to the lack of good communication between the development and design teams. Ultimately, the product will be presented in code format, and anything that affects efficiency during this process should be checked. These inefficiencies can be remedied by introducing a Design Systems Ops persona (inspired by the DevOps movement) :
Many questions arise from both sides of the design system:
- Where can I find tags, color panels, values, ICONS, patterns, breakpoints?
- How do I load CSS when prototyping, in production, or in a Web view?
- What is the best way to load font ICONS?
- How do they affect performance?
- Where should I find documentation errors, and where should I look for other people’s solutions to their own problems (problem tracking, knowledge base)?
- How can I contribute to the design system (fix a bug, add an icon)?
- I am a participant, how can I test my code in multiple environments without making mistakes?
- I’m a developer, what should I know about designing systems?
- I’m a designer. How do I iterate on existing patterns in the browser?
- What is the upgrade path from V1.0 to V2.0?
- Where is the documentation for version 0.5.0?
I learned about open source projects like Bootstrap and Material Design Lite. At the Guardian, I started building Bridges between design and development, and it was mentioned that Sass was the main adoption. Working for the Origami project at the Financial Times also helped me discover new ideas for design at scale. Where I work today, Salesforce, has a team of engineers working as Design Systems Ops who are passionate about delivering faster and better code to users.
After reviewing my past experience of how to Design at scale, here’s what Design System Ops can do:
- Local development environment (source mapping, no refresh overload, speed)
- Hosting (placing design presentations and documentation)
- Code demo (e.g. CodePen, JS Bin)
- Technical documentation (installation, problem diagnosis)
- Front-end automation testing (accessibility, integration)
- Automated testing across browsers
- Visual regression testing
- Code Style Checking (I wrote earlier)
The previous series was front-end centric, but here are some that are closer to the back end:
- Build system
- Resource storage and Distribution (CDN, compression)
- Performance testing (resource size, server load, CDN response time, etc.)
- Release flow (e.g. Git, SemVer)
- Release processes (e.g. continuous development, continuous integration)
- Testing/Staging stage environment
- Present test and performance results (such as dashboards, mail)
Or, more on the marketing side of things (development pitch) :
- Build the sample
- Help developers to achieve this design system
- Communicate the design system to the development community
As mentioned earlier, having solid solutions in these areas can greatly help design teams improve the quality of delivery and improve the speed and confidence with which they work. This is why I believe that having a good advisor on the design team increases the likelihood of a project’s success.
conclusion
As more companies build their own design systems, they are beginning to show interest in adding technical staff to support design work and tools. Because it’s just the beginning of the character, there are questions that keep me up at night.
- What else can Design Systems Ops do?
- What tools can help small teams follow this path with limited costs?
- Besides development speed, what other aspects should Design Systems Ops judge?
I’d love to hear what you think, and if you’re in San Francisco, come over for coffee and talk.
Design Systems Ops does not have an idea THAT I came up with out of thin air. To understand where my idea came from, read Ian Feather’s Awesome Presentation About Front End Ops.
Also, listen to the Design Details podcast, where many of the world’s best designers share their experiences creating Design systems and style guides.
If you want to discuss design systems in their entirety or want to learn more about them, don’t miss the Clarity Conference in San Francisco from 31 March to 1 April 2016 (organised by Queen of Design Systems herself: Jina ₍˄ Legal.awfully ˳̫.˄ Legal₎).