Document principles

principles.md

@@ -0,0 +1,39 @@
+# Principles
+
+### Communication
+
+Design systems provide a vocabulary between design and engineering, the language we use should be correct but not at the expense of providing clarity. Use words and descriptions that both designers and engineers can understand.
+
+* Be a bridge not a barrier. Use vocabulary that provides meaning to both designers and engineers.
+* Choose language that provides mutual understanding between engineering and design over specificity.
+* Support new vocabulary with descriptions and examples.
+* Be consistent in the application of vocabulary in written and verbal communication to reinforce understandings.
+* Articulate what you are aiming to achieve as well as what you are not doing.
+
+### Judgment
+
+There's often more than one way to do things, and there aren't always best-practice examples to follow. Despite this we still need to make decisions and keep moving forward. To deal with an uncertain future and still move forward we should have _strong opinions, weakly held_.
+
+* Make decisions that move us forward rather than halting progress due to ambiguity or difference of opinion.
+* Make decisions based on long term goals rather than this week's ship.
+* Evaluate technology by the risk they present, not just the solution they offer. High risk deserves careful consideration, low risk deserves less attention.
+* Have opinions and arguments for them, but remain open to seeing and hearing evidence that clashes with them when those opinions become wrong.
+* Prioritize solutions for people who use the system and how it serves the customers who use products built with the system.
+* Seek feedback on code review often, and more often when a solution takes you down a new path.
+* Take time to provide good code review, encompassing the above values when providing feedback.
+
+### Innovation
+
+* Treat everything as an experiment. Make small incremental steps that provide proof towards goals, or disprove them.
+* Ship often. We learn more from tangible outcomes than something that only lives as an idea.
+* Work on reducing complexity and simplifying solutions to enable us to innovate faster.
+
+### Implementation
+
+* Engineer just enough of a solution, value declarative over abstraction.
+* A little verbosity is better than clever code. Avoid implementations that reduce the ability for people to contribute.
+* Automate and abstract when repetition is a hindrance.
+* Seek feedback on implementations as often as possible.
+* Everything is a component.
+* Provide flexibility, but within the boundaries of the system.
+* Assume that people will break the rules, and provide safe ways for them to do so.