Design systems have quickly become the standard approach to maintaining visual consistency in user interfaces and smooth operations in teams with multiple stakeholders. Now we’re beginning to see the emergence of design system sub-trends, highlighting just how useful and integral they’ve become on a wider scale.
We’ve moved past whether or not design systems have tangible benefits and are now fine-tuning how we create and maintain them to maximize those benefits. Here are two trends you should definitely consider adopting in your design system practices, and two you definitely shouldn’t.
Do: Platform-agnostic front-end development
First, what do we mean by platform-agnostic?
Basically…one language, multiple platforms. A huge time-saver.
Problem is, running non-native code is hacky at best, so the mobile app versions very rarely worked efficiently. This meant that the end-results were really bad (or really expensive if we developed a different app for every operating system instead).
Platform-agnostic development is slightly different today though. Instead of using tools to make certain code languages work everywhere, we can now convert visual designs into multiple code languages simultaneously. Now it’s one design, multiple platforms, except that the code is always native and efficient. Amaaaazing.
Don’t: Limit yourself button libraries and type scales
There’s nothing wrong with button libraries and type scales. Actually, those are the two things that designers often start with because they instantly offer structure and visual hierarchy to a layout. That being said, design systems are most useful to teams when they have a number of different libraries and documentations.
Here are a few examples:
- Design guidelines: what are our core design principles?
- Content guidelines: what’s our style of communication?
- Brand guidelines: who are we and how do we communicate it?
- Style guidelines: how does this all come together, visually?
- Component library: how does this translate to interactions?
Many design systems are also starting to normalize the inclusion of interactive examples, design tokens, and components that meet the accessibility standards set by the Web Content Accessibility Guidelines (WCAG).
Button libraries and type scales form only a small part of style guidelines, a far cry from what we consider to be a design system by today’s standards. But does it matter? Are complete designs systems overkill amongst the large number of things a designer must already consider (responsive design, accessibility, performance, just to name a few)?
Absolutely not. In fact, design systems have become checklists for all of these things, which is especially awesome for less-experienced designers or those new to working with a brand who might feel overwhelmed by design requirements easily.
In short, use design systems to simplify design requirements. Also, remember that although design systems can seem scary at first, they’re not meant to be finished overnight. In fact, they’re not really meant to be finished ever, more like collaboratively evolved and maintained over time.
Do: Prioritize Code
A design system is meant to keep everyone aligned. Without adequately representing code in your design system, you’re leaving a lot of room for error when it comes to designers and developers collaborating. We’re not talking about snippets, but fully functional code that developers can actually use. The larger the company, the more impact a design system has in terms of ROI, efficiency, increased collaboration, and faster product builds. It’s crucial to begin your company’s design system journey ensuring design and development are equally represented.
The design system managers currently on the market fail to deliver when it comes to syncing design and code, but all of that will change with Supernova’s design system manager.
Don’t: Skip DesignOps
Within your organization, how easy is it to:
- Find relevant documentation?
- Edit documents/design systems?
- Get edits objectively reviewed?
- Sync edits between stakeholders?
What’s just as crucial as the quality and thoroughness of a design system is how easy it is to access, develop, maintain, and sync across stakeholders. While the tools do exist to make all of this happen, the collaborative nature of design systems means that the overall design operation (DesignOps) and all stakeholders involved in the operation needs to be maintained, too. Without DesignOps, even small edits can become a headache.
With your team, clarify the following:
- Who reviews the edits?
- How long do they have to do so?
- Who makes the final decisions?
Within teams (especially enterprise teams), there are so many cogs turning at once that when one cog begins to rust, the whole machine can crumble. DesignOps are essentially human or automated workflows that ensure this doesn’t happen.
If you haven’t started doing so already, make a team-wide decision to sit down with each other (once a week, once a month, whatever) and review the efficiency of the design operation.
Here are some questions you might want to ask:
- First, is it efficient? (Just put it out there!)
- Are changes discussed, or do they just kind of happen?
- Is everybody included, or again, are decisions just made?
- Are there any mundane/repetitive tasks that can be automated?
- Is there a lot of waiting? (e.g. feedback from stakeholders)
Getting answers to these questions upfront will save a lot of headache later. And that’s what we’re all about — avoiding headaches.