3 ms·

I don't see anything very unique looking here. I think they should have just gone with an off-the-shelf library.

marpstar 4y ago
I find myself asking why this is so common. I guess this is welcome because it's based on something other than React? My last employer (or the company that acquired them, rather) had a team of ~8 working on a design system/component library , trying to encourage adoption across 5+ disparate apps. Our app used Angular. They used React for their implementation. No consideration for mobile whatsoever. While I understand the desire for consistency in UX (so that it's harder to tell 3/5 products were acquisitions...), for a company that was so focused on "becoming cash-flow positive" they seemed to have no qualms about reinventing the wheel in the UX space.
- bradhe 4y ago
  I think you inadvertently hit the nail on the head here. UX teams looooove to geek out about design systems. If leadership doesn’t understand design (which, let’s face it, they typically understand less than software engineering) the UX folks will get to run wild on this project. Couple that with the fact that in 2023 “good design” has a strong center of gravity and you end up with tons of these “systems” that look the same. And, by the way, most of these systems can’t be used outside the context of authoring teams’ apps anyway because there are tons of little specific integration points that aren’t included in the system itself!
KronisLV 4y ago
> I think they should have just gone with an off-the-shelf library. This is typically not the case in larger orgs with products that need a consistent, unique feel and branding - that's why you see so many design frameworks popping up. Or sometimes you just want components for a particular tech stack (though you could integrate one of the existing ones with your JS/TS codebase, too), which is also what HashiCorp has done here (components for Ember.js). However for smaller teams I don't think that this approach makes much sense - I've seen 5 person teams spend time on creating their own component library when it felt a lot like bikeshedding, when there was actual functionality that needed to be implemented first. For most out there, just grab Bootstrap, or something specific to your front end framework/library like PrimeVue/PrimeNg/PrimeReact and first make it work, then consider customizing it. Then again, you don't see many companies out there with products that look like they're out of a Bootstrap tutorial, so go figure. I've actually heard people disliking fonts like Open Sans as well because of how common they are - seems like many want to set themselves apart. Not sure how much of a worthy goal it is, there's nothing wrong with software that works but looks a bit boring (as long as the UX is great).

I find myself asking why this is so common. I guess this is welcome because it's based on something other than React? My last employer (or the company that acquired them, rather) had a team of ~8 working on a design system/component library , trying to encourage adoption across 5+ disparate apps. Our app used Angular. They used React for their implementation. No consideration for mobile whatsoever. While I understand the desire for consistency in UX (so that it's harder to tell 3/5 products were acquisitions...), for a company that was so focused on "becoming cash-flow positive" they seemed to have no qualms about reinventing the wheel in the UX space.

bradhe 4y ago
I think you inadvertently hit the nail on the head here. UX teams looooove to geek out about design systems. If leadership doesn’t understand design (which, let’s face it, they typically understand less than software engineering) the UX folks will get to run wild on this project. Couple that with the fact that in 2023 “good design” has a strong center of gravity and you end up with tons of these “systems” that look the same. And, by the way, most of these systems can’t be used outside the context of authoring teams’ apps anyway because there are tons of little specific integration points that aren’t included in the system itself!

KronisLV 4y ago

> I think they should have just gone with an off-the-shelf library. This is typically not the case in larger orgs with products that need a consistent, unique feel and branding - that's why you see so many design frameworks popping up. Or sometimes you just want components for a particular tech stack (though you could integrate one of the existing ones with your JS/TS codebase, too), which is also what HashiCorp has done here (components for Ember.js). However for smaller teams I don't think that this approach makes much sense - I've seen 5 person teams spend time on creating their own component library when it felt a lot like bikeshedding, when there was actual functionality that needed to be implemented first. For most out there, just grab Bootstrap, or something specific to your front end framework/library like PrimeVue/PrimeNg/PrimeReact and first make it work, then consider customizing it. Then again, you don't see many companies out there with products that look like they're out of a Bootstrap tutorial, so go figure. I've actually heard people disliking fonts like Open Sans as well because of how common they are - seems like many want to set themselves apart. Not sure how much of a worthy goal it is, there's nothing wrong with software that works but looks a bit boring (as long as the UX is great).