DesignOps at early stage startups

With Laura Summers — User experience researcher, designer & front-end developer.

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

Hahaha. This is a funny one because as we were discussing earlier, the jury is still out for me on the term “DesignOps”. I’m a bit allergic to jargon, and tech is infamous for over-complicating already complex ideas with buzzwords.

That said, it feels like there is an evolution in our ways of thinking about and tooling design process, and this change is probably what DesignOps is trying to describe. We are looking at a macro level: at the meta-process and the meta-problems, for ways to optimise, automate and prescribe best practice.

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 don’t think it was any single tipping point, but rather a bunch of paper cuts that got more and more annoying over time. I’ve been working in startups for over 5 years now, and as anyone in this sector will tell you, startup is often just code for “rather disorganised, poorly funded small business” (Sounds alot less sexy that way, hun!?).

So the paper cuts were things like seeing existing design work that was really beautiful and fleshed out, but so far in advance of the development work and feature scoping as to be pretty much an act of imagination… Or seeing design be totally hidden away and siloed with one or two designers, rather than shared as a collaborative process with development and leadership… Or seeing design changes take days or weeks when it should just be a shared decision (e.g. we’re using time stamp not a date stamp, but let’s not update those 50 design mockups).

A tool which really (dare I say it) operationalised my relationship with both design and development is the living style guide. If you’re unfamiliar with this concept, it’s a style guide which is generated directly from your app code. You often need to add documentation and notes, but the core idea is to have a style guide which hooks directly into your production code, and is updated as the live product is updated.

Styleguidist for React is the library I have worked with most deeply. This tool can be viewed not just as visual and interactive documentation, but as a way to encourage organisational best practice, in this case component-driven design and development.

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

One issue I often see working in smaller companies and startups (although not unique to this environment) is new design work introducing unintended design inconsistencies. That could be inconsistency like how much padding is assigned to the button, or inconsistency in spacing for the vertical rhythm of the page, or more subtle things like a slightly different font weight (or more perniciously what looks like a different font weight but actually isn’t due to the vagaries of anti-aliasing.) This problem is why having a living style guide & component library is so important in my opinion: having that reference point where designers and developers agree “this is the correct way for this component to look & behave”.

That reference point gives developers implementing new UI permission to ignore most of those unintended design inconsistencies and reduces the burden of documentation and endless annotations for designers. If the existing component looks whack in the new UI, then it sparks the need for more design thinking either on that component or to explore the need for a new component.

Additionally, having this shared reference point means that we can be lighter and less precious about design artefacts. Honestly, I usually try and spend as little time as possible in design tools like Sketch and Photoshop these days. I try and hack together design changes in the browser, or demonstrate one UI view with a design but then describe the rest of the scope in a GitHub ticket with text documentation.

If there’s one big benefit to me working in small design teams (usually only myself, sometimes with one other designer), it’s giving myself permission to get a bit messy and not worrying whether each feature goes through exactly the same process. What’s more important is whether you’re having the right design conversations with your team, not so much how you got there.

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

Ha! This is such a dog’s breakfast. Some places I’ve worked have had a reasonably mature design tooling set, others have been pretty much starting from scratch in terms of both design tools and process.

One tool I tried in my current contract and wanted to love (but couldn’t) was Abstract. It’s a version management tool for Sketch based on Git - and while it’s a great idea in theory, the app just wasn’t there in terms of stability and feature set. It’s intended to provide a single point of truth for “the latest version of the design source file” - a problem which plagues most design teams, especially distributed or remote teams.

There were some weird bugs I was experiencing with symbols (they’d mysteriously disappear one commit to the next) but more importantly there was no granularity of control in terms of the commit. As someone who uses Git on a daily basis, it was super annoying not being able to discard unwanted changes and keep wanted changes. So if for instance you stray click and move an object by accident, you can’t discard that change, you have to go back and meticulously move the object back to where it’s supposed to be. Bleugh.

Without writing a novel on tooling, the other thing I will say is that when joining a team with no design process, I’m cautious about introducing too many tools and processes and try to do it one thing at a time. It’s important to be empathetic to the time and cognitive load that each new tool or process adds to the team, especially if your teammates aren’t design-inclined, and move accordingly.

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

To be honest, my colleague and friend Milly Schmidt has probably been the most influential on my growth and thinking in this domain! One thing that’s great about Milly is that she has helped me get more confident in translating my gut feelings about how things are, to legitimate discussions and action points. Often you’ll have a feeling that “this is not right” or “this feels jank as a process”, but it’s not always easy to give yourself permission to go ahead and put it out there.

Also, Mark Dalgleish has been pivotal to introducing the react-sketchapp and html-sketchapp libraries into the Melbourne ecosystem through his talks and work at SEEK.

Jeremy Keith, Jarrod Spool, Brad Frost are a few designers I follow.

And a few standout articles on medium include:

• Sketching in the browser
• Design ops for design systems
• DesignOps at Airbnb

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

I believe that most products are successful more due to of external factors like market readiness and political and economic climate than as a result of the factors a company controls (like product quality, design, development, culture, etc). It’s probably a bit of a depressing idea, but it helps me chill out and not take myself too seriously.

An addendum to this belief is that our cult of personality and hero worship of unicorn founders (Zuck, Dorsey, Musk, Bezos, Kalanick, etc) is insanely overblown in my opinion. We need to get serious about holding founders to account for the consequences of their actions both for their employees and more broadly in the markets they play in.