I thought my time in DevOps wouldn’t translate over to Design and UX at all, but I’ve found quite the opposite. It’s not so different to DesignOps if you think about it. Both disciplines were born by recognising that embedding robust operational “glue” will scale up a team without resorting to hiring. Here’s a few concepts I learned from my time in DevOps, that I’ve seen translate well to DesignOps.

Here’s a great introduction to DesignOps if you haven’t heard of it.

Raise cattle, not pets

When it comes to server infrastructure, we want to treat our servers as cattle and not pets. Pets are treated with special care and attention, often going above and beyond for their health and lifespan. In contrast, you’re expected to lose a couple of cattle from the herd. It’s not a big deal.

With cattle, the “farm” still makes a profit when a few die or aren’t up to par.

By following this metaphor, treating servers as cattle means we don’t care if one or two malfunction or disappear—our service is still up and available. When it comes to DesignOps, designs should be treated the same way.

Yes we should still apply a robust design process to discover, design, and validate our work, but that doesn’t mean being sloppy. The end goal is not to enable the team to deliver a high volume at speed, either. By making the design process cheap and easy, we become unafraid to try again.

If after conducting your research and validation activities the evidence points to no, it’s ok to let go. Your designs are cattle, and each one makes up the bigger part of the herd i.e. the product.

Takeaway: implement design tooling and processes to encourage effective, but disposal design artefacts and work.

Document, document, document

In order to avoid late-night calls for a fix when servers disappear, we typically capture configuration as code. If something goes wrong or there’s a transient problem, the code expresses exactly how replacing that part of the infrastructure is done.

The best DevOps solutions and tools will describe the “clean” state, and will simply respond and fix anything out of order.

Similarly in design, we should capture our processes and ways of working on paper. By making it tangible, we’re explicitly stating how we work to avoid ambiguity. Don’t get me wrong, as per the Agile Manifesto we should value people over written processes…

...but it’s bizarre when there’s no evidence or record anywhere.

Once you’ve captured your ways of working, you can not only collaborate on it together, but you can agree to it. The simple act of agreeing to something psychologically makes it easier for people to commit to it. It’s one of the strategies embedded into the Design Sprint process.

Furthermore, by capturing it you can iterate. As a designer, iteration is the name of the game. It allows you to not only improve and make it better, but to assess if you’ve actually made things worse. Having a record allows you to return to a previous setup.

Lastly, it simply helps with onboarding. New recruits will pick-up the working norms as they go along, especially working side-by-side with others, but it’s always helpful to have a written record of expectations.

Don’t forget, in larger organisations the configuration of your design tools can become complex. For example, did you know that Figma has a thing called true-up?

Takeaway: even when embedding a process or way of working, try to capture it. It helps your team commit to it, and also enables you to improve and refine it.

Make it Modular

After building a few projects, you start to see some patterns. When you compose the steps to provision and configure your app using self-contained modular units, you can save a great deal of effort.

Ansible has a library of plugins to configure your apps for example, and classic old Jenkins uses steps in a pipeline. It allows others to ignore the details, and focus on the outcome of each step. In fact, I wrote a blog on how to make a multi-step pipeline as code in Groovy – the language of Jenkins.

Similarly for DesignOps, we should be spotting patterns. What are the most common issues your team comes across? What tools do the team regularly reach for to solve a problem? Can we compose it? A recent article I read “UX Chunking: a digestible design process” works in this direction.

Design systems, after all, are perhaps the most successful example of designing modularly. New designers today don’t need to finesse how a button should work in various states, they only need to know when to use which state. The components we design with are no longer bespoke, but the arrangement is.

Processes can work very much the same way. Let’s take “ideation” from design thinking. Crazy 8’s, Worst Possible Idea, Mind mapping, Wishing are all great techniques, but I don’t need each of them every time. Depending on the problem, time constraints, and stakeholders, I can choose the most appropriate methods.

Takeaway: cut the fat by providing modular artefacts and processes as toolkits. This encourages outcomes, not Figma files.

Anticipate the deadly “Single Point of Failure”

Single Point of Failure, often abbreviated as SPOF, is a concept whereby a system can come to a grinding halt if one part of it isn’t working or isn’t available. Without any strategy for redundancy or a backup plan, you’re stuck.

Consider these design team scenarios, and if you’ve got a strategy to counter them:

• A member of the team is suddenly sick indefinitely
• Your design tool, such as Figma, is down for several hours
• All designs must be signed off by the Product Manager, but they’re booked back to back this week
• The community file or plug-in you use has disappeared
• The icons you’re using were free, but now require a commercial license

It can be overwhelming or daunting when these happen in the moment, but by anticipating their occurrence you can plan around them. Keep Calm, and Carry On.

It’s worth mentioning that not every single SPOF needs to be addressed. Some events happen so rarely, that it isn’t worth spending effort on a strategy.

Using the previous examples: I’d adjust our process to avoid a bottleneck with Product Manager sign-off, but I wouldn’t duplicate designs from Figma to Sketch in case they go offline.

Strike that balance between working “loose and fast” and “gatekeeping everything.” There are no hard and fast rules, but you’ll want to instill the ability for your team to choose responsibly. Sometimes you’ll want to stick to protocol, and other times you’ll want to break it.

Takeaway: identify bottlenecks or high dependencies in your design team, and carefully choose which areas to provide redundancy or a workaround.

Summary

DesignOps is still growing and is still relatively new, but we can learn and leverage parallels from the sister discipline of DevOps:

• Cattle and not pets—designs are meant to be disposable
• Documentation—keep aligned, and foster improvement
• Modular artefacts and processes—remain focused on the outcomes
• Anticipate SPOF—identify bottlenecks, dependencies, then plan for it

Using these principles, you’ll be surprised how much more capable your team becomes.

Liked this? Follow me, read Chuck’s about page, or become a Medium member to support me writing more (and support other writers, too!).