Is DesignOps making design... worse?

  • DesignOps comes from the intention to diffuse personal responsibility/decision making by making a craft into a system.
    • Its primary function is to supplant in person management by “coding in” the decisions rather than making them “manually”
    • Like its progenitor, DevOps, it suffers from the same delusion (that it can be separated out, ontologically and logistically) from the other functions of development (namely: building things for people).
    • By separating out the “ops” from the “design” teams delegate the responsibility of “being organised” to a team/person who “owns” the structure of the system.
      1. These things ensue:

      2. The practice of DesignOps becomes a fiefdom, a safe space away from all the “heavy” planning and structure of the customer-facing design teams, and therefore amasses complex governance issues, prioritisation issues, and bloat
      3. Those not in the DesignOps cabal lose sight of the system and need to then be re-educated, adding an overall layer of communication and management previously not needed
      4. The Design System, now disconnected from its purpose, begins to be less and less suitable for its intended purpose and now requires a formal change management process whenever it needs to be altered to better suit its purpose
      5. The design process for a new page now becomes a matter of assembling building blocks, for better or worse. If the cost of adding a new block is too high, the designer will simply use a less suitable one, causing eventual degradation of the overall user experience
      6. Positives:
        • The app becomes more visually consistent - great for helping users understand the system and context, wayfind etc.
        • Fewer bugs are introduced by “rolling your own”
        • Massive efficiency created by reuse/reduction of duplication/DRY principles
        • The system is self-documenting an easy to onboard new designers/developers into (in theory)
        • A shared vocabulary between design and dev helps them agree on approaches faster
        • Limited options prevent bikeshedding or unnecessary waste by limiting cognitive overload
        • Fewer or no unintended design variations are introduced (e.g. similar but not quite the same implementation of a button)
      7. Negatives:
        • The app becomes visually boring
        • Bugs are introduced by poor implementation of building blocks
        • Bugs at the building block layer occur in more instances and affect more users
        • Fewer “happy accidents” can happen due to more guardrails and less room for experimentation
        • It’s harder to introduce intentional design variations, which start feeling like “rule breaking”
        • Consistency is good, but sometimes you need to add design friction (type, color, or size inconsistencies) in order to slow down the user, signal a change in use, or otherwise flag a new landscape... DesignOps practices can actively resist or prevent these kinds of design choices.