DesignOps with Melissa McEwen

With Melissa McEwen — Software Consultant, Project Manager, DesignOps, Documentation Engineer, DocOps.

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

I think of DesignOps as bridging the gap between design and software, both on a technical and communications level.

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?

I’ve been working in IT for over a decade now. When I started out I was in academic IT departments where if we had a design, it was just a bunch of PSD files and often we didn’t even have the ability to work with the designer. I found myself often having to make a lot of design decisions because the PSDs didn’t have this information.

Fast forward to working at an academic design department, I had access to designers on my team, but often there were still gaps, especially once responsive design entered the picture. DesignOps became a way for me to communicate to designers what their designs would look like on the web and develop tools to streamline the process.

By the time I started working in advertising I had some pretty good tools and techniques for this. Designers love it because they can ensure that their designs look good when actually implemented. Developers love it because they spend more time developing and less time guessing. Managers love it because some of these techniques work really well for saving time and money.

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).

A good example is on one big ad project, the initial build had a very high budget but subsequent releases didn’t. We developed an automated style guide that divided the design into discrete components that we could “remix” for new pages. I wrote a little about it here.

The designers used those components to build the design and then it was pretty simple to implement on the development side. For animations we also piloted Principle. In the past the designer would just describe the animation to me or send me a video, which was a lot of guesswork and sending things back and forth. I”d be like “Is this good” and then they’d be “Oh it needs to be a little slower” and so forth. Principle provides a common language that translates well to actual development like bezier curve values.

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

I am in general Agile-skeptic but I think being “Agile” is critical here. It amazes me how many so called Agile organizations are waterfall about design. The model is the designers make the design and then deliver it to the developers who make the design into a site. One issue this often causes is performance issues. I’d get a design and there would be no consideration at all to performance - that requires designer and developer collaboration, as well as attention on the project management side to allocate time for this. That’s the reason I got into image optimization - making sure your images are the right sizes and they are fully optimized for performance makes a massive difference in site speed.

I am working more on the documentation side now and here the biggest challenge is just managing the designs itself. Like we have designs in InVision, PSDs, uploaded to Google Docs… everywhere. You know how you’ll often have design-final.psd and design-final2.psd? And then people end up building from the wrong PSD and it gets to designer review and they are like “oh no it’s the old design”? That’s what happens when you don’t have a process in this area. It’s as much a management issue as it is a technical issue. I think that gets missed in most “ops” fields that you need to have pretty good organizational and people skills to both get these processes in place and get people to adopt them.

Getting images out of these documents is another critical thing, especially when doing responsive. I’ve watched designers spend hours doing this, producing files like header-mobile.jpg header-desktop.jpg, etc. Automating processes like this as much as possible can save so much time and money.

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).

Design for Hackers was an important book but I wish there were more resources that took it further which is why I was excited to find DesignOps.

I actually read a lot of DevOps stuff like DevOps links, there is a lot to learn there.

Write The Docs, since I think technical writing and communication is also really important. Most of the open source work I do is in this area - writing documentation on image optimization for example.

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

A “crazy” thing I believe is that designs (and design related specs) are documentation and should be part of the documentation process.

Oh also accessibility is a big thing that DevOps is critical for - providing guidance for both designers and developers to make designs that are accessible and for developers to do it correctly. This is another thing “lost in the gaps” a lot and it has huge consequences.