Design Ops for all of us
In my view [this] requires a certain state of mind. It’s an attitude which says: I’m going to make a difference, I’m going to cooperate and communicate, and I’m going to understand that in the business of delivering great software, we’re all in it together.
–What Is This Devops Thing, Anyway by Stephen Nelson-Smith, 2010
As many others I have read Kaelig Deloumeau-Prigent’s post Introducing Design Systems Ops with great joy. My head was in danger of falling off from all the nodding and seeing my past years’ work reflected in it:
A Design Systems Ops is a person who is part of a design systems team, who needs to get into the designers’ shoes, and have a feel what their are trying to conceptualize. At the same time, Design Systems Ops need to understand the engineering requirements and define methods that will help shipping and scaling the Design System. In a way, a Design Systems Ops is the translator between these two worlds.
❤
One thing though doesn’t sit completely right with me:
Who will bridge the gap between the design systems team and the engineering team?
It implies that there is a “design systems team”. That might be a thing for very large companies. Kealig works at Salesforce, as does Jina Bolton. Her presentation on Living Design Systems tells us the following about Salesforce:
16K+ employees, lots of products, hundreds of developers.
For many of us, that is not the case. Most companies I know are at least one magnitude smaller: hundreds of employees, dozens of developers, and one to some products. Not to mention the 3 person startup.
All of us working in these smaller companies want their respective products to have a great UI, too.
I enjoy staying as cross-functional and flexible as the current constraints allow. Although I understand how this needs to be split up in larger companies, I haven’t met a single person yet who is excited about all the process overhead and politics it introduces.
If we want this whole idea to be a thing (and I really really do), it should scale down, as well as it needs to scale up.
A great Design System is only one part of the (hopefully) great toolchain with which we operate the usage, creation and maintenance of our great UIs. We have other problems and missing tools, too. Some questions:
- Do you even have a living Patternlab yet? Is it used across the whole product ? Is everybody comfortable using it?
- Is your dev environment supporting the use and enhancement of the pattern lab? Is all of that well documented and has a clear entry point?
- Do you notice when your UI breaks — both visually and functionally? Is everybody empowered to fix it?
- Do you lint your design code? Is it easy and clear to write code that lints without errors?
- Does your CSS scale and perform well?
- Do you have a build system for your icons, or does somebody need to click around in IcoMoon’s weird interface, knowing exactly what to export where to, without breaking character codes?
- Do you have a sandbox for prototyping UI concepts and getting feedback quickly?
- Can you export templates for Sketch, Illustrator, Photoshop, and Keynote from your pattern lab, so they don’t need to be maintained manually?
I could go on, but you get the idea.
So let’s enhance all Design Operations as a whole, not just the design system.
Thus I propose to call it DesignOps in order to:
- scale it down to all sizes and statuses quo of companies and projects
- make clear the cultural proximity to DevOps and draw from its decade of knowledge and experience
- move the focus away from a specific tool or part of the chain towards the delivery flow as a whole
So a Design Systems Ops could still exist. It would just be a more specialised DesignOps role.
What’s next?
I would propose an easy-to-understand and quick-to-get-started entry point for designers and developers alike. It should answer questions like
- What is DesignOps?
- Why should I do it?
- How do I get started while creating little friction?
- Are there best practises and conventions I can adopt?
To find answers to those questions, a dedicated space might be a good idea. I created one at GitHub/DesignOps — so please join the party.
