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.
      • These things ensue:

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