Summary
The design system's governance model outlines the decisions, steps and collaborative processes involved in the creation, re-usage, modification and deprecation of system components (either core or project one-offs). It also sets clear collaboration guidelines that will enable teams to actively contribute to the system.
See the preliminary Governance Model diagram (pictured below)
Objectives
1. Validate the high-level paths and processes involved in the creation of components
From strategizing and ideating the component need until its release and deployment and ownership beyond.
Walk through the model and validate.
See Figma for the living process model.
Former versions
v1: F34574303
v2.1: F34590165 (emphasized Hybrid model, “one-off component path clarification”)
Outcomes
- Present & discuss at designer workshop
- Bring our ideas and a refined model to the dev summit next.
Both presentations have seen interest and mostly asked for refinements: High-level like ensuring hybrid model for driver being either Product feature team/volunteer or Design System team or what's a one-off component T266687
Next steps
- Bring model to project managers/owners for feedback, probably in Product Saloon
- To be documented and shared in DS Team public-facing docs, like contribution guidelines and mediawiki.org,
2. Align on the initial model's guiding principles
The following guiding principles were developed and followed during the creation of the initial model:
- Transparency: Tasks status and progress is clearly shared and made accessible to all stakeholders. Gatekeeping, development, design and product decisions are made in the open.
- Enablement rather than enforcement: System consumers are considered contributors, and should be empowered by the core team to make decisions and own parts of the system. Product teams have a level of choice and impact on the system (e.g. suggesting components or variants, suggesting fixes or enhancements, or providing feedback for the governance model itself).
- Knowledge sharing rather than knowledge silo: Contributors should have support and access to resources that allows them to understand and influence the system's workflows, methodologies, standards and infrastructure.
Outcomes
- Present & discuss at designer workshop
- Undisputed support at Designer Workshop
3. Identify and settle on decision-making steps for DACI assignment later
Identify & define all decision-making steps to assign in close exchange with stakeholders and leadership so-called DACI (Driver, Approver, Consulted, Informed) roles and responsibilities in the aftermath of developer summit.
See Product Department DACI & Atlassian documentation on the DACI model
Associated artifact: team working DACI document
Outcomes
- Present & discuss at designer workshop
- Refine responsibilities and role identifications based on feedback
- Bring our ideas and a refined model to the dev summit next.
Next steps
- Assign DACI steps roles & responsibilities team-internally and evaluate with management, planned by September 2020
Decisions
**The governance model for component addition has been presented in both, the designer workshop and the developer summit and has received general positive feedback and no objections. Since then we've modified it based on detailed questions and will continue to do so. Lastly, we agreed to further reach out to product owners for further feedback before sharing it out publicly.
The guiding principles will be added as general library principles.
The DACI matrix is still in the works (planned for September 2021) and will be further discussed internally. It will be aligned to other Foundation Product teams' DACIs and lastly shared publicly as well.