Design Ops – Design Systems Ops for the rest of us

Design Ops – Design Systems Ops for the rest of us.md

Design Ops – Design Systems Ops for the rest of us

As many others I have read @kaelig'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 <3

But there is this one thing that doesn't sit 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 – to quote Jina's presentation on Living Design Systems:

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 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 our current constraints allow. That is true for me as an individual as much as for the team I work in.

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 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 for you:

• Do you even have a living patternlab yet? Is it used across the whole product yet? 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 Design Operations as a whole, not just the design system.

🤘 Design Ops 🤘

Also

Style guides, pattern libraries, design systems… all help normalizing practices and design patterns around a common language. That language barrier is actually where originate most of the inefficiencies.

One might say that this is true with the term "design system" itself :)

I don't want explaining what a "design system" is to block understanding the core of the role: to ensure and enhance that we deliver great UI to our user's browsers.

Great post! I actually totally missed @kaelig's post this week, thanks for pointing me to it :D Also: Clicking around in IcoMoon, haha I know the pain :D
Two comments:

1. Add more context: For those readers like me who hear about the "Design System Ops" post for the first time in your text, I'd provide a one-sentence summary of the idea @kaelig introduces in his text (instead of assuming it is already known). Also maybe spell out kaelig's and Jina's full names for the ones not familiar with them, and mention their employer Salesforce to point out the environment this idea is coming from. To make it even more accessible, maybe also explain what "Ops" stands for or where it is coming from.

2. Clarify the main statement or call to action: I can't quite nail down the conclusion of your text – Is it that we don't need "Design System Ops" in small to medium teams, but "Design Ops"? Or that we still need to implement "Design Systems" in our small to medium teams before thinking about roles to operate the system? Or both? One more paragraph at the end that makes that crystal clear would be awesome :)

Love it! I like the way you relate to "Introducing Design Systems Ops" and move to you main points.

I was also about to say the same thing as @Kriesse in her second point. I though "hey and now he's about to tell me what I/we should do in order to fix the situation" and then the article ends :). would be great if you'd either propose a solution or embrace that there is none and we all are now called to come up with great things.

Design Ops — for all of us — Medium

Both posts are awesome.

I'll add two bits to the disucssion, that I only bring up to add clarity:

1. There is no need to add "Ops" to the name, it just confuses things, especially as DesignOps is an emgering as a thing unto itself (see: Adrian Cleave's post). What Kaelig is describing sounds more like a Design System as Micro-Service. A Micro-Service being a descrete service that can be used by other parts of the system through APIs, in this case a design system that is a live style guide, brand guidlines, etc. that touches all parts of the product and of the departments within the organization. That is really cool.

2. Fabian brings up scale. This is important, because a company has to reach a certain mass (number of team members suporting the product) before micro-services make sense. At that point it is still one team working together, rather than multiple smaller teams. At that point, your Design System is not quite a Micro-Service, but more likely (or hopefully) a live style guide (patternlab), perhaps brand guidelines on a wiki, and only as complicated as needed as it likely still evolving rapidly as the company and product eveolve. At some point, with luck, the company will hit a point where code, style guide and teams need to be refactored into micro-services and smaller teams. And that is where Adrian's post about DesignOps kicks in.