In part one we took a look at the foundations of Design Systems. If you haven't read that yet, I suggest you check it out!
In this post we'll delv...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Emma,
Great post once again. Learning a lot about design systems due to your talks! I had a couple questions related to design system.
For example, there is a lib called,
styled-system
, which makes it possible to expose marginRight, marginLeft, ..., paddingLeft, paddingRight, ... to the "consumer" of the design system, but I'm not sure if that's such a good idea. It feels wrong, but I can't really express why and I might be wrong about it.Thank you for everything you do!
Kind regards,
Kevin
Hey Kevin!
You can absolutely maintain consistency with flexibility; it's all about providing boundaries for said flexibility. For example, allow teams to customize the theme/color palette for different products. So they won't be able to go rogue and add random colors, but they have flexibility to choose options within our bounds.
Too much flexibility is letting developers add custom/rogue values for things :).
What about how a component acts on it's surroundings. Like the padding or margin of an icon. Would you expose marginRight, etc or preferably a prop called "dense", which either makes the spacing tight or "normal" rather than giving straight access to modify the internal margin's.
You can create a spacing mixin/partial if using Sass to allow developers to add specific values for padding/margin. We use a multiple of 4 and have defined variables to help with this :)
That helps! Thank you! :)
Instead of thinking about elements and components, I like Atomic Design methodology and thinking in terms of atoms, molecules and organisms.
I think atomic design can't be properly used on a real project, at least 100%, as you will need different styling for same elements on different parts of a view.
Moreover you'll need those atoms to convert into usable components after all, it simply adds a step, just for adding coherence on a team (i mean avoid everyone to design components as they like instead on keeping same definitions).
Even those facts, Atomic Design is needed nowadays and its useful for many reasons, coherence (as i already said), easy-to-port as front-end framework and easy to generate a theme over it with few overrides (if well implemented).
This is a really awesome article I really learnt a lot from it. My question is how do get people onboard to refine or upgrade when you don't have a dedicated designer in your company especially when it's a small startup that does not have any designers?
Thanks for share this great series, Emma. I have a question respect to the order of the steps. If I don't have an existing application it implies that I can't do a UI audit and without it we can't prioritize accurately. So, what factors do I need to be aware for?
Thanks.
Ah Your talking about so-called style guides right? bitovi.com/blog/style-guide-driven...
Next time you should maybe apply and use the terms that are known by the industry
This is great, thanks for writing this up!
This is a huge area for certain.
Thank you for the post! This series is a good summary of the gigantic field.
Do you recommend creating your own Design System, or use existing ones ?
As a Entry level engineer in software industry, do I need to start with design or should I start with database first?
In-depth information.
This was a great read! I've almost always been on the maintaining end of a design system, so it's really insightful to read about getting one set up. Thanks, Emma! Can't wait for the next one!
Great article @emmabostian . Did you take this investigation any further?
Do you have any advice for how to share your design system with your team (what tools to use, etc) - and how to get and gather feedback from stakeholders?
Thanks for the post!