Also, I am wondering: looks like there is https://spectrum.adobe.com. What is the purpose of Spectrum without an implementation like this? Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
Also, I am wondering: looks like there is https://spectrum.adobe.com. What is the purpose of Spectrum without an implementation like this? Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
While the pieces of design systems make sense in and of themselves (you can argue for a clearer, easier to read font), I think a lot of bullshit gets dragged in along with people wanting to embrace "design systems" for the sake of doing it, or because it looks good on a resume "X designer built a design system at Y company". If I were to think even more cynically than usual, you can think of design systems as bundles of components.
> What is the purpose of Spectrum without an implementation like this? > Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
Cynically -- marketing for adobe, and some easy press, internally maybe a deliverable for the design/frontend teams that was on the roadmap for this quarter. Less cynically -- other companies can choose to use Adobe's design system instead of creating their own, also everyone benefits if Adobe has done stuff that goes above and beyond the usual bundle-of-components (ex. their React Aria[0] effort).
From what I've seen, design system teams at MegaCorps are usually at most 10 people, in an org of thousands of internal engineers and external contractors that may be consuming their product.
Discoverability is pretty important, otherwise engineers will try and get around the guard rails your system imposes.
Also yeah, it helps for recruiting frontend developers.
In the ideal situation the team of 10 produces the components/style decisions and the resulting components that the whole company uses and then you never see a weirdly styled/non-standard part of their offerings every again. In practice, it can get really messy as that team can become a bottleneck for various parts of the org trying to move in very different directions and management gets difficult.
In the near future, once one of the design tools really nails generating (probably React) components that devs don't hate, I think it will be much easier for the teams of UX/Design and UI (devs putting react components on pages and dealing with technical feasibility) to work together. It feels like design has only recently started to receive the automation/tooling love that devs have (tools that intelligently manage iteration, sharing designs, "branches", etc), so once someone bridges that gap hopefully tooling gets rid of some back and forth.
Please feel free to amend/improve my definition of design systems above -- the term has meant so much over the years inside and out of the strict boundaries of pure graphic design -- I am not a designer/UX person by trade (I do it only when there is literally no one else), but write frontend code and have had some friends bellyache to me recently about trying to get design systems implemented in a local mid-large size company with a startup-like environment.