Thanks to modern component-oriented architecture, the front-end community has been naturally gravitating towards design systems as a way of standardising our respective design languages into reusable components. When done successfully, it suddenly becomes trivial to translate standard designs into code. In fact, we may even find that this translation step starts to feel somewhat redundant.
In a world of components, how should our design processes change? How should our tooling change? How should we, as front-end developers, better enable this change? In this talk, we’ll look at the current state of design and development, and where we could go—if we’re willing to push for it.
I really want to know the cons of doing this thus far pic.twitter.com/5GiVgEmVad
— Xavier Ho ?️?? (@Xavier_Ho) June 21, 2019
Design systems are all about bridging the divide between design and code. What does that look like in practice for Seek? They use
html-sketchapp to generate Sketch symbols, so devs and designers work from a common source when working with the design system.
There is a problem though – Sketch isn’t a browser and still works like the old ways of static mockups/screenshots. A new generation of tools are trying to resolve this:
This is blurring the lines between design and code, and adding new options to the tooling choice.
Why still use a design tool? They’re fast, easy, new documents are cheap; and the work is easily shared.
What about dev tools? We have tools like…
- Typescript playground
…which are essentially REPLs so you can easily get up and running. There are more extreme tools like Code Sandbox which is a full IDE in the browser.
So can we bring this thinking into design systems? At Seek they came up with Playroom, which lets people use JSX in a visual tool and share it with a base 64 encoded URL.
(Demo of Playroom)
Seek is currently working on a new design system, Braid; and Playroom can preview all the themes at once.
What they found was Playroom changed their workflows:
- Developers started using Playroom as a complement to their IDE
- PRs started using Playroom previews to assist reviewers and QA
The goal was to make component code more approachable, and it mirrors the advantages of traditional design tools (easy, fast, cheap).
Low fidelity iteration should be on paper, high fidelity iteration should be in code. Design systems are about designing a palette and reusing it and this encourages that, by letting people design in the target medium.
Playroom is open source (
npm install playroom) so you can use this for your own design system.