Talk at DesignOps Global Conference 2019 , Manchester, England, 30-31st May 2019

Topic: [TBD – On  DesOps /DesignOps ]
Date: 30/31 May 2019
Venue:  Manchester, England

Super excited to be part of DesignOps Global Conference ( to share ideas with some great minds on hashtagdesignops hashtagdesops hashtagdesign and the future of hashtagdesign from the lens of hashtagopenorg culture and hashtagdesignthinking being applied as the way of life to improve and optimize the operations in the organizations to deliver the “wow” experience, through best utilizing the hashtagprocess and hashtagecosystems and hashtagtechnology in context. Thanks, Peter Fossick. Looking forward to a series of engaging sessions for every hashtagdesigner / hashtagleader.


About the Conference:

The DesignOps Global Conference is for design leaders, developers, practitioners, product managers, service innovators and business leaders that are defining the way we design and develop new products and services. Join us Manchester for the DesignOps Global Conference 2019 Agile and Beyond – New Frontiers in Design
30 + 31 May, 2019

The themes for this year’s DesignOps Global Conference are:

  • DAY 1
    • Theme 1: DesignOps and the impact of design
    • Theme 2: Collaborating at speed and scale
  • DAY 2
    • Theme 3: Developing new cultures – developing new organisations
    • Theme 4: DesignOps in the era of AI and cognitive computing

More details of the event and to get the pass visit









DesOps 101: Overview

[This is part of the slides I used in Community Call at Red Hat UI/UX Community of Practice on 9 Nov 2018. More details :]

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

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-2: Applying DesOps in Your Enterprise

[This is the SECOND 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 ‘Design System’ aspect of DesOps, and tried to address the challenges that designer face when they collaborate using around either two or more design systems. Neither of the design system as of today talk to each other in the same way, nor is the fact that that none of the design systems organize and define their patterns in the same structure.

This part of the work shop attempts to solve that issue through introducing the concept of “CDN based Open Design Eco-System” (* CDN – Content Delivery Network) that is modelled on a Nuclear Design Model which can be scaled up and be made semantic, so that the automation of design process can be made possible. In the workshop we also see an implementation or a proof of the concept for the web-design and development domain using HTML, CSS and Javascript. This uses CSS3 variables to implement an extensible framework based on the Nuclear Design Model.

The code can be downloaded from .

You can explore more at and

Workshop at UX India International Conference 2018 : Applying DesOps in Your Enterprise




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



Workshop at UX India International Conference 2018 : Applying DesOps in Your Enterprise


Applying DesOps in Your Enterprise

3 hrs Workshop | Category: Design Practice & Process | Target Audience: Anyone who is interested in optimizing the processes used in the enterprise or building solutions that focuses on process re-engineering is the most suitable audience for the first part of the workshop.   Any User-Experience pro,  Design Thinker, Service designer, and product-management professional can be benefitted. The second part of the workshop is helpful for the designers and UI developers who use the design system or would like to build a scalable design system for their organization or team. Basic understanding of HTML and CSS is good enough for the 2nd part of the workshop.


The workshop will focus on two aspects of DesOps, namely the process and eco-system. The process aspect will be identifying touch points in the enterprise, and try to optimize that with some solution using technology. The ‘eco-system’ part of the workshop will focus on building a sample design system using Nuclear Design Model to make it scalable and extensible.

Three key takeaways:

  1. Basics of DesOps from process and eco-System Angle.
  2. Learn about how to identify touch-points in the process /workflow that can be optimized to bring automation or technological solutions.
  3. Learn about the basics of Nuclear Design Model and applying to build open, scalable and extensible design systems.

Date & Time: 10:AM – 1 PM  on 4 October 2018
Venue:  4, 5 & 6 October 2018, ITC Gardenia, Bangalore


Event: UX India International Conference, 2018, A day full of inspiration and learning for user experience designers, UX leaders, visual designers, user researchers, front-end developers, program managers, startup founders and design students. Grab an opportunity to grow and network with UX Design industry experts. It brings engaging industry leaders to present a combination of inspirational talks and personal experiences.



Slides :

Sample code of the CDN based Design Eco-System POC using CSS Variables: 


Two Parts Articles:

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




Open Design System – Adding Semantics to Design System (Part-3): Heredity and Inheritance of Attributes

The word “evolution” was first found to be used around 1647 which was more popularised by the Naturalists towards the end of 18th century who upheld the age old pre-socratic Greek philosopher Anaximander’s view that humans must have evolved from an animal and this evolution must have sprung from sea. From Darwin’s theory of evolution, we see two important characteristics :

  1. In the eco-system the individuals of the same species are likely to differ in their measurable characteristics
  2. Such kind of variations are inherited (heredity).

For any complex and growing (evolving ) echo-system when we try to find the model to explain the behaviour of evolution, these two characteristics helps build a model that can provide meaningful reasoning behind the complex variations that exist.

Darwin’s The Desent of Man was more focused on hypothesis that variations are transmitted from parent to the off-spring, though it was a few years after established.

During mid 19th century, Gregor Mendel’s extensive pea-plant breeding explained and came up with a meaningful model.

This model was able to interpret and explain Darwin’s hypothesis around hereditywhere it toys around the questions such as —

“is it possible that an animal having, for instance, the structure and habits of a bat, could have been formed by the modification of some animal with wholly different habits? Can we believe that natural selection could produce, on the one hand, organs of trifling importance, such as the tail of a giraffe, which serves as a fly-flapper, and, on the other hand, organs of such wonderful structure, as the eye, of which we hardly as yet fully understand the inimitable perfection?”

The natural life-forms and their associated complexity of variations, basically, was well explained by the model of heredity. The moment we envision a design-system that can explain the variations in life-forms, it would be no surprise to be in similar lines of what Darwin had deduced. In the similar lens, when we take the case of any design-system, we see similar attributes. The variations of any entity can be explained with inheritance of attributes from parents.

Irrespective of the typical design system maturity level, in order to make a design system scalable, it should have this very characteristic of having the model to define variations and inheritance.

In typical sense of “design system”, as we refer in our day jobs in techno-design industry revolving around software application and related eco-systems, we face the use-cases that are the tip of the iceberg of the operational problems we face in a design process. The activities like, the categorization of UI patterns and mapping them to the user interface needs, manual export of the semantics while different teams work on different tool-chains especially in open and collaborative design scenarios along with long hours of religious debates” of the utilitarian values of widgets proposed to be used against the variants that are in the implementations, are some of such examples, which has become the part of the job, where unaccountable time, effort and of course organization money become under-utilised.

Design System help generalize the the diversified aspect of patterns we use in design. But, the offshoots of the design systems across the industry, to cater to the need of the individual organisation, who are developing them, are not solving the issue of bringing a normalization, rather they are making it more distributed. There are no two design systems that are equal in structure or in the approach they follow to define the patterns in them.

So the “design system”s which are supposed to be a “common-language” for their respective design process that every team member can adhere to in order to produce a consistent design, do not have a “common language” among themselves.

Along with that, none of the design systems, as of today has a model that can help explain any other design system. Even, the basic smallest pattern or the building button, they define, does not explain the variations we see across cross domain, organization and technological context.

A simple case of a “button” pattern, does not seem anymore simple, where we try to connect the dots between the variation we see regarding that.

For example how is a button different from that of a toggle button, or a text-link or a simple radio-button? Even a simple hyperlink with some background color and cursor properties can cloak itself as a mental model of the user defining the concept of a ‘button’. Also the technological dimensions to variation can span beyond the technology used, platform it is rendering and the framework or language in play.

This is a perfect example even in such a narrow definition of a design system (i.e. a pattern library for UI or a basic brand-system or style guide), how it is fit case for the need for a model to define these variations and inherent relationships among the entities to explain in a logical way how these variations are linked to each other.

(Fig. Ref:

When I think about the Design System, it’s not limited to the UI or brand library typically that we refer and try to define, rather, being a part of DesOps mindset, where every organization is a Design Organization (as every organization is in employing creativity in solving the problems for its customers through its products, services etc. ), it spans across and touches different and diversified domains, technological dimensions and information spaces.

(Fig. Ref:

For example, a design system can be a knowledge system for system design meant for developers, technical architects, data scientists. Similarly, a design system can define the elementary components and practices for process design – e.g. the elementary blocks of a Design Thinking framework like that of IBM Design Thinking framework can be explained and built using such approach. Or the design system can also cater to the need of the intersection of specific industry need and technological domain at the micro level — e.g. a design system that can define the model for a color system needed for specific type LED monitor manufacturing industry. In all these scenarios, the task becomes critical to define a model that can stand for this “universe” what we refer as a “design system”, where we can branch out or fork and build the shared meaning that can span across all diverse disciplines, domains, technologies and methodologies.

(To be Continued to the next post)

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

Previous post of this series:

You can also explore the following links:

‘Semantic Design System : Redefining Design Systems for DesOps’

Nuclear Design:

Open Design System Ontology:

Open Design System – Adding Semantics to Design System (Part-2): Roles of Pattern Library in Design Automation

In search of a tool that can minimize the translations of values, in context to UI design space, I was toying with an idea of Dittoa simplified version of the tool that can look familiar to the different roles involved in the process and at the same time it will align with a process that is about having the same source files at any of the stages of the process and can align with any design system with easy configuration mechanism.

This approach of Ditto was mostly about the conversion to application code via using a controlled configurable UI pattern library serving as the base element for a dynamic IDE that would help to reduce the gaps between the roles.

The idea involved a ‘single source’ based process that can work with standard pattern-libraries/design-systems.

Earlier to this, back around 2013-14, I had experimented with conversion of design files (PSD/AI/PDF etc.) to style guide through prototypes like Specstra as an early attempt to bring automation into design process to reduce the manual intervention around drafting style guides.

This was another different kind of approach, similar to which there are many solutions are available including Adobe Extract and Avocado etc.

Sometime back, while conceptualising the BetaStudio that focused on envisioning the automation aspects to include the usability dimensions of application testing as a part of an automated eco-system more aligned to DesOps mindset, I was playing around OpenCV and its ports in JS that can have a different perspective than my earlier approach to define a set of design benchmarks (the 1st circle in the stages defined in below image) to compare against the models/metrics towards the later part of the stages.

But this time I wanted to explore apart from the two above said approaches, there can be any other practical approaches, which can help building a UI design-automation solution component for the flow. For this I came up with a conceptual workflow “Pattern-AI” that involved some image recognition through a live camera and matching that for potential UI patterns by processing the camera input using computer-vision technologies, as shown in the flow below:

Based on this my set up was very simple, good enough for a hello world type validation of the concept, having a webcam output, being processes through a Kinetic based web application running in Chrome, which tried to identify the matching pattern (a simple image, icon and button ) drawn on the paper to that with a predefined pattern array with those object names. Though I never went beyond just matching the name, it was obvious that as I was able to match a pattern, generating a predefined HTML-CSS code was a piece of cake post that.

This experimentation helped me to later see that possible variation on this line can also be a part of the high level vision of bringing design automation especially in UI design space, like a missing puzzle piece.

However, this also made it clear that whatever, the potential approach might be, finally what we need is a “consistent and scalable design system model” that is essential to ensure whatever is getting translated from the different types of source through any of these various approaches, as that is the point where all these information is getting mapped and the meaning of each pattern is formed.

The basic questions that arise from these were…

When the system gets a clue from the input/source design (or hand-drawn wireframe) as a dropdown, can it consistently map it to a target design system or a pattern-library or even a brand-system based widget-library consistently?

Also even assuming that it does able to identify the pattern, for example as a button , how it can select or define the target implementation code a in a consistent manner? In this example case, a button can be defined as a <input type=’button’ /> or <div id=”button”></div>or even <button></button> etc. ?

This was an eye-opener, as it was clear from this that, irrespective of the technology used, and irrespective of the methodology is used to generate the required information for design benchmark, without the essential “common language” among the design-systems in use, the translation of those information/artefacts might not make sense to the systems running the automation. And this is where the whole purpose of DesOps mindset will fail.

This actually hints on a problem statement about the gap that currently our design systems have — i.e. a consistent way to define the patterns (and note this is not just limited to UI focused design-system) that can be scalable, and coming up with some approach to bring “semantics” to the design-systems in focus.

We will dive more into it in next posts. Meanwhile you can explore these links:

Previous post of this series:

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

#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso

Semantic Design System (Part -3): The Open Design System Ontology

[NOTE: Check the part 1 at : and part 2 at]

This originally part of a talk I gave at UX-India Pre-Conference Meetup at Symbiosis College, Bengaluru on 1st September 2018, titled: Semantic Design System — Redefining Design Systems for DesOps . The talk explored the existing implementations of design-systems and will be making an attempt to provide high-level approach to define design systems for the next-gen enterprises.

“Design System” plays a critical role in bringing a common language and consistency in experience across different products and brands of the organisation, along with fuelling a collaborative approach towards design, making it easier for different team members to contribute.

(Continued to next post. )

#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso

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