UX Journeys: On Design Systems

Design systems can be a misunderstood arrow in the quiver of a UI Designer or UX practitioner. Clarity on what it does and doesn’t do is the key.

Communicating visual and interactive preferences across design, technical, and stakeholder relationships is a challenging function for any project. Thankfully, the concept, awareness, and utilization of design systems enables this challenge to be met with most of the harder pieces taken care of. A design system can be thought of as a template. In general, this would contain:

• A library of visual (sometimes audial) components for designing the interface
• Code snippets and rules/logic to handle interactivity
• A framework for dealing with handling user and technical errors
• Links to associated or derivative resources
• Links to research and metrics from the development of the design system resource

Now, smaller design and development firms may create products using an existing design system (Section 508 Compliance Guidelines, Google’s Material Design, Salesforce Lightning, etc), or create a custom design system from the knowledge of using existing ones. Whether a pre-existing or custom system will be used depends on the time and resources dedicated to the project, and what level of fidelity will be needed throughout the design and development process.

The larger challenge of a design system comes from how it will be communicated as the pointer to solution being developed. For developers, a design system answers questions such as code quality, performance, API integration, etc. Without a design system, or without the knowledge of what a design system provides, too much time is going to be spent by designers and developers talking past each other before coming to a conclusion on these matters.

For stakeholders, a design system really should serve as a starting point for the ideal and base level design and functionality of the solution being developed. Unfortunately, a miscommunication of a design system (for example Section 508 Compliance) doesn’t allow stakeholders to think through what their solution does to extend the framework, and its merely used as a template (“can you make it look and act like the Compliance website” versus, “what can we take from that framework to demonstrate why our solution is transformative”). A well communicated design system enables stakeholders to spend less time deciding what something looks and feels like, and more time ensuring the solution is a complete answer.

If your designers and developers cannot point to the design system(s) governing their decisions, you are right to question not only the quality of the output, but the competency of their approach. As a company, Mindboard leverages both major design systems (the aforementioned plus ones from Facebook, Apple, and many other companies), and customized approaches to ensure that we aren’t reinventing the wheel every time a client wants an innovative solution.

Do your design and development teams need a refresher on using design systems? Or, do they simply need to understand how to better communicate the value of the design systems they are using? Get in touch with Mindboard and let us know how we can help your team(s) forward.