The Living Design System is mostly perceived all about modular design. Mostly the patterns, being the referred as the “molecules” or “organisms” as a part of “atomic design process”, are made to allow the part of structure or group. This view of the living design system brings to focus, its two major aspects — first is, of course, the creation and maintenance of patterns. The later is about coming up with a process and ensuring that these fit into a workflow that both would touch both designer and developers and make the connections among their workflows. However, this latter aspect has remained challenging even for the experienced teams across the industry.
Historically and interestingly, DesOps at the beginning, without its formal name was focusing on the areas of creation and maintenance and sharing of its modular design systems. At the very beginning phases in last couple of years, it was more about the organisations having the design systems and making these socialised. Primarily these design systems have consisted of visual design languages and components and widgets. These design system had defined basic goals, principles, branding (for specific organisational identity) and a visual language that helped it maintain consistency in the creation of design artefacts and assets. Along with it the UI patterns and widget libraries included in them helped to bring consistency in terms of interactions across a wider scale of interfaces within the organisation or product portfolio.
Ensuring this became part of the strategic aspect of any UX or Design team, in the organisation that was responsible for driving this. Mostly this task became the primary share of the role of the Design Directors, Leads and Principals in the organisation as a part of their goal to ensure ringing the right maturity to their design team and practices.
This was definitely a low-hanging fruit in terms of what DesOps as the principle is geared towards. The return from such low-hanging fruit was helpful in many ways. Apart from the consistency, it actually helped in reducing the friction among the teams regarding the design aspect. Also, it helped to reduce some aspect of operational inefficiencies in the design workflow to some extent and helped in reducing waste thereby helping the team to deliver at a faster rate.
However the design work practices, unlike the development domain are more diverse and being the area with the most creative energy association in the whole lifecycle, the challenges to ensure the smooth amalgamation of the these design systems to the process blocks of the workflow was not easy. The fact is till the date writing this passage, it is still a challenge to fit the existing tools, to the design work-flows and then aligning it to the whole delivery track fuelled by the DevOps paradigm.
Recently the design team at AirBnB, came up with React Sketch App. Last year at RedHat UX team meet up Summit, as a part of a design challenge initiative I presented a concept Ditto, that was supposed to redefine the way the design can be integrated into a DevOpssupported environment. Will share the details of Ditto in coming articles of this series. ClearCleft also in recent times came up with Fractal that tried to reduce and even remove the distance between the design and development teams. Note that both the DevOps and DesOps are born out of similar drivers, however, the practices concerned with the two are very different.
From the example of Salesforce’s approach to design, the takeaway is the technological approach of use of “the single source of truth” can be a good starting point towards building a practical DesOps culture in the organisation. As the soul of DesOps based on the cultural shift and practices working towards Continuous Integration (CI) and Continuous Delivery (CD), it makes sense to use the living design systems as the foundation of the overarching concept of DesOps.
To understand the overarching structure of DesOps, we need to explore the various dimensions that give the concept its shape. From a framework point of view if we look at it, the typical 3 pillars of any framework also fits here —
1. Consistency — in the context of DesOps the consistency plays the major role both in approach and workflows as well as from the design perspective
2. Continuity — mostly it fuels the continuous design aspect that provides agility to the design process.
3. Complimentary – no doubt as DesOps completes the full-circle, it complements the vision of DevOps.
In the next article, we will dive into the different models associated with the DesOps framework.
(c) 2018, Samir Dash. All rights reserved.