Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

DesOps - The Next Wave in Design

June 22, 2018
Samir Dash
Related topics:
DevOps
Related products:
Developer Tools

Share:

    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.

     
    (Note: Based on my book The DesOps Enterprise: Overview & Culture)
    Last updated: November 8, 2023

    Recent Posts

    • Skopeo: The unsung hero of Linux container-tools

    • Automate certificate management in OpenShift

    • Customize RHEL CoreOS at scale: On-cluster image mode in OpenShift

    • How to set up KServe autoscaling for vLLM with KEDA

    • How I used Cursor AI to migrate a Bash test suite to Python

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue