From experience, I've been part of teams that displayed frustration at a lack of clarity when it came to UI assets, and how those assets were managed. Often UI elements would be designed, and built, on an ad-hoc basis, with little thought given to to how scalable those solutions were, often resulting in multiple instances and re-designs down the line, as the product matures. It's become obviously, painfully so at times, that this is often not the best approach. Enter the design system.
It should be no surprise to those that know me well enough with the design community that I love Figma. It's become my number 1 design tool, and has been for well over a year now, totally eclipsing Sketch. This video does such a fantastic job of explaining just one reason why that is, the absolute symplicity and logic of building a design system in Figma.
The first time I ever considered the benefit of using a design system going forward for all design and development work was during my time at WiggleCRC. Whilst there was an excellent UX team within the company, which also included UI Developers, there was no real discussion of using a design system. We were of course using Bootstrap to eventually build out the UI components that would be designed by myself and the rest of the team, but this was by no means a standardised approach.
In order to really get the team thinking about a design system, we shared documentation and medium articles on slack, and talked about it further during on our Friday design meetings. In theory, it made a great deal of sense. A single source of truth, one which contained our user experience guidelines, branding and our UI elements - which would effectively be designed in such a way that they should be consistent and make sense regardless of the context in which they would be used.
"Why use Figma to do this Chris?" Figma was at the time still a relatively unknown design tool. Designers were still getting over their love and frustration of using Photoshop to design digitial products. Nothing could best Sketch. Or could it?
Note: A design system can't be designed in isolation. It requires many members of the team to chip in and collborate from all aspects of the business. It should not only act as a system in which people within the business can refer to for guidence, but it should be an aspirational tool which you should be proud to display publically. See AirBnB, Google's Material Design and Salesforces' Lightning Design System for inspiration.
If you're not familar with Figma, and you asked me why you should use it over other design tools, my answer would be tranparency. I've often found designers to be too far removed from the rest of the team, and collboration is not a priority. Figma encourages collboration.
"I've found designers to be too far removed from the rest of the team, and collboration is not a priority. Figma encourages collboration."
Colour. Typography. Sizing and Spacing. Desktop, Tablet and Mobile Widths. Imagery. This was an aspirational list of basic rules that would first be included in the design system, sharable with the team directly through Figma - but it wouldn't always be this way, instead, the preferred method of sharing would be embedding "live views" of different artboards on a private URL, such as design.wiggle.com. Each artboard would live in a different navgational item down the left hand side, accessable to all within the company, and always display the latest, signed off, version.
Because of Figma's developer handoff feature, developers were able to see padding, margin, font-sizes, RGB and Hex colour values and so on. No more sharing of flat images, no more guess work for devs or time spent asking questions. They had access to the single source of truth, so in effect, didn't need to ask certain, specific questions.
As with the Salesforce example above, eventually, Teams thoughout WiggleCRC would collborate and create an online repository that would host information on UI and UX Design guidelines, links to ongoing projects with Figma embeds and Accessibility information to name a few.
Atomic design is a methodology that was created by Brad Frost way back in 2013. In simple terms, it's a way in which we can organise different elements throughout our design system. Elements are organised using the atoms, molecules, organisms, templates and pages. At first glance this may seem a little complex for a design system, however, it's really rather simple. Let's focus on Atoms, Molecules and Organisms:
A good design system should reflect the flexability and dynamism of the organisation that employs it. Nothing exists in isolation, everything is interconnected. A good design system therefore encourages designers, and other members of the team, to think about the interface as an organic, flexable, scalable system.
Teams that successfully spend time on their design systems and promote the ongoing development of those design systems, are encouraging consistency and fundamentally, good user experience design.