Previous attempts had been coded or designed by a solo developer or designer in isolation and released into the wild. We had to come up with a different approach if we wanted adoption and a system that would be easy to maintain
Due to the micro-frontend architecture and the amount of discovery work needed, there was some leniency on time. However, the business would need to see a tangible proof of concept for such an endeavor before committing to it.
The key measure of our success would be in how we tackled adoption, not just execution.
I proposed we do an exercise to find out what "not to do." We brainstormed what we thought we would get from the worst approach, to its extreme; In our case it looked like a lot like a "Decision by Consensus" model. After listing what we thought would happen in a naive, and realizing that the approach would fail in our organization. We took it one further and went to the extreme in the opposite direction, intentionally arriving at another approach that we also saw failing. We figured the best approach had to be something in between.
If other teams feel that their feedback isn't valued; you could have a design system that wont be used. On the other hand, getting decisions from consensus would bog down the work, even when other teams do their research and are committed to the project; we where nowhere near that scenario either. The big question was:
