Here are some of the topics he hits on in his talk: 1. Your Sketch library is not a design system - the heart and soul of a successful design system is a collection of reusable code components that build real software applications 2. There are many technical benefits of design systems: reducing technical debt, faster and higher-quality development, reduces QA effort, potentially makes adopting new technologies faster, it’s a useful reference, and it’s a future-friendly foundation to build and iterate over for years to come 3. A design system has to be compatible with whatever technologies are used at the organization. That means creating and managing a technology-agnostic design system. 4. A design system needs to power real software applications. That means using pilot projects to ensure your design system is actually handling real-world scenarios rather than being an off-to-the-side exercise. 5. Create the design system’s UI code in a frontend workshop environment in order to quickly articulate many product scenario UI without having to build the functionality for real. 6. Create a CSS architecture for your design system that is portable and 7. Use atomic design to connect the design system components to your actual product screens 8. Components are like tools in the basement. Over time, the system should provide a healthy chunk of solutions for your products, meaning you don’t have to expend a bunch of time, energy, and effort on brand new stuff all the time. 9. With directly consumable components, you can bake in best practices into the components. That means you can build in accessibility best practices like requiring alt text for images and automatically generating the necessary id attributes. 10. Understanding how to release and deploy a design systems is critical. I highly recommend Nathan Curtis’s 6-part series on the topic.
Why not just use an in-between tech/lang/markup to create these components? Like JSON seems perfect to me as a descriptor for components (or xml), and then you can read/parse the system regardless of the tech used, and you don't need to port anything from one framework to the next hotness
I find it unfortunate that react-styleguidist doesn't show up anywhere (neither in the talk nor in the linked resources). It's interactive nature, included API parsing and so on IMO makes it much more suitable for a playground, style guide and API documentation all in one versus e.g. storybook. UPDATE: Ah, I just saw the end of the video. I think now I get it. ;)
React can be a legacy-to-modern UI tool because legacy DOM can be transformed into modern DOM - or DOM output by various server-side tech to modern DOM
Designers have been using Design Systems (reusable components and patterns) from the very beginning with Photoshop. Adobe Flash also used reusable graphic "components". We just didn't call it Design Systems back then. Nowadays it's easier to create a Design System with the cloud-based ability in Adobe XD. I think Brad Frost is a cool guy, but he only highlighted the idea of the obvious. I understand the small to large analogy of Atomic Particles, but trying to inject science terms into design language makes the systems concept confusing for designers.
![[DRIP] ‘Love, Maybe’ PREVIEW](http://i.ytimg.com/vi/U7hwHp95m1k/mqdefault.jpg)
Here are some of the topics he hits on in his talk:
1. Your Sketch library is not a design system - the heart and soul of a successful design system is a collection of reusable code components that build real software applications
2. There are many technical benefits of design systems: reducing technical debt, faster and higher-quality development, reduces QA effort, potentially makes adopting new technologies faster, it’s a useful reference, and it’s a future-friendly foundation to build and iterate over for years to come
3. A design system has to be compatible with whatever technologies are used at the organization. That means creating and managing a technology-agnostic design system.
4. A design system needs to power real software applications. That means using pilot projects to ensure your design system is actually handling real-world scenarios rather than being an off-to-the-side exercise.
5. Create the design system’s UI code in a frontend workshop environment in order to quickly articulate many product scenario UI without having to build the functionality for real.
6. Create a CSS architecture for your design system that is portable and
7. Use atomic design to connect the design system components to your actual product screens
8. Components are like tools in the basement. Over time, the system should provide a healthy chunk of solutions for your products, meaning you don’t have to expend a bunch of time, energy, and effort on brand new stuff all the time.
9. With directly consumable components, you can bake in best practices into the components. That means you can build in accessibility best practices like requiring alt text for images and automatically generating the necessary id attributes.
10. Understanding how to release and deploy a design systems is critical. I highly recommend Nathan Curtis’s 6-part series on the topic.
really helpful presentation on design system can you Please share PPT or PDF of presentation
Why not just use an in-between tech/lang/markup to create these components? Like JSON seems perfect to me as a descriptor for components (or xml), and then you can read/parse the system regardless of the tech used, and you don't need to port anything from one framework to the next hotness
Looks like Brad was on the right side of history regarding React 😅
I find it unfortunate that react-styleguidist doesn't show up anywhere (neither in the talk nor in the linked resources). It's interactive nature, included API parsing and so on IMO makes it much more suitable for a playground, style guide and API documentation all in one versus e.g. storybook.
UPDATE: Ah, I just saw the end of the video. I think now I get it. ;)
React can be a legacy-to-modern UI tool because legacy DOM can be transformed into modern DOM - or DOM output by various server-side tech to modern DOM
Brad is awesome
Awesome talk
Designers have been using Design Systems (reusable components and patterns) from the very beginning with Photoshop. Adobe Flash also used reusable graphic "components". We just didn't call it Design Systems back then. Nowadays it's easier to create a Design System with the cloud-based ability in Adobe XD. I think Brad Frost is a cool guy, but he only highlighted the idea of the obvious. I understand the small to large analogy of Atomic Particles, but trying to inject science terms into design language makes the systems concept confusing for designers.
God what an awful audience...
Why exactly? :)
@@WebConferencesAmsterdam they hardly laughed at a single joke by the sounds of it! Great show by the way :)
Oh, they laughed! We just don’t have mics hanging over the audience :)