Talk at RH UI/UX Community of Practice: DesOps 101-Overview

DesOps 101: Overview

 Community Calls 

The talk will focus on overview  DesOps.

Three key takeaways:

  1. Background and overview of DesOps.
  2. The high-level overview of the different dimensions of Design operations
  3. DesOps from Service Design point of view
  4. Samples/Examples
  5. Cultural dimension and Open Org aspect.

Date & Time: 12:AM – 1 PM  on 10 Nov 2018 (IST)
Venue:  Virtual Community call over BlueJeans.













The Future of Design Systems: CDN Based Open Design Eco-System


When we talk about an open world, we inherently refer to an attempt towards making it possible so that all the entities in that eco-system can talk to each other. It would involve peopleprops and processes – the typical 3 components we use in a service design model (

Any service design tool helps to find out the touch-points and what is happening around that with the user at the center through tools like Empathy Maps, User Journeys, Service Design Blueprints and so on.

However for a future world of automation and machine learning, it becomes critical to ensure that these touch points are also considered the other two i.e. props and processes at the center. The DesOps is practically all about finding out this and enabling those touch points through the act of optimzing, reducing or removing them, to improve the operation.

In the same context we look at the design systems in use, (e.g. in a visual design and UI design and development scenario – a branding guideline, widget library, collection sample code organized in someway) also are part of bigger eco-system, where the future automation of design with machine learning they need to talk to each other. Being a set of “prop” they need also to interact with “people” and “processes”. This means, a design eco-system of future should be open, where collaboration from “people” or the “designers” is made possible where design systems follow a common model to become part of the common language.

At the same time the design systems should semantic so that the machines can infer them and take logical decisions (read:

Then how to achieve this?

One of the possible way, as I see is to build the open design “eco-system” with the two components in them.

The first one is a Content Delivery Network (CDN) that would allow different design systems to share their content for reusability and collaboration against some namespaces (or an identifier path )

Secondly, it should follow a model that is scalable, extensible and can align to semantic model. One such model as I was writing about earlier is the Nuclear Design Model. (read )

So the Open Design (Eco)System would be combination of a CDN with a Nuclear Design Model.

To achieve this in design dimensions of different domains e.g. UI design, Visual Design, Branding, Voice based System Design, Business Process Design, Service design, Content Design, Learning or Instructional Design, System Design etc. etc. we need to use different technologies, framework and methodologies depending on the area it touches upon, and I think this would is a great opportunity for all service designer in today’s world to explore these and define.

In the UX India workshop I took an example case of UI design and development scenario targeting web technology, and attempted on a Proof -of – concept (POC) using HTML, CSS and JS.

I created a basic css representations of the Nuclear Model using CSS3 Variables, that allowed modification of properties which was an essential part of building an inheritance model of properties.

So I started with a basic bucketing of the entities at a conceptual level, with a namespace model and folder structure.

ODS-Global was the global namespace tagged to a folder that contained two set of entities i.e. Tokens and Primitives.

In Tokens (representing properties and attributes) I kept all the list of tokens without assigning them to any particular entities. Then under Primitives, 3 main primitives were defined (namely Shape, Image and Text), where each one defined which tokens belong to them.

Then each design system created by anyone would have a separate namespace folder under which there are buckets/folders for each entity type, namely :

Tokens – set of properties or attributes defined with default values

Primitives – applied a set of selective tokens

Derivatives – these are derivations from any primitive with modified values to the tokens they are associated with)

Patterns – combination of derivatives in an integrated way

Template – combination of patterns.

Views – combination of templates.

The above diagram shows the conceptual structure and how inheritance is happening based on the approach mentioned above. This conceptual structure now can be represented in CSS , HTML and JS as following

And the following image shows how the entities get their default properties and if needed over-ride them while maintaining the scope of their entities.

See how in a design system DS1 the properties change, keeping the same list of tokens intact, to provide one-to-one mapping among the design systems.

When I translated this into CSS and HTML and JS structure, I got the following structure of folders and files for the POC.

In the actual application, only referring to the namespace and type of entity is good enough to load the right pattern from any design-system part of the open design eco-system.

You can download and play around the code of the sample above from github:

Note: this is a prototype of the concept and is not optimal for any production usage. Ther are a lot scope to improve the implementation. For example usage of @import in CSS in real time may not be practical, but it might be good idea to write a preprocessor that would build the final CSS and JS from the namespace, like NPM.

Here are some screenshots from actual POC we ran in the workshop:

The following a example of pattern called “label” from a designsystem namespace “com-company1-ds1” . This is made with derivatives from 2 basic primitives i.e. “Shape” and “Text”.

The following a example of pattern called “button” from a designsystem namespace “com-company1-ds1” . This is made with derivatives from same 2 basic primitives i.e. “Shape” and “Text”.

The following a example of pattern called “editable-textbox” from a design-system namespace “com-company1-ds1” . This is made with derivatives from same 2 basic primitives i.e. “Shape” and “Text”.

The following a example of a template (not created a formal template class though ) of a login form from a design-system namespace “com-company1-ds1” . This is made with patterns from same namespace.

Hope you enjoyed this quick and dirty article written in 30 mins. If you get the concept from the article, my goals are met 🙂

Download the sample code to play around from here:

View the part 2 of the workshop slides here that is related to this activity:

You can view the first part of the slides of this work shop here:

You can explore more here:

‘Semantic Design System : Redefining Design Systems for DesOps’

Nuclear Design:

Open Design System Ontology:

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license







[Workshop Deck] PART-1: Applying DesOps in Your Enterprise

[This is the first part of the half-day workshop titled “Applying DesOps in Your Enterprise” I conducted at the “UX India Conference 2018” on 4th October, 2018, Bengaluru. This part focused on ‘Process’ aspect of DesOps, and tried to address the challenges of bringing the designers to the same page to that of diversified subject-matter experts (SMEs) during the ideation phase of an Design Thinking workshop, by collaborating on “Petal Process Diagram”(PPD) . PPD is a mind-mapping kind of activity with the focus to involve all the entities involved in and around a touch-point in a feedback-loop, and helps everyone in the room to be on the same page on the potential possibilities, feasibilities involving “props” and “process” components.

You can explore more at ]

Continue to the next part of the workshop, in the next post.

Meanwhile, you can explore more here:

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license



[Slides] DevConf 2018, Bengaluru : DesOps – Prepare Today for Future of Design (2018)

DesignOps is an approach to design inspired by the culture of DevOps. In this session, we will be touching upon the practical approaches on how to prepare for the next wave in design that compliments DevOps in the concepts of the cultural shift, collaboration, and automation. We will also see how to bringing the full circle of design in the context of software development lifecycle.

Topic: DesignOps – the Prepare Today for Future of Design!
Date & Time: 2:15PM – 2:45PM on 5 August 2018
Venue: Christ University – Bengaluru, India

Event: 2018 is the second free annual community conference sponsored by Red Hat for Developers, System admins, DevOps engineers, Testers, Documentation writers and other contributors to open source technologies. It is a platform for the local FOSS community participants to come together and engage in the knowledge sharing through technical talks, workshops, panel discussions, hackathons and such activities.

More info at:

External Post – DesOps is “DevOps 2.0”

DesOps is “DevOps 2.0” . Read it at Red Hat Developers Blog here –


… With recent software delivery processes, for example, the Agile process and Continuous Integration (CI) and Continuous Deployment (CD)of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over time with Agile and then with DevOps to its current shape.

However, because design is an integral part of any product delivered, there is a need to ensure that gaps are bridged between the traditional design lifecycle and the fast track of the DevOps development lifecycle. DesOps and DevOps both are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and thereby contribute to DevOps, for example, in aspects such as testing of the product that involves design aspects, usability, accessibility, etc.

The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During the past two to three years, the top five big companies have made heavy investments in this area that have paved the way for other organizations and design communities to be more explorative in this area…

Read the full post at