I’ve been interested in the notion of design systems since the first release of Atomic Design by Brad Frost came out in 2013. Around the same time I switched to Sketch for all my UI works, and it immediately seemed clear to me that a more systemic approach was not only finally possible software-wise, but utterly necessary to keep coherence across an ever-expanding range of digital products and platforms.
The classic brand manual or even the “Style Tile”, a document containing a summary of UI guidelines, couldn’t keep up with a more and more modular, collaborative and agile workflow and the proliferation of digital platforms.
Luckily, programming languages and frameworks have been evolving in the same direction, and probably even inspired the evolution of design systems, with Angular and React on the front line: from multiple separate languages for multiple platforms to one fluid, dynamic framework made of many little adaptable pieces: the very embodiment of the atomic design system.
A system that defines itself
Lately, lots of tools have been launched to address this need and make life easier for designers, yet most of them share the same paradox: they allow you to build a design system, but when you upload it to their platform to hand it off, the platform has a given style, which doesn’t meet the same design system’s rules you just set. The ideal tool would be a platform whose style is defined dynamically by your own design system.
The ideal tool would be a platform whose style is defined dynamically by your own design system.
But, unless you code it yourself, I don’t think such tool exists yet.
So far, I found the Launchpad Sketch plugin by Anima to be a good solution: it allows you to directly publish one of your Sketch pages to a custom domain, easily add interactivity, and update it any time you want. Nothing is added to the Sketch pages, so you can define the navigation and any other effect yourself.
Normally, I would have one or more Sketch artboards (or, starting with Sketch 47, a library) dedicated to the design system and linked to my symbols. I find the default automated symbol page to be too hard to control and browse, so I’m always adding the symbols to a different page with some more order and logic to it. From there, I just add basic navigation and push it to Launchpad. Pretty straightforward.
I don’t think this was the original goal of Launchpad, but it would be great if the Anima team decided to consider this use case and add some more features related to it in the future, like better integration with Sketch own responsive layout properties (you currently need to use Anima’s Auto Layout plugin for it to work well, particularly for symbols) or the ability to insert downloadable assets.
Skip the Wireframe
I think there’s another consideration to make, related to this kind of workflow.
I’ve always been doubtful about wireframes: clients don’t get them. A quick sketch drawn on paper can go a long way in explaining a certain interaction pattern, a transition or the structure of an app’s page – I do that a lot live, during meetings – but I think digitally crafted wireframes, sometimes even imitating a hand-drawn style, are just a waste of time. Particularly so as they force you to reason in terms of ‘pages’ or ‘screens’. Why not start from the atoms?
If the work is well-structured since the beginning, the whole system can grow progressively and modules can be updated without too much hassle, so there’s no need to have the final, perfectly clean style from the start.
Start at the end
I know it sounds counterintuitive, but what I usually do is to try and get a clear and good-looking UI as a first thing. I choose one of the main functions of the product and build around that. As soon as I need a certain component, I design it and immediately create a symbol for it. I used to add text styles and fixed palettes at the end: now I do it at the beginning. They might not be perfect, but they allow me to keep the whole thing as a coherent system as opposed to try and refactor everything once it’s too late.
You might think this method is too rigid and harms creativity. Quite the opposite: when you’re not limited by the cage of a wireframe and start from the look of the UI, you have much more freedom about which components to design and where to put them. Furthermore, you are not limited by the concept of an app’s ‘page’: which is finally becoming an obsolete idea. Transitions and interactions can happen on single components (which can then conveniently render separately even with hybrid apps, for example, using React Native), as opposed to the traditional whole-page transition.
Do your homework
That said, I’m absolutely not implying that designers should put the aesthetics of an app before its functionalities. There’s a whole process of user-research, generation of user journeys, stories and requirements before you should even open Sketch or any other design software. But it’s useful to start building and publishing a design system as soon as you can, even for small projects. It helps you and your team keep focused and it puts design where it should be: not on top, as a final icing layer, but at the base and in the middle of everything, like the yeast that makes every building block cook nicely together.