DesignOps at Tundra

With Adam Brock — Senior Front End Developer at Tundra.

---

In your own terms, at a high level, how do you define or think about “DesignOps”?

Co-running DesignOps Melbourne with Ch’an, our standard line is that “we don’t know either” - but of course, that’s not quite true.

I see DesignOps as the next step of evolution, not unlike the X-Men. Through a mutation of design, tooling and management (ideally, a lack of management) that allows designers to spend more time doing the things they enjoy (actually designing things), and less time doing things that would be better off being done by a computer or not done at all (most meetings).

Thanks to the success of DevOps, having a term like DesignOps really legitimises the important work that we know needs to be done in order to make our jobs better.

I also believe this role really requires someone who is a bit of a Maverick on some level. If you’re not naturally inclined to be a Maverick or go rogue, I hope that being a part of a group like DesignOps Melbourne can at least give you the excuse of “DesignOps made me do it”.

What was the tipping point for you, where you realised this was something that was required and beneficial in your team/company? Was there anything that made you take notice and decide to venture down this DesignOps path? Or any early wins that made you pursue it further?

The inception of it for me was deciding to leave my “design” role behind and pursue a full time career in development. This wasn’t because I stopped enjoying design; it was actually the opposite, as I could see that design and development were going to merge closer together over time. Once I realised that I was personally spending more time actually designing things straight in code and the browser, and seeing that it was not only faster, but more of a robust way to design in such a weird flexible medium, I figured that there was little chance we weren’t going to end up there as the default eventually.

This was right before the post-PSD era was written about by Brad Frost, which I remember lots of people in my agency laughing off at the time - yet here we are a few years later, and I would say we have mostly arrived. It seems crazy to still be using print design and photo editing tools when we have such great screen design tools that were purpose built for this medium.

I was first introduced to having a design system (or “style guide” as we called it back then) back in 2014, when I was working on the re-build of the Honda website. We actually had it printed out on the wall in our work area so it was something constantly visible to everyone. It had everything from colour palettes, typography, vertical spacing and some individual components. In hindsight, it was a much less advanced version of what we’re doing now, but the idea of it was enough to make me see this was the right direction.

The tipping point for me was being brought into work on “legacy” (1-2 year old) projects, which were already becoming visually inconsistent and making changes to CSS files in a way that was analogous to playing a game of “Jenga” in your code editor. No one really owning either side of it, every task was taking way too long because the situation resulted in more design and development being piled on top, re-thinking everything from the ground up, instead of re-using what we already had in place. Basically, everyone would be afraid to re-use or edit the existing styles, so the CSS file would continually just be appended to with new styles (usually coming up with more creative and specific ways of overriding previous styles to be more !important).

So, one of the first steps for me was getting the design and development teams metaphorically, or literally sitting on each other’s laps while the work is happening. Too often: design, development, copy, production and every other team just works away in their own world, which can lead to everyone becoming very protective of their precious work and vilifying the other parts of the team in their minds whenever some feedback or questions would come through about their work.

As far as the actual work goes, design systems were my first and longest lasting love in this crossover between design and development. The feeling of jumping onto a project, and having the chance to consolidate 54 shades of a brand’s primary colour and turn that into code that solidifies it down to a single value that can be abstracted across an entire codebase, and kept in sync with a design system frontend was awesome - then applying that to layout, typography, icons, components, theming etc - you can see the benefits immediately.

A couple of years ago, we started getting more serious about using real content as part of the design process - so for example I would output JSON data from the production database for the designers to import into Sketch to roll out a grid of “cards” or rows based on the data that would actually be used when the design was built out.

How does DesignOps effect the efficiency/effectiveness of your day-to-day operations in the team as a whole, and more specifically in the design team? Where have you noticed the most improvements? (ie. Speed of work, frictionless of handovers, happiness of employees, quality/consistency of work etc).

For us, the two most noticeable areas of improvement would be speed and quality/consistency of the work. Working in an agency, these are very critical for our day to day operations in the studio.

By making design systems a core part of any design and build, the speed of development and consistency of the design in the final product have both become way better. We don’t spend time solving exactly the same boring problems over and over again in the design or development stage, which allows us to spend more time on interesting problems or that extra 10% that makes something really great.

One real world example of this was the topic of my first talk I gave at the DesignOps Melbourne meetup, which involved developing our own tool for making our email builds 70x faster than when we started. This and other examples just like it in our agency continues to prove in a very tangible way the benefits of investing time and thought in DesignOps.

What does the tooling and flow/process look like for your design team (and development team - if applicable)?

Our designers are currently using Sketch as their main design tool, which they usually upload to InVision for feedback, and finally exporting to Zeplin for development “handover” (which I really don’t like).

Having said that, we’ve recently been giving Figma a serious test drive in our design and development team, which I’m already personally on board for going all-in on, as it will replace Sketch, InVision and Zeplin for us.

The designers love it, the built-in development handover is really nice (speaking personally) and having all of the feedback built into the project file is a huge benefit for streamlining the often fragmented review/approvals process. Having version control built in, and not having to worry about file management on our server is another huge plus. I really love that it’s built on web technologies, as it just re-enforces that this is where everything is heading.

Our design/development process actually involves getting the design into code and the browser as early as possible, rather than spending too long falling into the trap of finessing it into a fantasy solution in a design tool using fake content. We write scripts, build tools and have some defined patterns that allow us to spend more time actually building things rather than getting decision fatigue or get stuck trying to solve the same problems over and over again in the operational aspects of development.

What resources or influences have had the most impact on the way you approach your day to day operations in the DesignOps space? (This could be other companies, books, podcasts, articles, talks etc).

This industry we work in is weird, because I’ve found that there really aren’t many heroes to look up to, in a Michael Jordan or Steve Jobs sense. I’m sure this is partly due to how relatively new it is, but it seems to essentially be a group of people who fell into their role somehow or another, and are now all looking to each other and Medium posts to try and figure out what’s going on or what they should be doing, rather than dedicating much of their own time to thinking about it. So, I’ve almost stopped paying attention to lots of the noise a while ago, and don’t read very much news or technology related publications.

One company I will shout out to as one of the few “heroes” that we do have is Airbnb. I think the work they’re doing, in the DesignOps space and others, is really setting a good standard for everyone else to aspire to.

I think there are certainly many other fields that do have heroes which are more influential to me than any of our own, such as architects, chefs, hip hop artists, CEOs, designers (usually non-digital).

As far as specifics go, I’ve listed a bunch in our DesignOps resources page on this site. My favorites on that page are all of the books and documentaries. You might ask (as others have asked me), “Could you please explain what any of those documentaries have to do with DesignOps?”, to which I would say, you can learn more from seeing how South Park makes an episode from nothing to being aired in 6 days than you can from 100 Medium articles about “the one thing you must to know right now about design tools”.

To call out some of the specific books I recommended, here’s some more detail:

Creativity, Inc.

I recently re-read this book, which is written by Ed Catmull, the co-founder of Pixar animation studios. He’s spent the last 20+ years of his life on a mission to discover the invisible forces that conspire to destroy creativity. Every page is filled with true wisdom from a man who has seen it all, and actively works to make things better for his teams. It’s the best book I’ve read about how to think about creating an environment that actually supports their creative employees to do great work.

Zero to One

Another very influential book for me, written by Peter Thiel, the co-founder of PayPal. It’s really waging war on conventional thinking, and a culture that has become complacent with simply copying each other with very small improvements. We should be aiming to come up with something brand new (going from 0 to 1) instead of taking something and making it slightly better (going from 1 to n).

Powerful

Newer book that I’ve read twice, written by Patty McCord, the Chief Talent Officier at Netflix. Again, she poses some unconventional ideas that have been very successful at her company. She is firing on all cylinders against things we’ve taken for granted as being “good” and true, but are actually wrong and false. For example, she hates the idea of “empowerment”, because everyone who walks into the company already has power, and by saying we need to empower employees is a sign that the management structure is not conducive to letting them keep their power.

What is something you believe, that most other people would think is crazy?

I have lots of these, but the one seemingly contrarian truth I have been coming back to recently is:

It’s safer to take risks than it is to play it “safe”.

It’s amusing to me that we still have campaigns and ideas being designed by committee, to ensure that whatever they’re creating will be liked by everyone. What you end up with is the average opinion of the average person, which of course, results in an average output.

When you apply this at scale, and have all of these people copying what their competitors are doing and putting their own average take on it, you end up with almost everything being the same.

To me, it seems obvious that taking this approach is actually riskier than doing something different. If the safe option is being average, the same as everyone else, with your risk of being forgotten (or ignored) sitting at roughly 100%, then it seems like doing something different and having a chance of being better (and noticed) is far less risky than playing it safe.

Why would you try to create something average and “safe” that half your audience might “like” (at best), instead of creating something that you genuinely think is cool, which will result in lots of people hating it (that’s a good thing), but a small portion of them loving it?