I’m one of the eight UX Jedi working at Raona, a software development company. We design and build a lot of apps every year (>100), and every single one of them is carefully conceptualized, designed and crafted with love :)
As you may imagine, most of the apps we build have common components, styles, and other stuff like icons, so it’s quite clear that we need to “reuse” design components across projects and design files.
But further than this, having such an amount of different projects also means we have many ways to approach the same UI concepts (several types of forms and inputs, different toolbars and menus, modal windows, … and lots and lots of card templates for board-like interfaces). And that’s incredibly powerful. It’s priceless. But… it’s also hidden. No one (except their creator, and luckily one or two colleagues) knows about them.
We had a treasure chest of reusable components and design assets… hidden in a drawer.
This is why we started thinking about having a unique design system for all of us. To be more productive, obviously. But also because it provides the best way to share knowledge, design alternatives, and best practices within the team. Even when there’s a new hire in the team, it’s a super-rapid way for him/her to get on the train.
Brand.ai published three cool articles about this same topic that helped us a lot, but none of them satisfied all of our needs. Anyway, give ’em a try (spoiler: go directly to step 3).
Our requirements for a design system
- Have a single (and always updated) place to host all of our reusable components and make them visible.
- Whenever a design asset is updated, the team must be informed.
- Every designer must be able to use the assets easily in their projects.
- Whenever a design asset is updated, any design file using that asset must be informed (and ask if willing to update).
- Any of the UX team jedis must be able to update the design system easily and without conflicts (merges, versions, …)
We are big fans of atomic design, so we organize our Sketch files in a component based design system. In Sketch this means that we have organism symbols that are made up of molecule symbols that are made up of atom symbols (I can’t belive I wrote this sentence. Let me draw it).
That’s super cool and highly productive, but a bit tricky, because depending on how the design system manages the references to other symbols this can become a real nightmare. Keep reading, you’ll see it in a minute.
What’s included in the design system
There are basically 3 things that we need to reuse among our projects.
- Components: which include all of the component-element-particle structure mentioned before.
- Icons: don’t ever underestimate consistent iconography :)
- Text styles & colors: otherwise called identity. We’ve all gone through some project with tons of similar styles, colors that look almost the same but are not, and text sizes from 11pt to 24pt… well, practice makes perfect. Don’t do it again :)
The original idea is quite simple. Having a symbol of everything we’d like to reuse. Sooo simple. Ta-daaaah!
To organize them, we created a Page for any kind of component or element (call ’em controls, if you want). Notice we also have an ‘Icons’ page, and an ‘Identity’ one, where all text styles and colors are set. This is how it looks like:
Now when one of us needs to design a card, a button, a modal window, or whatever in his/her design, can just open up the design system and see all of the available options for that very same UI element.
We have the Sketch design system file synced with Invision (as a project), and when anything is updated in the design system, the Invision project gets updated too. As the project is also synced with Slack (in a Slack channel called #designguide), and everyone in the team uses Slack and is in that channel… the whole team gets magically a notification and a thumbnail of every change that is made in the design system. Cool!
With this simple idea we achieved the first 2 of our 6 goals. A single place to host all of the UI elements, and the team always up-to-date.
Don’t copy&paste from your design system. What you need is to get an instance of the symbol in your file, keeping the link to its origin.
So…what about reusing and syncing elements? Let’s get to it.
The best solution: using Craft Library (though it doesn’t work 100%)
I’m an Invision great fan, I must admit (go try it!). Well, Invision has a great suite of plugins called Craft, and one of them (Craft Library) is a tool thas was developed specifically to solve this kind of sharing+updating+collaborating complex problem.
A Craft library is just a collection of controls that you can arrange in categories (it has a lot of other cool features, check the Craft plugin page for details).
The amazing part is that you can use items from the library in any design file you’re working on. You just need to open the library, and drag the component to add it to your design.
You just need to open the library, and drag the component to your design file to start using it. So simple, so clean!
But hold on! It’s cooler! Whenever the original component in the design system is re-synced to the Craft library, Craft will automatically notify you in your design file (and you’d be able to get the changes — if you wish to — by just clicking a “refresh” button). Whoa!
The idea, using Craft Library, is to create a library called “design system”, and replicate the whole Sketch file structure in the library. The Sketch file becomes then just a way to see and edit the components, but the “real sharing” platform is the Craft library.
Here’s how the big picture looks like:
Therefore any designer may use any component in the design system easily, and get notified whenever it’s changed in the design system (and asked if willing to update). Hey… those were requirements 3 and 4! High five!
What you get in your design file is the full symbol, which means that you can edit anything you’d like to for your own design. And, maybe, re-upload the ‘improved’ symbol to the Craft library for others to use the updated version. You just need to select the symbol and re-sync it again to the library.
It’s a cool and useful feature, but for me it’s even more important. It provides a way for all designers to work with any component in a separate file, and when finished uploading it to the library, avoiding troubles of different people editing the base design system file, versioning, merges, … and that was requirement 5! Yaaa-hooo!
So Craft Library seems the solution, right? Why did you say it doesn’t work 100% for you?
Craft library works great with ‘atom’ symbols. It works like a charm, nothing to say. But, as I said, we use atomic design, and that means we have (at least) 3-level-deep symbol nesting. Craft initially had a lot of issues related to syncing, re-syncing, and updating design files when using ‘molecule’ and ‘organism’ symbols in the Craft library. References to library items seemed to get lost, and nothing updated accordingly to what one would expect. But fortunately there are good news! It’s been improved a lot since those first days, and now it seems quite better at handling symbol nesting and references.
Craft library had some issues handling nested symbols, but now most of them seem to be solved.
When you ‘use’ a symbol from the Craft library, what you get in your design file is the full symbol and all of its dependencies (if you import an ‘organism’ symbol, you’ll get also all the ‘molecule’ and ‘atom’ related symbols). If you edit any of the ‘atom’, ‘molecule’, or ‘organism’ symbols, and re-sync it to the Craft library, all items that are dependant on it will get updated (which is great!).
At the time of writing this article, Craft only has an issue related to symbol nesting. Though re-syncing any of the ‘atom’ or ‘molecule’ symbols to the library will update the symbol in the library and all symbols depending on it… Craft is not telling other design files that use those symbols to get updated. The relationship between both seems to be broken some way.
The good news is that the Invision (awesome) support team is aware of it (we’ve been talking a bit this weeks) and the dev team is already working to solve it. So… I hope that soon I’ll have to edit this post to remove this few lines :)
Reusing controls is never easy stuff when you need auto-updating, deep-symbol-nesting, versioning, and several people contributing on it, but with this system it can be pretty straighforward. Give it a try!
Note that we’ve been only talking about the technical solution, but sharing a design system does involve lots of other stuff: contributing, validation, growth, etc. Make sure you define (or think) about those before unleashing your design system.
Reusing controls is not easy stuff. But with this system it can be pretty straighforward.
Just a couple of considerations:
If you’re working with flattened libraries (without symbol nesting) and with a single branding/design guide, it will work like a charm. If you do work with atomic design and need nesting, it will work, but you’ll just need to be more careful and train your team well.
If you have deep nesting, and work for several customers or have several brandings/design guides… you’ll surely encounter difficulties reusing components, and trying to apply your other branding to them. I’ll soon publish a post about this. Keep the lines open.
As always… hope it helps! :)