UXLx 2017 — Day 1 — Design systems
This choice of the workshop was quite easy for me. When I saw that Jina Anne will have full day workshop, I already knew what workshop I will attend on my first day at UXLx.
Summary
The workshop was a mixture of a design view and engineering view. Jina started with her path from simple style guides to advanced design systems. Then we did a few practical exercises — e.g. we wrote user stories or then conducted very quick UI audit. Last part of the workshop was the mostly case study of Salesforce Lighting Design System (SLDS). To be honest, I expected a little more practical workshop than it was. But there was a lot of takeaways which I split into two parts — design and engineering.
Designers & design systems
This points should be useful for everybody in the team — from developers and designers to product managers.
- Don’t treat your design system as a side project. Design system is how you ship your product.
- Define 3–4 main principles for you design system. It can help you communicate it to your team or stakeholders better. (eg. SLDS have Clarity, Efficiency, Consistency and Beauty). It’s important to have them prioritized.
- Create user stories for your design system. Treat is like a product.
- Consistency in your design system doesn’t relate only to visual style. It is also about a consistent dictionary for your team.
- Nice template for UI audit from Brad Frost — http://bit.ly/uxlxdeck
- Don’t just show color swatches in your style guide. It’s always better to explain how colors should be used and what they represent.
- It’s good to use 4 as a standard base unit for your grid/layout.
- Design system will help you free yourself from a daily design routine, so you can focus on a bigger picture.
- Show. Don’t tell.
- It’s good to use design tokens in your design systems. They are more abstract and help you build a common vocabulary with all members of the team.
- SLDS has nice motion documentation.
- It’s ok to change your mind about something in your design system.
- Everybody should be able to contribute. Make it easy.
- Naming is hard. You should agree on the names of components with your team.
- Support the tools team already use.
- If style guide is not integrated with a team workflow, it will die.
Engineering & design systems
If you are a designer or product manager, you can share this part with your team. Some things from the list may be helpful for them.
- If you’re doing a larger refactor, don’t do it all at once. Focus on one area, then move to another one.
- Automate your accessibility tests.
- Don’t hard code values in your styles, use design tokens instead.
- Don’t bind classes to HTML elements. You should be able to use class “.title-big” for h1, h2 or div.
- In the component library show only the code that other developers need to see. It will be much easier to read.
- If you are refactoring, have a deprecation strategy. Make obvious what is deprecated. Versioning can help a lot. SLDS have nice deprecated SASS mixin.
- Code should be easy to update and maintain, not requiring hacks. It should be clear where files and styles belong.
- Code should be reusable. Be careful with too much nesting.
More readings about design systems
Did you like the article? Don’t be afraid and press the heart icon here on Medium. You’ll make me happy :-)
Also, you can follow me on Twitter or continue with my notes from other days of the conference.
