-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs([DST-449]): add values and principles to documentation (#3957)
- Loading branch information
Showing
3 changed files
with
66 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
"@marigold/docs": patch | ||
--- | ||
|
||
[DST-449]docs: add values and principles to documentation |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
--- | ||
title: Governance values and principles | ||
caption: Our governance values and principles on how we make decisions in the design system. | ||
order: 7 | ||
badge: new | ||
--- | ||
|
||
“How does the design system team make decisions?” | ||
”How does the design system team prioritise?” | ||
”What can I use as a guide when I have a request for the design system team?” | ||
|
||
We have been asked these questions many times by our stakeholders and they have motivated us to find ways to provide more transparency. So we worked on a framework which we and our stakeholders can use as a guide to become more confident in dealing with the design system.The process of how we handle changes and additions is written down in the page [Governance process](/introduction/governance-process). | ||
|
||
Governance Values are meaningful key terms that help ensure a consistent and solid decision-making process. They serve as a compass during complex strategic phases, anchor us to our principles and ensure that we can evaluate and critique our work in a positive way. | ||
|
||
Governance Principles are a set of defined rules that enables us, the design system team, to make decisions in accordance with our defined values. They serve as a framework for how to act in certain situations and enable us to fulfill the defined product values. | ||
|
||
## Our values and principles | ||
|
||
### Transparency | ||
|
||
For us, transparency means that we communicate openly, honestly and clearly about the decisions we have made and our intentions. Future versions and changes to Marigold are also communicated openly. | ||
If we say no to something, we will always offer alternative solutions that help the teams concerned to make the best possible progress with their work. | ||
|
||
### Predictability | ||
|
||
We provide stakeholders with a way to follow our roadmap and our decision-making guidelines so that they can better predict what to expect from future decisions and releases. | ||
|
||
Our approach to prioritization is guided by the company backlog, ensuring our effort adds value and is in harmony with the overarching goals of the company. | ||
|
||
### Empathy | ||
|
||
We will always empathise with our users' situations, not leave them alone with their complications and offer the best possible solutions. | ||
|
||
By establishing and transparently communicating our boundaries, we enable other teams to set realistic expectations. This proactive approach significantly reduces the potential for misunderstandings, fostering a more collaborative and understanding work environment. | ||
|
||
### Think holistically | ||
|
||
Prefer holistic solutions over individual ones to ensure versatility across multiple teams. | ||
Good decisions require not just logic, but real-world evidence. | ||
|
||
Gathering evidence means doing research, starting with the basics and gathering information from other design systems and adjusting them to our needs. Changes should be based on clear user need, not a gut feeling. | ||
|
||
### Sustainability | ||
|
||
We prioritise the long-term sustainability of our design system, ensuring that it remains relevant and effective far into the future. We should evaluate and evolve the design system over time, aim to make decisions that will be long-lasting and won't require revision in the future. | ||
|
||
### Embrace risks and failure | ||
|
||
Imperfect decisions are ok. Learn from your mistakes. Make the best decision you can right now and then iterate over time. | ||
|
||
Failure is not seen as a setback but as an opportunity for growth and learning. We strive to learn from both our successes and our failures and use this knowledge to develop and improve our design system over time. | ||
|
||
### Keep it boring | ||
|
||
The design system is boring—that is, it’s not meant to contain wild or untested ideas, even if they’re compelling or seem to be working well in a single product. | ||
|
||
Start with the simplest possible design, knowing that it will evolve and become more sophisticated in later iterations. Do not add in early functionality at this stage to keep it as bare bones as possible. | ||
|
||
We avoid unnecessary complexity or novelty that could introduce risk or instability. By keeping it “boring”, we ensure that our design system works predictably and consistently for users and stakeholders. |