DesOps, aka. DesignOps, refers to an approach to design that is inspired by the culture of DevOps. In this and the following posts, we will explore, the practical approaches for
- How to prepare for the next wave in design that compliments the DevOps concepts of a cultural shift, collaboration, and automation.
- We will also see what solutions are available today that contribute to bringing the full circle of design in the context of the software development lifecycle.
Today, design as a discipline is getting more and more recognition across the entrepreneur world and many industry efforts, such as IBM's Enterprise Design Thinking framework, Red Hat's Open Studio and similar ones, are at a large scale, trying to create a synergy between the Agile approach to the software development lifecycle and the Design Thinking. It is an interesting crossroad where the next big thing in product delivery is to bring scalability as well as automation to the creative process.
In the context of the software industry, I always see “design” as an intersection between creativity and technology where both shape each other—with help from user needs—and blend the results into successful products.
Any typical software product that is delivered involves many complex as well as divergent technologies, processes, people, and visions. Though software delivery mostly happens with team members segmented into two major groups—developers and designers—ultimately, the best outcome always depends on how the two teams communicate with each other and how efficiently their thoughts and ideas are shared, propagated, and translated.
When it comes to product development, the amount of complexity and the variety of aspects—from diversified thinking, technology, tools, and processes—that go into it, are significant. Attempts have been made over to improve various aspects to ensure the delivery process can be optimized to scale up to ever-expanding needs. In the software and IT infrastructure industry, recently one such phenomenon is DevOps, which focused on rethinking development and operations to improve productivity and efficiency.
DevOps started near the end of the first decade of this century. Back in 2008, there was a fine separation between the roles of who would code and who would deploy software. Basically, the coders were responsible for code generation while the infrastructure guys looked after the process of deploying software.
Due to the rise of the Agile process, code generation and deployment as a part of delivery became more frequent and continuous, unlike the age-old waterfall model when the cycle used to happen every six months to a year. In all major software services industry, it was common to have fixed calendar dates that represented software releases. The two-to-three-week sprints of the Agile approach made such cycles obsolete in many ways.
As continuous delivery became the de facto standard, it narrowed the gap between the development team and the infrastructure team. This change also gave rise to the need for multidisciplinary roles or individuals who could bridge the gap between the production environment and the development server, allowing their code to be deployed in a more efficient way and faster. As the DevOps movement took shape, the practices around it grew from a few talented hackers to a profession with a culture of its own involving its own set of tools, practices, technologies, and workflows that has become the norm in the industry today.
Today, most of the DevOps approach focuses on the process blocks that mostly impact engineering or technical aspects of the product rather than on the design aspect. To bridge that gap, many attempts are being made to define a consistent approach called DesOps.
DesOps or DesignOps is a relatively new term. To comprehend DesOps better, many refer to DevOps, which has similar underlying philosophies and goals. DesOps is a relatively new concept, yet it is a growing area of concern for designers seeking to help their teams increase the value they produce for their organizations and their organization’s customers. However, DesOps practices have been inconsistent in many attempts made by different organizations for many years.
Even when we try to implement a DevOps-geared process to run a design-driven process model, the challenges, such as the gaps between design and development or between design and testing, are not fixed. Without implementing DesOps to fix the design process, the implementation of DevOps will never yield the desired outcome and will not be able to sustain the core philosophies behind it.
DesOps and DevOps are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and, thereby, contribute to DevOps. For example, aspects such as the testing of the product involve design aspects, usability, accessibility, and so on. In the testing phase, benchmarks are needed to act as a referee; that can only come from a process where DesOps has implemented the output and then feeds the benchmark to the DevOps phase where the testing block can use it. In addition, when we use the Agile or iterative delivery process models, at each sprint cycle the end-to-end flow is executed, thereby making Continous Integration (CI) and Continous Delivery (CD) truly meaningful.
DesOps was primarily born out of the primary need of how to design at scale. The factors that shaped it are of similar to what shaped DevOps. With software delivery in recent times, with the Agile process, CI & CD including Continuous Deployment, the DevOps approach provides a faster highway that ensures faster delivery with lower risks. So the earlier software development lifecycle model got redefined from Agile to DevOps in its current shape.
However, because the design is an integral part of any delivered product, the gaps between the traditional design lifecycle and the fast-track DevOps development lifecycle need to be bridged. The need for tighter integration between the design team and the engineering team is a necessity to ensure design at scale. In the past two or three years, the top five big technology companies have made heavy investments in this area and have paved the way for other organizations and design communities to be more explorative in this area. The implications of DesOps are reflected in the outcome, where the silos among the teams and disciplines are reduced. Along with this, DesOps improves the collaboration among cross-functional teams and working practices, which contributes to minimizing waste in the delivery process.
Historically and interestingly, in the beginning, DesOps—without its formal name—focused on the areas of creation and maintenance and the sharing of its modular design systems. In the last couple of years, it has been more about organizations having design systems and making these socialized. Primarily, these design systems have consisted of visual design languages and components and widgets. These design systems have defined basic goals, principles, branding (for specific organizational identity), and a visual language that helped maintain consistency in the creation of design artefacts and assets. Along with that, the UI patterns and widget libraries included helped to bring consistency in terms of interactions across a wider scale of interfaces within an organization or product portfolio.
Ensuring this consistency became part of a strategic aspect of an organization's user experience goals, and the design team was responsible for driving this. Mostly this task became a primary part of the roles of Design Director, Lead, and Principal roles in an organization as a part of their goal to ensure bringing the right maturity to their design team and practices.
This was definitely low-hanging fruit in terms of what the DesOps principle is geared towards. The return from such low-hanging fruit was helpful in many ways. Apart from consistency, it helped reduce the friction among teams regarding the design aspect. Also, it helped to reduce some aspects of operational inefficiencies in the design workflow and to reduce waste, thereby helping the team to deliver at a faster rate.
However, design work practices, unlike the practices of the development domain, are more diverse and design is the area with the most creative energy in the whole lifecycle. So, the challenges of ensuring the smooth amalgamation of the design systems into the process blocks of the workflow were not easy. The fact is, it is still a challenge to fit the existing tools to the design workflow and then align that to the whole delivery track fueled by the DevOps paradigm.
Recently, the design team at Airbnb came up with the React-Sketch App open source library. Last year, at Red Hat UX team meet-up summit, as a part of a design challenge initiative, I presented a concept called Ditto, which was supposed to redefine the way the design can be integrated into a DevOps supported environment. I will share the details of Ditto in future articles in this series. Recently, Clearleft came up with the Fractal open source tool, which tried to reduce and even remove the distance between the design and development teams. Note that both DevOps and DesOps were 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 that the technological approach of using “the single source of truth” can be a good starting point towards building a practical DesOps culture in an organization. Because the soul of DesOps is based on the cultural shift and practices that work towards CI and CD, it makes sense to use 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, the typical three pillars of any framework also fit here:
1. Consistency: In the context of DesOps, consistency plays the major role both in the approach and the workflows as well as from the design perspective.
2. Continuity. This mostly fuels the continuous design aspect that provides agility to the design process.
3. Complimentary. There is no doubt that as DesOps completes the full circle, it complements the vision of DevOps.
In my view, DesOps is not only about the tools or technology employed—which generally refers to the discourses for bringing automation and improved process re-engineering in the engineering sense; rather, DesOps is about defining a culture of design through improved work practices; communication between the design teams and within and outside the project/product teams along with the stakeholders; and about aiding these practices—with the help of technology to enhance communication among the involved tools and the overarching eco-systems.
Stay tuned and be part of the DesOps journey with me.
