By definition, a Design System is a series of components that can be reused in different combinations to manage design at scale. In the context of software development lifecycle specific to digital products e.g. apps, applications and websites etc., the design system can contain design guidelines, visual style guidelines, assets, components, widget definitions, form controls, interaction paradigm definitions etc. at a different maturity level touching upon different roles starting from the interaction designer, visual designer to prototyper as well as the developer.
Many organizations have the pattern libraries clubbed with some best practices and guidelines used as a Design System for the organization and the community — for example is one such example is RedHat’s PatternFly. When you visit PatternFly website, you find it a typical design system that has different components including interaction paradigms, widgets, working code, visual style guides and assets touching upon many roles involved in the delivery thread. Similar is the case with lot other popular design systems. Among popular Design Systems as of today, most notable are: Google’s Material Design, BBC’s Gel, SalesForce’s Lightning, AirBnB’s Design Language , IBM’s NorthStar and so on.
To normalise practices and design patterns around a common visual language, style guides, pattern libraries, design systems play a critical role. Design systems can vary in maturity. With purpose, I have mentioned the case of “different maturity” — it means that the variations of the concept of the design system are already in place, and each of those variations has a slightly different efficiency to solve the common goal of designing at scale. at the bare minimum level, it can simply start with naming objects, colours, texts, components and conventions or even best practices. This can scale upto highest maturity level, where it can define finer details of the experience and even can end up in generative solutions in themselves — e.g. frameworks which may dynamically provide or define the experience details required for delivery.
Design Systems have been so popularised, they are arguably a default need of any product organisation of even limited scale. This usually becomes the very first push by an organisation to begin looking at their design operations with fresh eyes as introducing a design system brings with it a whole set of new problems that most digital product design organisations were previously ill-equipped to deal with on their own. The success of the implementation of a design system will ride on the support it gets operationally.
No doubt, Design Systems are a primary need for the organisation even on a limited scale and budget. However, the design systems mostly are developed within the operational vacuums. Have the best-designed components, but if you can’t create a workflow for their upkeep and deployment not just through your product offerings, but through your design production system itself, it will invariably cause more friction than the previous system did.
When you start with the pain point of a Design Systems, you are starting your operations with a solution to a specific problem. This lens answers the question — “How do we scale design quality through the enterprise?”
Why We Need Design Systems?
By nature, a Design System helps taking decisions faster and reduce wastage in delivery track. This thereby helps the designers to spend more time in defining workflows. Also as it helps to work in a fast track mode, it also promotes the designers in exploring multiple concepts in the same amount of time.
Having a Design System is to have a “single-source-of-truth”, which can be referred by all different roles including engineering, testing as well as designers throughout the delivery lifecycle. This helps in articulating as well as implementing consistency across different modules of the application or even in the product line. However to ensure the Design System acts as a “single-source-of-truth”, certain criteria need to be fulfilled — and this is also the crossroad where a Design System that acts as the “single-source-of-truth”, paves way for DesOps.
Design System as “Single-Source-of-Truth”
Let’s first understand what do we really mean when we refer Design System as “Single-Source-of-Truth”. In the enterprise, any design on the hindsight has one major alignment — i.e. to align itself to the business goals or the enterprise, which also drives the product strategy as well as the delivery and impacts a lot of associated aspects such as the delivery life cycle that includes the typical Design, Development and Quality tracks. In most of the cases the associated operational systems which are made up of processes, practises and tools are mostly development centric. The traditional SDLC models were designed more from a process perspective that had the bias towards development aspect of the delivery. So when a Design system is typically established in an organisation, the normal tendency is to create a Design System that fills the gap between these different entities and their associated process blocks. The Design System that touches all these associated entities and the process blocks in a way that helps in optimizing the delivery of the product or in improving the quality of it, by becoming the single driving force of design aspect (from the creative problem-solving aspect ), can be regarded as a “Single-Source-of-Truth”. But in reality, as the different roles like the Designer, Developers and Quality Assurance team members, each play within their boundary of age-old definition of processes. The tools, technologies as well as the processes used by them are so diverse and the workflow among them so disjointed that on the ground reality, that having a Design System as “Single-Source-of-Truth” has not been an easy thing to achieve.
Designer Tools vs Developer Tools
One of the key aspects is that in modern time with the use of Agile along with design-driven practices like Design Thinking and User Centred Design models, has tried to reduce the tilt toward the engineering, has certainly helped many organisation to be more effective in delivering products with the qualitative design. However, the Design System developed in many organisations by nature involves the set of tools and processes that suffer from such bias and the selection of tools and technology-driven workflows that are more developer-centric. For example, the tools like TextEdit or Notepad and the command line terminal windows are highly preferred by the developers. The workflows defined around such tools to make developers more productive and help them improve their craft which is coding. When the processes and tools by themselves are technology driven and developer driven, and when such system is integrated with the standard components of a design system like style guides, codes, widgets etc. , the generation and maintainability of such things by designer gets affected as they are from the different world with their own way of working with their own world of GUI driven tools starting from mind mapping to wireframing and creating visual assets. And this what brings the disjoint experiences to the design operations, thereby preventing to achieve a seamless full-circle of design-development operations. But the result of such design system is always like a patchwork that may not introduce the fundamental changes in the process to meet the goal of DesOps — most of which are centred around consistency, collaboration, continuous integration and continuous design. And to achieve this is actually a goal that aligns with the core vision of DesOps.
We will continue exploring the Design Systems in context with DesOps and touch upon topics like Design System maturity and Living Design System as well as the concept of generative systems, in the part -3 of this DesOps article series. So keep tuned in and do feel free to share the word!!!
© 2018, Samir Dash. All rights reserved.