This is good from the perspective of empowering teams with freedom of problem solving, but I fundamentally disagree it contributes to cohesive user experiences. The value of design systems is not only in accelerating the product design and development process but to ensure users don’t have to learn new Ui patterns or ways to achieve a goal at every module / view / page they encounter. Today’s products are highly fragmented due to this product trio bottom up empowerment which doesn’t account for what happen before of after in the user journey.
I think the elements you suggest are valuable but introduce issues in the end user experience (the most important thing) if not paired with review processes and cross team alignment… then why not encoding that alignment in standardised UX?
The premise of this article is that teams will do what they have to to unblock themselves. Design systems at scale become increasingly slower and harder to maintain, especially those with highly opinionated components.
When a feature team needs a new prop added to an existing component, the design system team becomes a bottle neck. I see this time and time again.
So undoubtedly the feature team will hack the component or build a completely custom one.
What tends to scale well is providing highly flexible components that contain non negotiables baked in. Such as color and box shadow.
The mindset that, “The design system should provide everything for the feature teams and everyone must adhere” has proven to be a fallacy. It just doesn’t work.
So give teams primitives and detailed guidelines they can follow on top of core components.
The premise proves my point. We are fixated with the idea of shipping fast and solving local problems as a higher imperative of delivering a cohesive user experience.
This happens only in software.
When constructing a building or assembling a physical product that was designed and engineered with specific intent, function and user flow, you don’t have teams just going about solving each floor / part the way they want.
Apple wouldn’t be what it is and wouldn’t offer it’s crisp UX across all OSs if it allowed each team to reinvent patterns at every release just because they need to ship urgently.
This is good from the perspective of empowering teams with freedom of problem solving, but I fundamentally disagree it contributes to cohesive user experiences. The value of design systems is not only in accelerating the product design and development process but to ensure users don’t have to learn new Ui patterns or ways to achieve a goal at every module / view / page they encounter. Today’s products are highly fragmented due to this product trio bottom up empowerment which doesn’t account for what happen before of after in the user journey.
I think the elements you suggest are valuable but introduce issues in the end user experience (the most important thing) if not paired with review processes and cross team alignment… then why not encoding that alignment in standardised UX?
The premise of this article is that teams will do what they have to to unblock themselves. Design systems at scale become increasingly slower and harder to maintain, especially those with highly opinionated components.
When a feature team needs a new prop added to an existing component, the design system team becomes a bottle neck. I see this time and time again.
So undoubtedly the feature team will hack the component or build a completely custom one.
What tends to scale well is providing highly flexible components that contain non negotiables baked in. Such as color and box shadow.
The mindset that, “The design system should provide everything for the feature teams and everyone must adhere” has proven to be a fallacy. It just doesn’t work.
So give teams primitives and detailed guidelines they can follow on top of core components.
The premise proves my point. We are fixated with the idea of shipping fast and solving local problems as a higher imperative of delivering a cohesive user experience.
This happens only in software.
When constructing a building or assembling a physical product that was designed and engineered with specific intent, function and user flow, you don’t have teams just going about solving each floor / part the way they want.
Apple wouldn’t be what it is and wouldn’t offer it’s crisp UX across all OSs if it allowed each team to reinvent patterns at every release just because they need to ship urgently.
Hey if you have a solve for this at scale happy to hear you :) this has not been my experience at Microsoft and Amazon
Sorry but Amazon never seemed to care about consistent Ui across touch points, nor a polished UX…
Nevertheless, thanks for the thoughts in the article and for engaging with my comments.
Thanks 😊