The design system craze is picking a lot of steam lately. AirBnB, salesforce, Mailchimp, Material Design. Are most people using them are are people still sticking to a good old css framework and that it.
It very much depends on the project's requirements and the deadlines and what I think is the best option for each project. Just like frameworks, libraries and other tools it varies from project to project, although I admit I tend to keep the same parts of the stack I used for previous projects.
I use design frameworks to prototype and quickly release projects. Bootstrap and Material Design make it dead simple to create professional looking pages.
I use design systems to help manage my projects. Concepts like Atomic design, or finer nuances like Airbnb's methodology for class descriptors. It allows my team and I to organize our styles efficiently and effectively, and it gives a greater insight into the creation of styles (resulting in less refactoring over time).
At the end of the day it's hard not to bolt a Bootstrap Grid onto a project as a scaffold. It makes the CSS process more about colors and type than about the box model.
Design systems have been a thing for years, it's mostly the terminology getting more traction now. Frameworks emerged for a lot of reasons but a key one was people wanted repeatable ways to produce their designs, particularly at scale.
To look at it another way - if you're using a framework without your own specific design, you're basically using someone else's design system. That's fine for any project or business where design is not a key business advantage (eg. maybe it doesn't matter if your website looks like everyone else's because your business is selling a product, not the UI itself). Or a personal project that just needs a UI that works - use whatever you can build quickly.
But anyway, as a literal answer - yes, at work we use a design system.
I am against "Design Systems" in the idea that they come with pre-baked code and pre-existing styles they expect you to use classes to apply presentationally, resulting in the same code-bloat and double-finger to accessibility as ignorant bloated half-tweet narrishkeit frameworks.
It's just been my experience that most everything code-wise that comes pre-cooked is half-baked!
EVEN when conceptually they are filled with good ideas -- like Material Design's approach to "flat plus". It's the implementation that leaves me walking the other way.
JUST like with the dipshit trash that are front-end frameworks, that at least for HTML/CSS result in writing two to ten times the markup needed, using JavaScript to do CSS' bloody job, and as much custom CSS in most "completed" websites as you'd have WITHOUT the stupid malfing framework idiocy! Even BEST CASE the MOST you get out of it is shifting the total amount of code out of the CSS and into the HTML -- instead of fixing bloat you just shuffle it around; and at what cost? Oh, that's right, telling separation of presentation from content to go stuff it!
But then I'm a content oriented developer, meaning that to me content and functionality dictates markup, content + markup + device capabilities dictates layout and style. NOT the other way around. Starting out with what it's going to look like and slopping in classes to say WHAT it looks like instead of WHY? 100% grade A farm fresh DERP.
Hence why HTML/CSS frameworks are nothing more than going full Pakled. You never go full Pakled.
Tommy Hodgins
CSS & Element Queries
I understand what "design systems" are trying to accomplish, as well as "CSS frameworks", and while I agree with the principles, and tout the advantages of them to others, I don't use them myself for my own projects. Or at least I don't use the systems and frameworks of others for the projects I work on.
The idea of a design system is to define a design language that can scale across the many different layouts and design challenges you might face and provides you a way to 'solve' these challenges in a consistent way that has integrity over the whole project. I do this, but I see it as my job to figure out and define what this means for each project, rather to approach a project with a "design system" in hand and apply it to the project. For me, the design system you come up with is kind of like what a "brand guide" is for graphic design. It's a great document to produce yourself, and then stick to.
As for CSS frameworks, that is kind of like one application of a design system. This is the design language translated into the CSS language, but you may also be using the same design system with other programming languages, or other apps (like Sketch or Illustrator) which don't use CSS, but would have 'frameworks' made out of other things that weren't CSS to accomplish the same task that the CSS framework provides for you in CSS. I think the best CSS framework is the one you create after solving a problem from scratch 4-5 times. Once you have solved the same problem a number of times, you finally understand how to abstract that nicely and write a helper (your framework) that ensures that every time you solve that challenge in the future, you are doing it in a consistent way.