By using design systems, design teams can improve their workflow, reuse their knowledge, and ensure better consistency, said Stefan Ivanov. They allow one to fail faster and to speed up the iteration cycle, enable spending more time collecting user feedback in the early stages of product design, and reach the sweet spot of a product market fit much faster.
Ivanov, a senior UX architect at Infragistics, spoke about the purpose of design systems and shared experiences from creating Indigo.Design at ACE Conference 2019. He mentioned that design systems are seen as the tools that let people start from scratch, but not empty-handed, providing the designer with an established instrumental that is not only a single source of truth, but ultimately assures knowledge transfer, fosters collaboration, and eases designer-developer handoff.
Design systems support communication and collaboration in teams, as Ivanov explained. "Our design team is split across different continents and we have always strived to make things work as if we were sitting in the same room", he said. He mentioned that besides geography, it is often the case that borders are drawn by gaps in understanding. It can be difficult to communicate an idea clearly enough to a developer sitting a few steps away and have the whole product team on the same page, Ivanov said.
In his talk, Ivanov shared his experience creating Indigo.Design. He mentioned that the inception of a design system helped his team identify flawed UX and design practices and improve their own internal processes.
For example, our product specifications were often getting off track and falling in a silo where people didn’t collaborate enough to provide the quality of requirements that is necessary. Working on a design system helped us in this regard to see the big picture first, and adapt our processes and align them better with our users’ real needs.
Ivanov mentioned that their tooling makes design systems universal, as organizations can create their own design system on top of it in minutes. It also removes the design-developer handoff, with properly generated code with a pixel-perfect match between prototype and code, he said.
Creating Indigo.Design taught them the importance of using the same vocabulary to understand one another more clearly. Ivanov stated: "I find design to be the process of bringing an idea to life, irrelevant of one’s role and tools."
InfoQ spoke with Stefan Ivanov about using and creating design systems.
InfoQ: How can design systems support team communication and collaboration?
Stefan Ivanov: A major success measure for our design system has been how it will improve the communication and collaboration between user researchers, interface designers and developers. The answer to this question was crucial to us because as in many organizations,
Integrating a UI Kit with rich prototyping experience is an obvious need for someone like myself, but also being able to conduct usability testing is instrumental. This makes rapid prototyping possible and saves hours of meetings, while keeping the feedback and changes from one iteration to the next transparent to everyone.
Once a design is stable, development may start with a simple meeting, especially when prototypes are integrated with the generation of executable code. This reduces the back and forth between designers and developers, but also mitigates the risk of working with assumptions caused by lack of proper communication.
A consistent style and behavior of the UI Kit and UI component library drive the number of flaws further down, and we all know how often these overtake many meetings. Here is why I believe that the success of a design system is determined by how well it bridges the gap between various roles because that boosts productivity by letting everyone do what they are best at, rather than talk about it.
InfoQ: What approach did you take to develop your design system? And why?
Ivanov: First and foremost, a design system must clearly answer the question of how well it supports the different roles in the product development lifecycle. How easily can a designer craft a design that pleases the eye but is also functional? How can a user researcher validate the layout and screen flow? How easily can a visual artist define and apply the brand? And last but not least, how accurately and quickly can these concepts be translated into working code?
When we started exploring ways to start our design systems journey, we looked at two things: what others had done and what our end goal was. Others’ experience taught us how to split and organize our UI Kit. We embraced the Atomic Design approach and created three separate yet connected libraries. The end result that we aimed for was to let product teams quickly design and build complete apps. In order to achieve this, our team looked as some 100+ apps, both commercial and enterprise, as well as tens of design patterns for web and mobile. We clustered them by usage and analyzed the building blocks that were used to establish them. This effort took us a few months to gather and organize the initial ideas, but gave us the complete picture at the very beginning and helped us establish the right focus.
One of the low level fundamentals of every design system is how styles and other brand elements are defined and applied. We chose to use a combination of layer styles for colors and typographies to ensure that once changes are applied properly, they affect profoundly and consistently the whole design. And since most of the tools in our design arsenal provide a plugin ecosystem, it makes absolute sense to leverage this and deliver on the brand promise with just a few clicks.
Another cornerstone of a design system is how easy it would be to configure an element of it. If we dissect an input element for example, what styles would it support? Will it support light and dark variants? Can one configure its state and layout, or tweak the text and background colors, for example? Symbols, a concept supported by the majority of design environments out there, provides the means to do it, but deciding how much flexibility to give to the user of a design system is our responsibility.
InfoQ: What have you learned from using design systems?
Ivanov: From my experience using design systems I learned that we often set our own boundaries and don’t see beyond them. Quite often the role of the user researcher or the developer is ignored, as all you have at hand is a UI Kit, which in my opinion is limiting rather than empowering because it leaves the designer-developer handoff gap wide open.
A true design system should take a different approach and enhance the workflow of every role in the product development lifecycle by establishing a common vocabulary. How could we claim then to foster communication and collaboration when we look inside our small little box and not outside of it?