DesignOps in 60 Seconds

Walk in to most agencies or corporate organisations 5 years ago and you’ll see a team of designers using different tools, working in different ways, and demanding creative freedom to not stifle their process.

Now as design is becoming an integral part of business, standardisation must happen. It will not limit creativity, rather it will allow designers to focus on design, and not a cacophony of tool issues. I felt compelled to give this summary to simply the issue as it’s been on an exponential rise for the last several years filling hours of talks and conferences when it should be common sense.

As I’ve said for years in a 3 second summary “DesignOps is simply called being professional”. The 1 second version? See the graph, Alignment = Success.

Thanks to Guus for the comedic diagram!

What I write below is common in the Development, Test (QA), and Product Owner world, it’s not new, we’re simply catching up.

Step 1: Tool alignment

Any design organisation or design team should be working on the same toolset. For example, Figma for design, Miro for brainstorms, Slack for communication, Google Drive for storage of files.

Step 2: Workflow alignment

Define and use a common workflow. The steps are often the same, which is some set of steps around — Research, synthesis, vision, user testing, detailed design. Jira recently came out with a process flow for designers.

Otherwise my friends in the tech sector have been telling me about Whatever it is, have a defined workflow everyone works against.

We track most design work in Jira, and link Figma files to Jira to have a completely integrated workflow. Trello or other tools work as well.

Step 3: Define Common ways of working

Define the following — this is in no way an exhaustive list, just examples.

  • Folder structure for Google Drive (or whatever you use to store files)
  • Sheets / Pages structure for Figma or other design tool. This would include how you handle components, naming colours or pages, what is complete, in-progress, etc
  • Meeting cadence
  • Naming conventions for files, templates, components

Step 4: Comment your designs

Much like developers comment their code, comment your design files — in a standard way. Design handovers have long been the bane of many designers. During many handovers, designers lose context and immediately want to waste the next month reinventing (read: making different, not better) what has been done because rationale and reasoning was not presented. For all designs, add in some version of the following

- Use case or User story
- Pros and cons of the design
- Alternate design if applicable
- Risks associated with the design
- Rationale for decisions taken

This may also be done in your tracking tool, depends on what you use.

Lastly, unless you have a team of over 50 designers, you probably don’t need someone full time for DesignOps. Hire a vendor, set up the process, then adhere and adjust as needed. Simple!

Want more on Design Entrepreneurship? Check out this ever growing list of articles and view points.

A note from UX In Plain English

We are also always interested in helping to promote quality content. If you have an article that you would like to submit to any of our publications, send us an email at with your Medium username and we will get you added as a writer.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store