Going Subatomic: How Working On A Design System Revolutionized My Way Of Approaching Design
Going Subatomic: How Working On A Design System Revolutionized My Way Of Approaching Design
What I learned during my two years working on a Design Language System for Accenture and how it made me question what I thought I knew about the design process.

Giacomo Gabrielli, UI/UX Designer
Hello everyone and a big thanks to the organisers for inviting me today. My name is Giacomo and I’m a UI and UX designer at Accenture. I’m here to talk to you about my work on a design language system and to share some tips that I hope can help whoever is working this kind of project and improving the usability of their library files.
Before we start, a few words about myself… so that’s me with a monkey because why not? My career started off as a freelancer and after years and years of collaborating with communication agencies, design studios and what not, I joined Accenture in 2018. For the last couple of years I’ve been part of a small team working on a very ambitious project, a design language system that could scale across several of the company’s applications. So it was quite obvious from the start that the task would be pretty challenging. Our mission was to audit a portfolio of dozens of different apps to create a design system that would accommodate all functional and non- functional requirements of those apps, while still maintaining the company’s strong visual identity and narrative.
But first of all, what is a design language system. Even though I’m sure that most of the audience is already familiar with the concept, it remains quite broad and king of a vague domain and depending on who you ask everybody seems to have their own definition. These are some of my favorite ones that I stumble upon while reading articles and listening to speeches. So Brad Frost, the first to theorise the atomic design concept says that a DLS is the story of how an organisation builds a digital product. Alla Kholmatova, the author of a great book called - wait for it - Design Systems defines it as a connected pattern and share practices organised to serve the purpose of a product. Or again, a bible of visual standards, typography, guidelines, colour palettes and repeatable patterns used to dictate the voice and tone of a brand. And at last, my favourite of all, what brings order to chaos which in my opinion, really sums it up perfectly. So no matter how you decide to define it, the general idea remains the same: a design language system is a single source of truth based on design assets, guidelines, code assets, patterns and semantics with the goal of improving the design process with scalability and consistency. I guess, I have my definition too now - so just add that one to the list as well.
The market today offers dozens, if not hundreds of great examples of design systems built and distributed by companies of all sorts. For example we have Material Design by Google, probably one of the most famous ones out there: Carbon by IBM, which is my personal favorite, Protocol by mozilla, Polaris by Shopify, Airbnb Design, Base Web by Uber and this is just to name a few. But a design system can also live outside of the corporate world, and since I’m a huge comic book fan, I felt a strong urge to include in my speech, the recent and quite awesome rebranding of the X-Men. In 2019, Marvel comics decided to completely renew the franchise from both a story-telling and design standpoint. Author, Jonathan Hickman along with designer, Tom Miller drove the look and feel of the series through the roof in quite a different direction to what comics usually do. The new brand identity relies on, and you probably guessed it, a design system. It’s minimalist aesthetics are heavily inspired by Swiss design and in my opinion it works really, really well scaling perfectly across the many titles connected at the X-Men roaster.
Okay, back to business. So my main job on the design system that I’ve been working on in these past years is to craft and test the components in the so-called UI library. A UI library usually comes in the form of one or more design files which we can call Mother Files. Designers can install these Mother files as libraries to use the ready-made components and styles without having to actually open the files themselves. A Mother file is usually stored in the cloud. Everytime a new component is added or changes of some sort is made, it happens in that specific file which consequently updates all the Children files that use it. One of my tasks is also to operate as a housekeeper for those library files which means I have to make sure they’re always tidy, updated and efficient. You see, a design library is an entity in constant evolution and it can be a big, hot mess with hundreds if not thousands of symbols. So this role is of the utmost importance or that’s what I like to think, at least. This job has had me spending quite a large portion of my days working on ways to make the library more smart and more reusable for both our teams and the designers that will be using it for their projects. I’m sure everybody has their own tricks and techniques on how to create and maintain a library because whatever works, right? Nonetheless, I would like to share a few tips based on my personal experience which I hope will benefit you no matter your level of knowledge on the subject.
I’m going to get a little technical but please bear in mind thatI’m referring specifically to the software that I usually work with, which is Sketch. Although a lot of what I’m about to say is just based on common sense and it can surely be applied to other similar tools as well.
Okay, let’s begin. So the first tip on my list is Go subatomic. A design system is a modular, scalable way of approaching design. You start from units, combine those units into bigger entities and just keep scaling up. This concept is known as Atomic Design and it borrows terminologies from science. You start from atoms, you combine those atoms into molecules, the molecules into organisms and so on - you get the point right? So the atoms are the smallest building blocks for the design system. They’re the smallest functional UI units which means they cannot be broken down any further without ceasing to be somewhat functional. Some examples of atoms are buttons, input and selection components such as check-boxes and radio buttons. While struggling with ways to easily make changes to multiple elements at once, I came to realise that sometimes it can actually be useful to create components that are even smaller than the atoms. These subatomic particles are structural, non-functional components that can help gain more control over a library file and save time when having to perform major changes.
To give you a practical example, I’ll walk you through a common use case...So in your DLS library you’ll probably have to say at least four or five different types of buttons: primary, secondary, outlined, text button, destructive; pretty much the industry standard. Let’s say now that for each type of button you want to offer a text only variation, an icon only variation and a text with icon variation - with the latter available both with the icon on the left and the label on the right and vice versa. That’s 20 button types! It’s likely that for each type of button you’re going to want to offer at least four different states: active, hovered, pressed and disabled. So multiply that for the number of button types and you find yourself with at least 80 symbols and we’re just considering one single size which means that potentially your file could contain hundreds of button styles which is pretty intense, right? Now, imagine that you started out with right angle buttons, sharp corners, zero radius now at some point along the line you and your team decide that it would be cooler to round those button corners a little but just to give them a bit more of a friendly look and feel. With all the button containers separate instances you would have to individually select each of the 80 or more backgrounds and change the radius.Quite a length operation which at some point along the line might need to be repeated if a different design decision is made.
The solution that I found, at least, is to create a single subatomic component which we could call button container for example and use it as a background for all your button type, variations and states.By doing so performing a structural modification like changing its radius will just waterfall on all of your buttons. Creating subatomic elements common to multiple components within the library is a smart way to perform bulk modifications with just one clock rather than hundreds. A ripple effect across your whole DLS that will save you a lot of time and a lot of headaches. So other examples of subatomic components could be fields, labels and containers or even modal containers.
Okay, so my second tip for you would be ‘Don’t Be Sloppy’. One thing to keep in mind when creating a DLS is that you need to design for two distinct audiences. The first group are the actual end users of the digital products that will be built with your design system. The second group are the product reams, so designers and developers that will use it to build those digital products. This means that not only a design system should look good, be accessible and offer a solid user experience but also that it should be efficient and easy to use by the people that basically do the same job as you do; so think of your library files as that first line of defense. For it to work well, the way you group and name your symbols must be bulletproof. Let’s start by the grouping, so the first thing I would suggest is to try to be smart with the way you group your symbols and avoid excessive nesting. When I talk about excessive netting, I mean something like this… Probably setting a limit to 4 or 5 levels of nesting could be a good practice, more than that could start to become a little overwhelming for the users. Try to figure out if some levels of nesting can be avoided with workarounds. For example, if you offer a group of inputs with the helped text and a group of the same impulse, without the helper text you might want to consider just offering one group of inputs with the helper text by default and make it removable with an override.
Okay, naming your symbols. So smart symbols naming can really improve a library’s usability. Using numbers to give the order you want elements in a group is a great way to decide your own hierarchy and to not be forced to stick with the alphabetical order. For example, the state of an input can be numbered in a chronological order so 1 for default, 2 for hover, 3 for active,4 for filled out, 5 for error and 6 for disabled. This will make the selection of a different state of the component much quicker and intuitive.
So while being tidy is surely good practice in any type of project it’s essential when working on a design system. A consistent and organised naming of elements in a library can be a bit of a drag, I know that but I assure you that it always pays off. For example, all the labels in the library should be called ‘label’, all the backgrounds: ‘background’ or ‘container’, all the fields: ‘fields’. You don’t need to be too creative with it. It’s so easy to just lose track of naming and get a little lazy. And believe me, I know that very well. By default, Sketch will add the word ‘copy’ to any element copied by dragging and holding the ALT key, it's very common to see files just full of instances and symbols called ‘something, something copy 1’, ‘something something copy 2’, ‘something something copy a thousand’. I admit that sometimes, I might be a little obsessive compulsive but this kind of thing just drives me off the wall. What is also does though is it makes life much harder for the designers that will be using your file and working with overrides to modify the symbols in Sketch. The override panel wish is located in the so-called inspector area on the right allows you to change certain things in a symbol without having to structurally modify it. Let’s see an example, pretend you haven’t been too careful when naming the elements that make a complex symbol like a datatable. The override panel will end up looking pretty messy. When you do a good job with the naing however, the panel will look something like this - just better and easter. So if you want to get a little crazy, emojis can also be a fun and pretty efficient tool for naming layers. And that can really help the user identify elements in a group - don’t over do it, of course.
Finally, tip number 3: ‘Set Boundaries’. This is a takeaway that is applicable to our lives but also to our Sketch files. We want to allow designers that use our libraries to have creative freedom but we also want to make their work easier and I’m sure that they respect the rules of our DLS. Sketch has recently added a great new feature to override function by allowing you to decide the overrides you want to enable for your components and the ones you don’t, this means that when creating a new symbol you can simply uncheck the parameters that you'd want to show in the user’s panel. Say you‘re building a text input, this type of component is usually made of a field, a title and a placeholder, while managing the overrides, you’re going to want to allow the user to only be able to modify the input titles, and placeholder but not the text field because that kind of parameter is usually codified with a specific style and it shouldn’t be change, so go on and uncheck the field. When using an instance of the symbol, the override panel will look something like this…
So I know, this might not seem like a really big deal right now but imaging creating a complex component like the data table we talked about, previously dozens of possible override parameters difference in usability can be huge. The practice of limiting overrides is definitely worth investing some time in, it declutters the library’s usability but it also allows you to set certain boundaries to avoid designs that don’t respect your style guide. If a designer really wants to customise, a symbol can always decide to detach it anyway - not much we can do about that.
Okay, so that’s it. These are takeaways from my experience that I hope can help you improve your workflow but especially the usability of your library files. I would like to finish with a quick quote by the great Emil Ruder which I think fits well with what we talked about today. “To design is to plan, to order, to relate and to control. In short, it opposes all means of disorder and accident.”
Thank you so much for following.