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