Design System tools & workflow for small teams
It’s necessary to tell about the benefits of having the consistent visual language and working design system anymore, everyone is talking about it nowadays. But there are many ways to execute it on practice. Which tools to use, how to build the right workflow and communication in the team. There is no one-fit-all solution yet, what works for big established teams will not work for smaller ones or single designers.
So here is my version of Design System setup. The main criteria for choosing certain tools and flows over alternative ones were:
- it should be easy to start using
- safe storage and versioning
- all resources have to be accessible to the rest of the team at any moment
- scalable functionality
👋 Since this article has been published 2 years ago, there were a lot of updates and new trends in Design System setup available here:
Toolbox
Sketch
Might seem obvious for the rest of the world, but it was quite a move for our team as literally no one have tried it. Switching from XD (thanks God not Photoshop) to Sketch was harder than expected
Dropbox
Cloud storage and version control
Invision
Mainly used for collaboration with steakholders, hand off to developers and simple prototyping
Jira
Product owners’ favorite tool
Also Adobe Illustrator for Marketing Design, in Product design I use tools as Principle and Framer for interaction design, JetBrains Webstorm for code, I’ve also used a Symlink tool for a little hack in Sketch.
Alternative tools that we have tried but they have not passed our criterias are Abstract and Git (version control), Zeplin for hand off, will tell more about them below.
While being super enthusiastic about discovering new fancy design tools myself, in teams it’s wiser to use stable ones that have big active communities and many useful integrations, unfortunately it does not help innovative fellow to get their products into masses.
Sketch workflow overview. Using Sketch Template and Libraries.
At the time we were setting up this Design System, Sketch has just introduced its libraries in Beta, that would allow of having a single source of truth for UI components and seamless team collaboration. We immediately decided to put it into the center of our Design System. It was the best decision to make!
Creating a consistent style
Often rebranding or changing the overall product style is not exactly a goal, most of the time what you need is just to get rid of inconsistency and to fresh up, to add a bit of a uniqueness and an articulate character to the visuals and the tone of voice.
I have started with distinguishing styles, reusable elements and whole blocks from the existing product and collecting them into one sketch file. Often there are several variations of the same component, or lots of button style to throw away, not speaking of typography. So there will be many decisions to make on this step. Start with the easy parts — color palette, typography, spacing grid and basic UI elements (atoms). They are easy to arrange into reusable styles and symbols in Sketch. This makes a proper foundation for your future Library.
We can already link it to Sketch as a library and try it out.
Here is the first pain point comes. Sketch Libraries allows to share Symbols, but not Typography styles, Filling Styles and Color palettes. This has to be done via Sketch template, which create another layer of complexity, but unfortunately the only way to go.
I have cloned my dear library and remove all the symbols from the version that is meant to the template.
In order to keep template outside of the Sketch App folder (in the Dropbox one in our case), I used a little hack with Symlink tool, that explained in details here
The problem with the template is that it gets cloned every time and updates of the template would not affect the files that was created with it previously. There are pro’s and con’s — on one hand it keeps old files safe - none of the updates would damage old designs. Those, who knows how CSS changes can lead to unexpected results all over the place would understand me. But on the other hand it does not move us closer to the dream of the continuously evolving Design System. One of the solutions can be turning typography and color styles into symbols and linking them through the library, I have done it for the button fillings and content elements, but overall it sounds too much like a hack. Currently we have to cope with the fact, that if we decide to touch some typography styles and colors, it would have to be done manually in every previously created file.
I have left the page with the styleguide in the Template file, this way every new file created from this Template would have a copy of it, it can be use as a reminder or removed.
Library
Library contains a selection of UI elements saved as sketch symbols with extensive overrides. This library can be attached to every new or old sketch file, every time something is changed inside the library, all previous versions will get a suggestion to update to the newest version, so if we decided to use pink buttons instead of blue, we can change in the library and all sketch files linked to it could be updated. This can be a very powerful tool, but has to be carefully protected, that’s why we keep it on Dropbox with limited access rights.
By the way, I have discovered that different versions of same font can render differently and eventually break sketch files. I have reinstalled all used fonts on my computers and required all team members to do the same.
Storing and version control
Storing the data on the cloud is out of the questions nowadays. Versioning should be too, but apparently it is still not embraced by most of the teams. In the code world it is done with Git, which would be a powerful tool, but in the design environment it would just create more problems. The learning curve is too steep, it requires actions every time which would be often forgot or ignored, there are no immediate rewards. So too much effort for little benefits.
There are new tools like Abstract popping up, they make it easier for a regular designer to learn, but still have some troubles to use, my personal experience with it was quite bias. It corrupted some of my files (=days of work), did not support latest Sketch features immediately, and, the most important, there is not single .sketch accessible anymore.
The alternative was good old Dropbox that has built-in versioning control that you never notice before it saves your ass. It’s probably not the most powerful tool, such things like access rights settings can be improved, but for a small like ours it’s still the best option and requires zero effort and learning.
Getting other designers on board
This is where it gets really interesting. Set of buttons and 8 shades of gray can hardly solve the design inconsistency problem. The library has to be
- hardwired into design process by every single designer
- massively enriched to serve needs of every each of them
The more it’s a one person’s project, the more personal it gets and harder for other members to start using them. It is better to involve the rest of the team early on and let them to add the elements they need themselves. It helps not only to start a discussion and allow everyone contribute to the common good, but it would make them learn and understand the logic of the system faster. Often we reinvent the wheel just because we can’t figure out how to use someone else’s one.
It’s good to agree on such rules, like file structure and naming, responsiveness support, using grid, icons, frontend limitations. It is super useful to involve frontend developers into discussion as early as possible.
Sharing
Dropbox is a great way to keep the store source files and assets, but it does not always help when you need to present specific cases and keep non-designer stakeholders in the loop. We use InVision for that. We got everyone in the team using it — the management show can easily show teasers to the investors, the head of product loves leaving comments in the middle of the night, product owners can link directly to Invision prototypes directly from Jira, developers can easily find all they need without begging designers to send the latest version in pdf, marketing create moodboards together with designers, and it just feels cool to show your new cool design directly on the iPhone and watch people amazed that we are working that fast (and gets disappointed when discover that it’s just a prototype).
We have tried Zepelin and some other tools for developers hand off, but it gives no obvious benefits over InVision Development Tool and since we use InVision anyway, no need to overcomplicate the workflow.
Working on real stuff
Design can differ a lot depending on what you are designing for. Colors and Typography can be shared between different teams, but UI elements on Marketing Pages might have nothing to do with the Products ones. That’s why I focused more on creating the proper structure and workflow rather then framing specific components. The next step would be to create separate libraries for different needs — marketing pages and different products. The great thing about Sketch Libraries is that you can link to several of them.
The next step of the design system has nothing to do with buttons and typography styles, much more than that.
I would start with creating 3+ Sketch files (or one file with 3++ pages in it):
- Product map, that includes same resolution artboards (I take 13’’ laptop resolution), you start with having them empty and just naming them and maybe adding a list of basic functionality.
- User journeys (same like product map, but arranged like user journeys)
- Design in details: screens, different states, their responsive versions and related components
The most of the work is happening in the file number 3. It can be one file with multiple pages for different screens/parts, or multiple files. I like to have them on different pages, but the file might become too big and too slow.
For example working on the Dashboard, I would create a Dashboard page with a bunch of artboards on it: low-level prototypes, different resolutions, alternative versions, states, children components, everything related to this part. One of the artboard (13’’) can be transformed into a symbol and reused on the product map and the product journeys files. This way you can always have a high-level view of the product with all the latest updates, and focus on details on the other file. No need to copy-paste and update after every change.
I try to follow the same logic syncing my work to InVision, with Craft Plugin this process takes seconds.
Developers hand-off
Most of time waste is happening on this step, unfortunately we could not find tools yet that would automatically sync same components on design and frontend sides yet. Most of them have one-direction communication (e.g. designs can be translated to React Components once, but further changes have to be done manually anyway). And cleaning up the code creates even more work than just writing it from scratch.
The best we can do is to work together as much and possible, listen to each other’s needs and.. keep the same naming
Free download
You can download the library I used for illustration on Github. Feel free to contribute as well!
Update
A new article about Design System setup available here:
