Design Ops

Discipline

Organising the practice of design with Design Ops

Design Ops comes out of a very concrete observation. A large share of the time spent on design does not go into designing, but into looking for a file, redoing a screen that already existed somewhere else, explaining again a decision taken three months earlier, preparing the handover to the technical teams. The more people are involved, the more time goes into tasks that add no value.

Design Ops (short for Design Operations) is the function that organises this practice. Its scope covers the tools and their shared use, the design processes and how they fit with development cycles, documentation, the onboarding of newcomers and the handoff to the technical teams. The goal stays the same everywhere: designers spend their time designing rather than administering their own practice.

Design Ops is frequently confused with the design system. The design system is its most visible piece of work, but it is only one among others, and a design system without governance or a contribution process goes out of date quickly. Applied to user research, the same logic goes by the name of Research Ops.

What is Design Ops for?

  • Standardise tools and methods, so that the work produced by some is reusable by the others
  • Reduce friction between design and development, from the handoff to the documentation of components
  • Make it easier for new people to join without starting from scratch (onboarding, access to files, naming conventions)
  • Make the design workload visible, so that requests can be estimated and decided on rather than simply endured
  • Define what is expected from a piece of design work and how it is checked, so that arguments about quality stop resting on gut feeling

Why adopt Design Ops?

  • Design Ops organises production and collaboration around design, Research Ops does the same for user research
  • Research Ops has its own infrastructure, from recruiting participants to recording permissions, through to a space where findings are centralised
  • In smaller organisations, the same person handles both
  • DevOps responds to the same drivers but leans towards tooling and automation, where Design Ops is mostly about processes

Framing a Design Ops initiative

Before starting on a workstream, you still need to know which one matters. That is what a framing canvas is for. Filled in during a workshop with the people concerned, designers, technical teams and decision-makers, it brings out the real friction rather than the friction people assume. That is where the ranking of the workstreams comes from. It covers five areas.

  1. Who we are. The profiles involved, on the design side as well as on the side of the people who decide. It also records the obstacles the latter run into, which are often missing from diagnoses carried out among designers alone.
  2. The organisation. What design contributes, how it works today, which methods are actually practised. The question is about what exists, not about what the reference documents describe.
  3. Communication. What information travels within the teams and what reaches the decision-makers (and how). Knowledge sharing and the way feedback is phrased are dealt with here.
  4. Structure. The balance between individual autonomy and shared practice. This is the most debated area in the workshop, because that line is never drawn in the same place by the people who design and the people who steer the work. It also sets out the objectives, the responsibilities and how success is recognised.
  5. Constraints. Internal rules, security, confidentiality, handling opinions and disagreements. On many projects, this part often determines what is feasible before tools are even discussed.

Frequently asked questions

A few of our case studies

Research Ops

Research Ops organises the practice of UX research within an organisation: methods, tools, recruitment, sharing user knowledge.

Read more about Research Ops

Figma

Figma is the leading collaborative design tool. Design, prototyping, design system and handoff in a SaaS that connects designers, developers and product managers.

Read more about Figma

Design system

A design system is a component library and the governance that comes with it. What sets it apart from a design kit, and when it becomes necessary.

Read more about Design system

Design Kit

The design kit, or UI kit, brings together a product's components in a design file: buttons, forms, cards, navigation, icons.

Read more about Design Kit

Design sprint

The design sprint is a format, not a method, that condenses the design thinking steps into 5 days to tackle a problem as a group.

Read more about Design sprint

Atomic design

Atomic design breaks an interface down into 5 levels: atoms, molecules, organisms, templates, pages. It's one of the reference methods behind a design system.

Read more about Atomic design

Curious to learn more about us?

Everyone talks about user experience, service design, ergonomics...
It's not always clear, and you'd like to find out, or sharpen what you already know.

Let's talk