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 -2) : The Nuclear Design Model

[NOTE: Check the part 1 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

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