Team’s Vicious Circle and Avoiding the Organization Turning into a Pack of Zombies

On the theoretical level, the interaction can be modelled based on various entities like tasks(i.e. activities users perform to reach their goals), dialogues (i.e. interaction between user with users and machines and vice versa ), rules or instructions (i.e collection of behavioural instructions ) and states (i.e. conditions present in the system ) etc. Broadly, the interactions in the team/organization involving communications and sharing among members or more specifically among the roles, though is part of the Process dimension, constitutes the components that are part of the core of Cultural dimension of DesOps.

Basically, this is all about getting answers to two questions that a typical Product Manager or a CEO of the startup has in mind :

  • Do I have the right team?
  • How do my team can be effective in communicating and collaborating at different spheres with different types of entities involved?

In the previous article, I was primarily referring to two levels of the interaction were human-to-machine and machine-to-human and how minimization of the touch-points where the translation of value happens. This is primarily about “consciously and proactively considering the exchanges between people and organizations in the enterprise, and supporting these interactions with automation and tools” (Guenther, Millan Intersection, 2013 ). Solving the challenge to minimize such touch-points are relatively easy, as it involves some aspect of technology and toolchains associated. However, the level which is about human-to-human interaction is the most complex to deal with as it does not have any technology involved in it. In the last article, we slightly touched upon the full-stack roles, that handled some aspects of it. This aspect is more about involving knowledge, skill and expertise attributes of humans involved, and some aspect of it is also involved with human-to-machine & machine-to-human levels, which are partially solved by the redesigning the process involving the technologies. However, the human-to-human interaction is more complex, because it involves the attributes of human emotions, attributes and bias and cognitive fixedness that are counter-productive for any organization heading for disruptive innovation.

Broadly these attributes are part of forming a right set of team, with the right mindset. This is broadly about what kind of team members you should be looking for and also about to implement a set of practices and rules which would help grow each team members towards the self-awareness about there cultural fitment as well as motivate and guide them to grow themselves to overcome their fixed mindsets if any.

Fixed mindsets are the roadblocks to innovation in any organization. The fixedness is part of the human attribute that acts as the vitamin for a pre-defined process oriented no-brainer’s job to bring effectiveness, but at the same time acts as cancer for innovation. Typically, the key types of fixedness that hinder having effective human-to-human interactions in DesOps organization are as follows:

Cognitive Bias: The Cognitive Bias is typically defined as a mistake in reasoning, evaluating, remembering, or another cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information. The cognitive bias is a kind of fixed mindset that sometimes also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests apart from the aspect (popularly known as Confirmation Bias) that induces the tendency to search for or interpret information in a way that confirms his/her preconceptions. This leads to the premature closing down of options in a creative process, as the person affected by this only seeks out the evidence from the information he has that was pertinent to his argument, and remains blind eye purposefully to any other information.

HiPPO effect or Authority Bias: HiPPO (highest paid person’s opinion) is one of the popular terms in the organization-productivity domain. Basically, this is more about having authority biases and the team’s tendency to attribute greater accuracy to someone how holds a higher position in the organization. Beware of the HiPPO (highest paid person’s opinion) in the room as it means that the team has fallen foul of the law of the HiPPO — When a HiPPO is in play, the organization is most likely not relying on data to inform decision-making, rather the HiPPO (highest paid person’s opinion) tends to win out. In large corporate environments, it’s easy to experience it first hand. Usually, when a group of people are trying to make a difficult decision, for which there are lots of opinions, the person in the room who is further up the hierarchy (and therefore typically paid more) expresses what they think and tries to hijack the spirited discussions to steer towards forming an opinion among the team to follow what he thinks and labels it as the team’s decision.

HiPPO effect is the biggest roadblock in interaction aspect of DesOps. If you remember in previous articles of this series I had mentioned how one of the key philosophies of DesOps is to advocate and put a data-driven decision making into practice. HiPPO Effect actually is cancerous to DesOps culture. All the efforts to implement the right process and toolchains as a part of having an effective DesOps in the organization can fail, even only this cancer is still there as a part of the work culture.

Authority Bias is in similar lines with the HiPPO effect, but this may not necessarily about the person who is higher in the organizational hierarchy or paid more, rather it is about the person, who is “seen as experts” or even as an authority in the organization or even in the team. We have an inbuilt tendency to believe those who we perceive as “experts” and usually have a deep-seated duty to authority, and tend to comply when requested by an authority figure.

For example, in typical design or UX team meetings, it is the most difficult situations for young members who are just fresh out of colleges and had to present certain aspects of their solution that are in opposite directions to what the leader of the design team thinks or beliefs. In many cases, these ideas are brushed aside by the authoritarian leader or manager sighting even some frivolous reasons e.g. “it has to improve”, “immature and not practical”, “you need to understand our design process first”, “can’t use that to discuss with stakeholders as it is half-baked design” and so on. And in such cases, most of the “faithful” designers to the leader, echo the leader’s decision and even some start advocacy to explain the logical reasons behind the leader’s reasons. Some may be “yes-men” to the leader consciously, however, some do so as they perceive the leader as the “authority” or “expert” and this allows the authority bias to be successful in killing new ideas and fresh thinkings. In many cases, the member does not realize that they have already fallen prey to such bias.

One of the most famous psychology experiments of all time, known as the Milgram experiment, provides a terrifying example of that a very high proportion of people would fully obey the instructions. Read about this 1961 experiment here: ) and here is a video of that experiment:


The Bandwagon Effect is typically a psychological phenomenon in which people do something primarily because other people are doing it, regardless of their own beliefs, which they may ignore or override.

The Herd Mentality The Heard mentality and mob mentality, also lesser known as gang mentality, describes how people can be influenced by their peers to adopt certain behaviours on a largely emotional, rather than rational, basis. Basically, when the Bandwagon effect is blended with the catalysts of emotions, it takes shape of the herd mentality. This is the most negative extreme of the Bandwagon effect.

Also, the Cognitive Bias is more induced by the Herd Mentality as the persons involved turn blind eye to the factual information which can be used for making data-driven decisions. Rather, the persons depend on the emotional ripples for taking decisions and develops a strong Cognitive Bias, thereby contributing to form the Vicious Circle in the team.

(Download the PDF of above at )

The Vicious Circle, refer to complex chains of events that reinforce themselves through a feedback loop, and it is interesting as feedback loop acts as the essential spine for any DesOps organization. The fixedness attributes in persons involved in the team essentially turn the feedback loop into the Vicious Circle that gradually cuts-off the supply of oxygen to the innovation in the organization.

In many cases, HiPPO effect or Authority Bias makes the team meetings ineffective and counter-productive. The members either fall prey to these bias, or they try to avoid conflict in the team and keep themselves safe in the organization by remaining silent (mostly by seeing the large mob of the zombies of these bias in the team. In such situation when some spirited members typically lower in the organizational ladder counter the argument of the upper ladder persons or the leader, the conflict arises, which is in most of the case becomes counter-productive for the team and the organization and becomes suicidal for the those at the lower ladders. Else, the typically the long silence follows in the team meetings when the leader explains his/her idea or viewpoint to a problem (in a tone of judgment in many cases). In both the cases, when it becomes a regular trend that when a leader of the team’s or the ideas or viewpoints from the those who are placed on the upper ladder are praised or unanimously advocated without a few valid questions and some set of team members regularly remain silence, this is a very symptom of the cancer. In another scenario, if the young minds in the team who used to have questions earlier when they had newly joined the team, have no more show any interest in questioning or ask the obvious questions where most probably they do not really need an answer or seems to know the outcome of the questions they asked, that is another alarm for the cancer.

If the team does not have a diverse-voice or the team members mostly ask questions which do not really going to impact those who asked those, and fall in the graph in questioning opinion of the leader in a productive way or some members in the team remaining silent who used to be more creative in the past (and for a long time their opinions were brushed aside and never mattered ) then the team or the organization has already become a totalitarian state and is in a serious condition that requires the fix of the culture.

This is important to remember here, that the foundation of DesOps is based on interaction and collaboration that is productive and supports innovation from grass-roots. In the trueDesOps organization, the ideas flow from bottom to top, like the seed of ideas germinate and grow as plant and gradually through continuous nourishment from the surrounding culture which turns it into a big tree with the fruits of innovation. All the process improvements, toolchain support and the technologies act as the catalyst to support such a culture. Going DesOps is about adapting to change, being flexible, adopt disruptive innovation in a measurable and informed approach. For such eco-system to be successful, it is essential to ensure the work-culture is supportive and provides motivation to the actual people who are part of it.

So where is the way out? One of the fundamental tasks of DesOps, as a Service Designapproach, is to prepare the work culture of the product team for more positive interaction in context to hum-to-human communication and collaboration so as to prepare them for the process changes that might follow up along with the aid of automation and new technologies supporting radically new toolchains. And in such cases, to avoid the team falls prey to fixed mindsets, mostly three steps can be taken:

  1. Choosing the right people with more open personal traits at the time of hiring. During the hiring process, there are many popular psychological tools and methodologies can be employed to avoid personal traits with higher index in the person, which is less willingness to take the risk, or avoid the person too much structured-perosn who is more prone towards process-oriented obedience. The new age innovation in organizations needs the product team with the people with more open and inquisitive mindset — those who have lot of questions in them with passion than the structured minds who always define the box as the red line for him as well as his team members, to play within.
  2. Always keep an eye on symptoms of Vicious circle getting formed within the team or organization. Mostly it starts with the persons who are at the top of the ladders. And the most commonly it starts with HiPPO effect. Evaluate internally if there is any change in the behaviour of the team during meetings — try to find answers to question like “Has the spirit of some members have changed?”, “Is there fewer questions in meetings and especially fewer questions to the people at a higher hierarchy? “, “Has the agreements to the top leaders’ views have increased without much discussions over last few meetings?” “Has some set of members are regularly putting up silence since a period whenever the leader of the team or people on the higher ladder is throwing the ideas?” “Has there been an increase in rejection of ideas from the grassroots ?” — These will help in forming the timely suspicion to avoid the Vicious Circle. Note, that these may seem like addon work, but this timely diagnosis is worth it, as it helps to ensure that the organization is not got cancer at its’s brain and heart.
  3. Another key aspect is to bust fixed mindset is to enable un-learning. The systematic un-learning is a key to fixedness that is more functional or structural in nature. Unlearning helps in fostering a sense of willingness that helps in opening up minds. Especially this is effective as well as critical to have the managers and the members of the top hierarchy, to develop a sense of willingness to unlearn and learn something new. Unlearning helps to put team members out of their comfort zones so that they are more willing to pursue the unfamiliar and fosters curiosity.

We will be exploring these in details in forthcoming articles of the series. Be in touch, and do not forget to share this post.

(c) 2018, Samir Dash. All rights reserved.

[Originally published on May 14, 2018 at]


Translating Value at Different Stages of Design with Minimal Waste

In 1967 Ronald Barthe published Elements of Semiology, which stands as a temporal marker of post-structuralism, where he gave rise to the idea of “Meta Language”, which in fact “beyond language” or “Second-order language” which is used to describe, explain or interpret a “First order language”. Each order of language implicitly relies on a metalanguage by which it is explained. And it is obvious that the translations between the first order and the second order never loss-less and the true meaning of the first order language is lost or deteriorates when it is represented in “Second-order language”. Design process involving multiple intersections of information communication and sharing through translation of the value (e.g. vision, idea), loses its original meaning while being translated through different tools into various forms of expressions. Also, the different roles (e.g. Product stakeholder or product manager, information architect, interaction designer, visual designer, prototyper and developer etc. ) contribute to the infinite regression of “meaning” of the value.

That’s why one of the key factors that working with developers in terms of the realization of the design has always been a big pain and non-stop iterations, and this turning in favour of the term Full-stack Designer that shares the same spirits as that of the term Full-stack Developer.

(Download PDF from )

Typically the phrase “full-stack” (or full-stack developer) refers to someone who is someone comfortable and could single-handedly tackle every layer of software development. Typically DevOps engineers and full-stack developers share the same philosophical traits — they strive for greater agility and flexibility and hint at a trend towards greater generalization in the skillset of technical professionals. In case of the full-stack designer, he grows into a cross-disciplinary professional who can handle across Interaction Design, Visual Design as well as UI Development or prototyping. This helps to reduce the gaps between the outputs from these different and the effort that goes into the translation of concept flowing from one stage to another, where there are many roles assigned to more than one persons are involved (And remember that one of the key principles of DesOps is to remove waste by applying practices like Lean models).

So if we see that one of the major focus of DesOps in this aspect involving the work-culture is to reduce the gaps between the roles and wastage thereby. The translation from one role and discipline to another makes the meaning second-hand interpretation and such process is never loss-less. Something or the other gets lost in translation, as we progress towards the realization of the value or the product.

So by implementing Lean methodologies and by striving towards having minimally sized team members with as diversified expertized to help to minimize the intersections or touch points among disciplines and roles where the translation happens. In short less need to translate the value, the less information gets lost and less is the waste in terms of value, effort, cost and time.

Going “full-stack” is one approach to avoid the waste that happens in the process that Barthe has termed as indefinite regression or Aporia . This is mostly from the roles perspective. The other approach is through process or work practices redesign to reduce the number of intersections where the translation happens. In the context of DesOps, this is significant, as it involves the interactions at various levels between the primary two entities i.e. human (i.e.people or user ) and machine, namely — from human-to-human, human-to-machine, machine-to-human and machine-to-machine.

So one of the key factors involved while implementing the DesOps in the organization is to look for process re-design to “minimize the touch points of interaction” through the principle that advocates to minimize the gaps between the roles.

Sometime back, I was evaluating some of the design systems and tools available to study the pain-points while transitioning the design concept from one tool to another and moving from one role to the other. I got in touch with many of my friends who were designers by profession in different enterprises and were at different levels of comforts with existing design and wireframing toolsets, starting from Adobe Suite to the Sketch based eco-systems. Based on the discussions, the interesting thing that I found was many of the tools being used at different organizations, are selected based on the pricing and what the team is comfortable working with, rather than with a focus to have a seamless workflow. In many cases, the cost played a bigger role and due to licence cost, some had switched from most popular design tools to the cheaper replacements. However, the biggest struggle that was there was never solved i.e. the iterations in the design process remained challenging despite the change in tools. Every change in design aspect that was iterated was facing the overshoot of the effort, time and cost. The transitions of value from one set of tool to the other e.g. the quick wireframe created in Powerpoint during the stakeholder workshops were being translated into Photoshop was actually about relooking at the layout due to the constraint that popped up while working with the specific widgets in a specific resolution that never went well the wireframe concept. In one organization, the team replaced the Powerpoint with Sketch and tried to use that to complete the process, which turned into a nightmare as the sessions ended with the people struggling with the tool.

In search of a tool that can minimize the translations of values, I was toying with an idea of Ditto, a 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.

(Figure : The common pain-points in typical Design-process  )


(Figure : Typical Design process based on various touch-points where translation happens )

Ditto is a conceptual vision of a design tool that uses UI pattern Library (which is configurable ) and understands the relationships among the components of the design system configured to create and maintain its own objects that can be rendered on a super simple easy-to-follow and familiar looking interface with drag and drop kind interactions enabling the users of different role to focus on their goal rather than figuring out how to use the tool. Conceptually Ditto was capable of taking any type of inputs and exporting different types of outputs on demand e.g. the wireframes, visual comps and ready to deploy UI coded with HTML/ CSS/JS.

(Figure : The conceptual solution, Ditto is based on a “Single-Source” based process )

(Figure : The conceptual solution, Ditto  is based on a “Seamless Workflow” based process )


Watch a video demo that elaborates the concept in context to these use-cases —

The benefit of such a tool would be to reduce the critical – dependency on any particular role in the team in order to carry out with the project. For example, assuming a startup is only having a visionary guy with a developer, he can go into the tool to drag-drop few shapes and objects in a traditional Powerpoint / Keynote kind of interface which he is familiar with and export that as a barebone interactive code/prototype that can be tested. He can continuously test and get feedback, based on which he can tweak the same source and iterate. His developer friend can use the same source to export the code in a click to use in the production. And interestingly if he makes any change, that would be updated back to the same source. Later if a visual designer’s help is taken to customize the look and feel, it would allow updating the same source that’s running in the production where the necessary changes to the code will be managed by Ditto in the background. And despite the fact that the visual designer modified the source, (which affects the internal code) he is doing that in a Photoshop kind of environment familiar to him.

If we look at this “Single Source Based Design Eco-System“, any role can enter and come out with a production-ready code, be it a product owner or CEO of the startup, or an interaction designer, visual designer or a UI developer.

The benefits of such a tool are many:

  • Seamless work-flow for Design – Developer collaboration
  • Saving on license cost as no longer it is required to use multiple design tools
  • Single source makes it maintainable.
  • The omini-change process ensures that any changes happening at any stage of design stage will automatically take effect on other stage deliverables. (i.e. assuming at if UI html code is tweaked, it will also reflect in wireframe and visual design stages without any extra manual work!)
  • Zero learning-curve
  • Single user – Single Tool: makes it easy for any of the roles can login and generate implementation ready UI output.
  • Significantly reduces Cosmetic / UI compliance issues
  • Significantly reduces the time to implementation of the design concepts
  • Boon for Agile projects where the changes are common.

Some of the components of the conceptual design tool Ditto, you might have noticed are already available in some of the design tools. For example, similar in Sketch, you can create a custom pattern library theme and use drag and drop to add them while you are designing. But, its more about customizing themes based on existing ones and exporting shapes specific CSS at the end, which is at a very lower level of maturity from a design system standpoint. Similarly, exporting existing design to HTML feature from Adobe’s Creative Cloud Extract in some sense does not take account into how certain design systems of high maturity can be fit into it so that the output can have functional interactions as a part of business flow for the UI.

But certainly, Bootstrap Studio is much closer to the concept of Ditto. It can be improved around the areas configurations and there is a need to move away from the traditional Application type UI and interaction layer so that it can align to one of the core attributes i.e. to make each user role feel familiar with the interface or rather making it easy to follow. The UI widget based WordPress-page builder tools like Elementor are closer in this regard. While talking about Eco-Systems the tools and technologies, I will write about what are the tool-chains that we can combine for different levels of DesOps implementation looking at the maturity levels of Design Systems in play in the organizations.

Well, the thoughts presented above is a practical example of conceptualizing a value communication using improvements in processes and using technology to applying regression to the touch points where the translation happens, and thereby reducing waste and avoiding loss of meaning of value throughout the design process. We will explore the aspect of communication aspect of human-to-human, that is an important part of DesOps culture. Stay tuned.

(c)2018 , Samir Dash. All rights reserved.

(This article is originally published at on May 12, 2018 at )

The “When/If – Then” Tool to Capture Hypothesis

(This article was originally published onApril 29, 2018 Linkedin Blog at

As I mentioned in the previous article, the assumptions or the hypothesis can be made as a formalized statement of “if …. then” or “when … then” kind of format. To use ensure that this is captured correctly during collaborative sessions and within the design team, I have been using the same and some variation of the same format as a tool which I call “When/If – Then” Tool. This is a simple tool that can be very effective during collaborative sessions, to capture the assumptions that form the basis of why we believe that how the certain aspect of user pain-points and user needs should be translated into solutions using specific aspects.

Basically, this tool was helpful than the traditional elaborative templates to capture assumptions, as it was straightforward and can be used with a minimal explanation to a cross-functional crowd, a large portion of such population may not be accustomed towards the use the typical Tools and methodologies. The “When/If – Then” Tool is synonymous with the typical cause-and-effect kind of flow that is understood by and large and required very minimal explanation, and can be like any other UCD tools, can be constructed using simple post-its or printed formats.

Here is a post-it version of a barebone “When/If – Then” Tool:

Following is the basic format of this tool that has primarily 3 boxes — the left hand spanning column represents the persona or the target user (even segment given a larger scope from the market perspective) whereas the right-hand side boxes represent “When” or “If” part of the assumption and the lower box “Then” forms the outcome aspect of the assumption or hypothesis.

You can download a printable PDF of the template at

Basically, the above template helps you in completing an activity to frame your Hypothesis statement that are key to the the whole hypothesis-driven design (HDD) methodology. Now it is important that this tool can be applied to two-part blocks that can be used seeing as what you assumed versus what outcome have you got throughout experimentation.

A friend of mine asked me a valid question that it is fair to assume that HDD based approach as informs the assumption as a part of the course correction, whether it would replace the research from the process? My view on this is that the research (in the traditional definition like user and market research etc. ) has a key role in the process, as it is a mechanism to inform the stakeholder to create a vision. Technically a vision, itself is a set of hypotheses formulated by the stakeholder or the product manager. So it has a unique role in the process at the beginning of each cycle of the iterative process (let’s say to contribute to new requirements that flows down from the vision) and will stay. However, the hypothesis-driven design (HDD) helps in making a formalized approach and adds a mechanism to ensure the feedback-loop that informs these research or chunks-of-research that happens along the way in a structured and non-ambiguous way that enriches the research involving the additional validation process with evidence. Which acts as a catalyst to improve the efficiency of the research in a positive way. So essentially research is happening organically throughout the process in an on-going manner.

In the next article of the series, I will continue the exploration on the same topics. Keep in touch.

(c) 2018, Samir Dash. All rights reserved.

Lean Methodologies & Hypothesis-Driven Design (HDD)

The second life-line as pointed out in the dimension of ‘Culture’ is “Cultural Shift towards Lean Philosophies” (Refer the part 5 of the current series here ). In this part of the series, we will be deep diving for the same.

Typically any lean methodologies are based two basic goals:

  1. Helping the organization understanding customer value
  2. Using the key processes of the organization to continuously increase it and work towards delivering a perfect value to the customer through a perfect value creation process with zero waste.

In the context of Design and User Experience(UX), in the seminal book Lean UX by Jeff Gothelf, provides some lean methodologies break the stalemate between the speed of Agile and the need for design in product development lifecycle” [Jeff Gothelf and Josh Seidenjeff, The Lean UX]. If we observe closely, the basic foundations of Lean UX prescribed are common to the core Lean philosophies, namely:

  1. Remove Wastage from Design Process — Moving away from heavy documentation to a process that creates artefacts which can be directly used in the design and development lifecycle itself.
  2. Cross-functional Collaboration — All the stakeholders from any parts of the product lifecycle including the designer, developers, quality experts, analysts, marketers and end-users all collaborate in a transparent and productive way.
  3. Experimentation Based Iterative Execution — So fundamentally it alludes to the UCD core principles, that assumes that the designer (or the team) learns from the execution of the prototypes in an iterative cycle that starts early in the product lifecycle, from which the learning is used as an input to improve the product along the way. If you notice this is the very basis of what we talked about the continuous and integrated feedback loop.

The use of Agile and Design Thinking practices can be seen alluding to the philosophies above. However, regarding the third philosophy — to ensure that the designer has the right approach to conduct the experimentation so that the feedback can be used in a productive way to take informative decision making along the way across the design process requires some non-ambiguous methodologies that can help the designer making some assumption and validate that through experimentation. This is the basis of one of the core foundations of Lean UX and related lean methodologies, which is popularly known as Hypothesis-Driven Design (HDD). As any design that we produce is based on certain assumption and HDD provides the non-ambiguous approach to the same, that follows the third philosophy i.e. Experimentation Based Iterative Execution.

“Declaring assumptions is the first step, in Lean UX process” [Jeff Gothelf and Josh Seidenjeff, The Lean UX] . This statement reflects how the assumptions or the hypothesis is the core the Lean UX principles. Basically, the four steps in the Lean UX approach is the same blocks that appear while in HDD, and can be mapped to the following blocks:

  1. Making Assumption / Formation of Hypothesis
  2. Build a Prototype / Minimum Viable Product (MVP)
  3. Execute / Run the Prototype
  4. Get Feedback / Observation

Now step 4 is the feedback loop that connects to step 1 making a cycle, thereby using the feedback from current iteration as the input to form the assumption for the next iteration.

Interestingly this means the HDD process always depends on outcomes rather than traditional outputs of any traditional process. The outcomes are kind of hints from the segment that can give direction to the design along the way and help in getting incremental validation of the vision by acting as “evidence” or the and more precisely they are the factors that help in “course correction” for the design. As the outcomes of the assumption act as pieces of evidence, it helps in making data-driven decisions.

You may ask, does that mean the design is reduced to quantitative factors which will act as evidence to support some of the designs? Now, here is the interesting aspect that helps to understand the approach — the feedback or the evidence can be either quantitative or qualitative in nature. And to avoid the risk of being limited to measurement-driven design, the qualitative perspective is provided equal footing in HDD approach. This makes a fit case for DesOps that can help in converging the technology with this philosophy to form required service design solution powered by machine learning, artificial intelligence and automation. The aspect of the actual implementation using technology is what we will be exploring in coming articles of this series, mostly while discussing the third dimension i.e. technology.

The very first step in HDD, i.e. “Making Assumption / Formation of Hypothesis” involves articulation of the assumption or the hypothesis. And this is the most important aspect of HDD, as the other steps depend on this. Typical hypothesis statement can be framed as per the following simplest form —

I think doing [this] will result in [that ].

There multiple variations to this that many professionals use in their area for HDD based research and design /development activities. Some add the factors such as the segment or the persona or the end user of the product, something like the following —

For [user / him/her ] I think doing [this] will result in [that ].

If you see the above keeps segment in a context that helps it keep focused on to specific persona, which thereby can lead to the user-centred design process. This is essentially labelled by many as a design hypothesis.

Some use additional factors of forming negation of the hypothesis by adding an attribute like whether this hypothesis is believed by him as true or false. To formulate a null hypothesis and thereby move on to define an alternate hypothesis (which is essentially a negation to the null hypothesis one craves to validate, but due to nature and structure or any metrics associated with that, it may not practically be possible to achieve that. So in such kind of cases the implicitly the state of belief is presented as another factor to take part in the validation process —

Because I think [this] is true, I think doing [this] will result in [that ].

I believe that any hypothesis statement can be cultivated from the bare-bones model of cause and effect being rendered as a formalized statement of “if …. then” or “when … then” kind of format. At least this gives a more practical approach to build a real-world HDD based system which is technically feasible and is the essence of any DesOps system.

The next important aspect in this regard is how to ensure that we are considering the qualitative aspect of the evidence, as discussed above. If we look at irrespective of the fact that there is a crowd of applications out there which claims to support the business through a data-informed approached, they are primarily a set of some variation between the extremes like A/B testing tools and data-driven analytics and data modelling based prediction systems. But if we notice with care at the core of HDD we found that the essence of HDD lies in making sense of the data and treat it as evidence so as to inject it to a UCD based process to fuel design or business decisions. Though coming up with a real-world HDD system would require similar tools and technologies of data-driven systems, but they will be supporting components to HDD based system. In this regard, the real HDD based full fledged system is literally non-existent as of today, while I am writing this article. In regards to DesOps, this makes a lot of difference, as most of the HDD frameworks out there are not 100% autonomous. Most of the implementation of HDD is mostly based on the work practices and methodologies, which is implemented depending on the need and feasibility. However, these are good enough when we use these, in context to the tools we gain from UCD, Lean models and the Design Thinking principles. But, it is interesting that the philosophies of DesOps, take it to the next level, making it autonomous and integrated with the over-arching feedback loop we have been referring many times.

To be continued… Keep tuned in.


(c) 2018, Samir Dash. All rights reserved.

DesOps: The Business Value Proposition

Each design is a proposed business solution which is essentially is a hypothesis. Any design process — as strives to get the answer or solution to a fundamental problem — essentially starts with the problem in mind and some assumptions in mind, which is mostly a hypothesis. And to solve the problem, with the assumed hypothesis or the business value in mind, the designer iterates and if he uses User-Centered Development (UCD) approaches, he would go into the cycle of Think – Make – Test cycle. And this implicit way of solving the issue creatively uses references to different aspects of business, namely :

  • The complete business offering
  • Customer orientation and service innovation for customer relationship
  • Business Infrastructure
  • Revenue Streams
  • Productivity and Cost control structures

As DesOps principles and practices have Hypothesis Driven Design & Development (HDD) and UCD process as its core components, it also refers to the same business value propositions. Implementing DesOps actually takes these into consideration and tries to use technology to improve the process around these.

If we refer to any standard business model frameworks such as Business Model Canvas, a template that is popularly used for developing and investigating every important aspect of the organization. The framework in such a template outlines investigations for areas such as key partners, key activities, key resources, value propositions, customer relationship, channels, customer services, cost structure and revenue streams, which always helps to understand and identify the core goals, strengths and priorities of the business that provides the context in which the UX has to be seen. This can be seen in the following equation: “Customer needs + Business context +Technological feasibility = Successful UX making the successful product”.

In a business model, we refer to UX when we plan a strategy for “Value Proposition”. In the typical Business model Canvas, value proposition involves areas like the following, which can be seen traced back to DesOps principles & practices.

  • Newness: In DesOps, this is associated with “Continous Discovery” and “Design Thinking” practices.
  • Performance: Improving performance by optimizing the process blocks through Agile & Lean methodologies through the implementation of automation through service design approach.
  • CustomizationDesOps implementation focuses on customizing the process blocks through service design approach and defining business process redesign/engineering.
  • Getting the Job Done”: This is fundamentally the result oriented approaches taken in DesOps which touches upon different aspects like roles, cohesive team play, removing wastage through Lean methodologies and the similar.
  • Design: This is core to DesOps, and is seen as the creative problem-solving.
  • Brand/ Status: Brand and Status is well associated with the feedback loops that include the real users in context and feeding the design process with continuous feedback including brand perception and related mental model of the user of the target segment.
  • Price: Though purely a market associated component, the price can be dramatically reduced through implementation of DesOps, as it focuses on reducing waste and improving efficiency through automation and process improvements
  • Cost Reduction: It is one of the fundamental components of ROI on DesOps in an organization. DesOps helps reducing cost through service design approach to optimize and redefine business process.
  • Risk Reduction: DesOps helps reducing ambiguity by the implementation of optimized process and automation powered by the feedback loop that touches all the roles and the aspects be it human or machine in context. This improves reliability and thereby reduces risk.
  • Accessibility: Through the implementation of Design Thinking, UCD model like contextual and participatory designs and continuous feedback loop, DesOps helps to ensure the accessibility factors are in consideration while iterating over a design.
  • ConvenienceUsability: Through its advocacy of UCD models and Design Thinking and integrated feedback loop, DesOps help in ensuring usability aspects in all design delivered.

From a product manager’s standpoint, the successful UX meant for a business must balance between the needs of the users and the feasibility of implementation of the UX solution within the business context, and all the practices and principles of DesOps converge towards this.


(c) 2018, Samir Dash. All rights reserved.

The 10 Practices of Design Operations (DesOps)

A method, procedure, process, or rule used in a particular field is typically defined as practice for that field. In last article, we discovered about the 10 guiding principles that drive the DesOps. No wonder the practices involved in DesOps, loud the same principles to the core. Note that we are still discussing the culture driven by DesOps / DesignOps, that is typically fuelled by these practices.

Here are the broad practices that drive the DesOps philosophies:


Download Poster:


1. Design Thinking

This practice ensures that we employ the creative problem solving, the typical methodologies and tools of Design thinking. Here are some quick notes and list of methodologies and tools used in IBM version of it which anyway follows the fundamental principles of Design Thinking

The typical tools of Design Thinking, such as Stakeholders map, Experience maps (As Isand To Be), Personae, Roadmap, MVP, Kano Modelling, Story Boarding, Priority Grid etc. are coupled with continuous practices defined in the following to implement the Continuous Loop of the Design Thinking practice that holds the DesOps philosophies.

2. User-centred Design (UCD) and Usability Design

Users (both the typical user / persona from UX angle and the segment from marketing/business context ) are at the core of DesOps. Any design solution generated fundamentally is an advocacy of the user needs and tries to direct the business goals to build upon this. The business goals are also in such cases are market specific and are based on the pulse of the segments driven by the user needs. You can have a quick note on UCD and usability-design here As UCD or Usability design focuses on the Iterative Design approach of User Centered System Design (UCSD) process this fundamentally contributes to DesOps goals.

As UCD supports growing product through iterative design that is also fuelled by all 3 models of design which contribute to typical Design Thinking as well as Lean UX models, namely:

  • Cooperative Design: This involves designers and users on an equal footing.
  • Participatory Design (PD): Inspired by Cooperative Design, focusing on the participation of users
  • Contextual Design: “Customer-Centered Design” in the actual context, including some ideas from Participatory Design.

And here are the steps we use while implementing UCD , irrespective of the above models we follow: All these UCD models involve more or less a set of activities grouped into the following steps mentioned below:

  • STEP 1 – Planning: in this stage the UCD process is planned and if needed customized. It involves understanding the business needs and setting up the goals and objectives of the UX activities. Also forming the right team for the UX needs and if needed hiring specialties fall into this step.
  • STEP 2 – User data collection and analysis: This step involves data collection through different applicable methodologies such as user interviews, developing personas, conducting scenarios, use-cases and user stories analysis, setting up measurable goals.
  • STEP 3 – Designing and Prototyping: This involves activities like card sorting, conducting IA, wireframing and developing prototyping.
  • STEP 4 – Content writing: this involves content refinement and writing for web and similar activities.
  • STEP 5 – Usability testing: This involves is a set of activities of conducting tests and heuristic evaluations and reporting to allow refinement of the product. However, Usability Testing can have its set of steps involving similar activities such as planning , Team forming, testing, review and data analysis and reporting.

And you will see all these naturally fall into the places while any DesOps is implemented.

3. Hypothesis-Driven Design/Development (HDD) & Data-driven Decisions making

The DesOps story remains incomplete without referring to one of its key practices that are Hypothesis-driven – development (HDD), which certainly contributes to the service design like DesOps, that brings possibilities of changes to inculcate design thinking, innovation and organizational changes. It also promotes the lifecycle methods and adjusts them to ensure that integrated work-flow and work-culture is established that can make the best use of data-driven decision making by running multiple early-stage experiments (synonymous with what we are trying to achieve through continuous feedback loop and prototyping) and gathering insights from their outcomes (and not just output!). Another interesting thing is that this advocates the use of UCD approaches as it focuses on making an assumption, running experimenting and validating them with measurable data, and thereby taking some action based on the same.

Will elaborate on HDD driven methodologies in context to DesOps as we move in this series of articles.

4. Agile / Iterative Life Cycle

There are several challenges in integrating UX design and related activities into a typical agile software development lifecycle process. The most common problem is typically “ finding a balance between up-front interaction design and integrating interaction design with iterative coding with the aim of delivering working software instead of early design concepts”. This happens mostly because typical pure SDLC approaches primarily aim at “efficient coding tactics together with project management and team organization instead of usability engineering”.As Agile is more “a way of thinking about creating software products’ rather than being a specific process or methodology hints at the challenges of UX integration into it as integrating user research and UX design with agile, is itself an “agile antipattern”.The very idea of SDLC is a process for developing software, traditionally never kept the “user” into a focus, or event kept any scope for methodologies that try to bring any component that is not considered as a native ingredient of the process of creating a software product. The focus was always the “cost, scope, and schedule” that drive any traditional SDLC models including Agile. And sure enough, this typically gives rise to the challenges for UX integration into any SDLC as project managers never try to upset the balance of these three by reducing costs, tightening deadlines, and adding features in the specification. To know more about the typical challenges we face while implementing design / UX into Agile SDLC read my earlier article here:

However, there ways to mend this gaps between process driven life cycle models such as Agile model — one of such is to implement usability design model (we discussed that as a practice of DesOps above). Usability process supplements to any software development life cycle at various stages, as is not a complete product development process as it does not output the final product at the end of the process cycle. One such solution is reflected in below diagram :

And it is interesting to see that each cycle in such solution is actually contributing to a continuous cycle of Conceptualize – Design – Build – Test that aligns nicely with DesOpsprinciples and other practices.

5. Lean UX Approach

The Lean UX practice focuses on the Lean philosophies that focus primarily on reducing waste from the process and provide ways to simplify and expedite the delivery keeping the quality intact or enhanced. Interestingly the Lean UX is based on the 3 foundations which are also part of the DesOps practices list we are discussing:

  • Design Thinking: This foundation upholds the concept that “every aspect of a business can be approached with design methods” and gives “designers permission and precedent to work beyond their typical boundaries”.
  • Agile Software Development: Core values of Agile are the key to Lean UX.
  • Lean Startup method: Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets teams building quickly and learning quickly

No practice used in Lean UX is something new. Rather it is “built from well-understood UX practices”. Many of the techniques used over the time in various UX process and have the practical usability even today have been packaged properly in Lean UX. So the following foundation pillars of this also supports DesOps as inherited from this practice:

  • Cross-Functional Teams: Specialists from various disciplines come together to form a cross-functional team to create the product. Such a team typically consists of Software engineering, product management, interaction design, visual design, content strategy, marketing, and quality assurance (QA).
  • Small, Dedicated, Collocated: Keep your teams small—no more than 10 total core people as keeping small team has the benefit of small teams comes down to three words: communication, focus, and camaraderie. It is easier to manage the smaller team as keeping track of status report, change management and learning.
  • Progress = Outcomes, Not Output: The focus should be on business goals which are typically are the “outcomes”, rather than the output product/system or service.
  • Problem-Focused Teams:“A problem-focused team is one that has been assigned a business problem to solve, as opposed to a set of features to implement”.
  • Removing Waste: This is one of the key ingredients of Lean UX which is focused on “removal of anything that doesn’t lead to the ultimate goal” so that the team resource can be utilized properly.
  • Small Batch Size: Lean UX focuses on “notion to keep inventory low and quality high”.
  • Continuous Discovery: “Regular customer conversations provide frequent opportunities for validating new product ideas”
  • GOOB: The New User-Centricity: GOOB stands for “getting out of the building” — meeting-room debates about user needs won’t be settled conclusively within your office. Instead, the answers lie out in the marketplace, outside of your building.
  • Shared Understanding: The more a team collectively understands what it’s doing and why, the less it has to depend on secondhand reports and detailed documents to continue its work.
  • Anti-Pattern: Rock-stars, Gurus, and Ninjas: Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. So more efforts should on team collaboration.
  • Externalizing Your Work: “Externalizing gets ideas out of teammates’ heads and on to the wall, allowing everyone to see where the team stands”.
  • Making over Analysis: “There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room”.
  • Learning over Growth: “Lean UX favours a focus on learning first and scaling second”.
  • Permission to Fail: “Lean UX teams need to experiment with ideas. Most of these ideas will fail.The team must be safe to fail if they are to be successful”.
  • Getting Out of the Deliverables Business: “The team’s focus should be on learning which features have the biggest impact on the their customers. The artefacts the team uses to gain that knowledge are irrelevant.”

You can read more in one of my articles here:

6. Fail-Fast through Prototyping

Typically a Fail-Fast is about immediately reporting any condition that is likely to indicate a failure. Also, Fail-Fast allows gathering early stage feedback that serves as an input for the continuous UCD model which helps bring up solutions to the design issues using such input and thereby minimizes the risk of product failure in the hand of users or in the market. This is also a philosophy that aligns to the Lean Startup methodology and accelerates innovation as it encourages taking early stage risk. Typically the startup cultures undertake bold experiments to determine the long-term viability of a product or strategy, rather than proceeding cautiously and investing years in a doomed approach. In service design, this helps to improve the processes to make use of systems that support Lean methodologies and model. The great part is that this in DesOps while getting combined with UCD processes, provides options to run short and quick UCD iterative cycles of Think – Make – Break kind of model.

Prototype plays a crucial role in UCD models to achieve Fail-Fast and thereby ensuring early feedback on the design is received that can contribute to the evolution of the product. Different fidelity of prototypes is used in order to ensure that the target experience can be tested.

7. Continuous Discovery

Continuous Discovery is primaily involved with the conceptualization stage of the product lifecycle. This practice mostly is driven factors like

  • User focus: The goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should control the development.
  • Active user involvement: Representative users should actively participate, early and continuously throughout the entire development process and throughout the system life cycle.
  • Simple design representations: The design must be represented in such ways that it can be easily understood by users and all other stakeholders.
  • Explicit and conscious design activities: The development process should contain dedicated design activities.

This practice, however, is not just limited to conceptualization stage, but organically is part of the evaluation and build stages as the outcomes from such stages of life cycle, it gets the input of feedbacks and evaluation results which aid in the discovery of the solution through the design process.

8. Continuous builds and delivery

This practice focuses on continuous design delivery that ensures that the DesOps sustains the lifecycle and supports iterative UCD cycles. This involves the process that supports the design of the solution which thereby contributing to the system development that is iterative and incremental. The early part of life cycles involving such practice typically gains life from prototyping which is used to visualize and evaluate ideas and design solutions in cooperation with the users.

So the factors in this practices are :

  • Evolutionary systems development: The systems development should be both iterative and incremental.
  • Prototyping: Early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the users.

9. Integrated & incremental testing

Evaluation and getting the feedback from all stages of the lifecycle is key to any DesOpsimplementation, therefore integrated testing (including usability testing) in an incremental fashion is what that plays a stronger role among all the practices. This actually draws from the UCD models running a User Centered System Design (UCSD) approach. As UCD experts help in benchmarking usability tests popularly known as “summative evaluations” that evaluates the performance of the system /product developed on several grounds. The metrics of this test is typically based on the “error rate for users as they use the system”, the “time it takes to attain proficiency performing a task”, and the “time it takes to perform a task once proficiency has been attained”. So the factor that drives the practice is —

  1. Evaluate use in context: Baseline usability goals and design criteria should control the development.

Note that the key here is that all the testing should support evaluations in context. In the real context of use, getting the data is what makes this effective and thereby making DesOpsmore fruitful.

(Fig – Source: Re-imagining Beta Testing in the Ever-Changing World of Automation )

The ISO standard also defines Quality process where context plays the major role. And interestingly Usability testing and HCI aspects are all driven by context. Read one of of my articles on how context plays a critical role in testing and usability, which also narrates an experiment named BetaStudio here – .

10. Service Design on an Integrated Feedback-Loop Model

The integrated feedback loop is actually more than getting testing reports. This practice ensures that the feedback flows from any point to any point as needed, may it be from stakeholder to Designers, or End-Users to Developer, Testers to Designers or in any path that flows from one persona to the other. Also, this includes the service design that helps to implement the DesOps which ensures the information, as well as the feedback, is flowing seamlessly even including from and to the systems and different roles. This certainly uses service design employing recent technologies like Automation, Machine Learning and Artificial Intelligence etc.

Hope this article was helpful. Keep tuning in for the next parts of this article series. Before moving on to next points on Culture of DesOps, we will be looking into a Business Model Canvas and try to see how DesOps fits in. Do share the words.



(c) 2018, Samir Dash. All rights reserved.

The 10 Principles Driving DesOps Culture

(Originally first published on April 17, 2018 at  )

As pointed out in the last article, the dimension ‘Culture’ has at the hindsight 3 life-lines, namely

i. Principles & Practices

ii. Cultural Shift towards Lean Philosophies 

iii. The way the team works (Mostly Design team but not excluding the intra-team work-culture)

In the current article, we will be focusing on the Principles that drive the DesOps philosophies. Broadly, the DesOps can be seen based on 10 commandments or the guiding principles which help set the goals —


Download Poster:


1. Implementing DesOps is to follow service design methodologies.

In reality, DesOps is the most evolved service design methodology, that touches upon all the different roles involved in a product lifecycle starting from conceptualization till the point product being used by the consumers. Therefore, DesOps implementation should establish the best practices for designing services according to both the needs of customers and the competencies and capabilities of service providers.

2. The feedback loop should cut across the product lifecycle

Ensure the requirements are fed into the DevOps cycle through feedback loop seamlessly so that the adjustment of the requirements can be done based on the feedback loop in the design stage that is also iterative and in the agile sprint loops. The requirements formulation is one of the core activities of design.And the requirements should be able to adjust based on the feedback that typically comes from means that cut across design as well as the development -test-deployment-production stages. So it involves the feedback from the large part of the delivery-deployment track, which is fundamentally DevOps impacted process areas. And when continuous integration and delivery (CI & CD) are part of the DevOps implementation, the continuous feedbacks that pours from various stages of DevOps should be addressed in an agile as well as iterative design stage, where these feedback fuel the design decisions to adjust requirements ignorer to meet the user as well as market needs. It is therefore critical that the DesOps implementation must follow the principle of completing the full circle of feedback loop that would cut across both designs as well as the dev-deploy-production stages – i.e. the complete SDLC and use it as an input for Design.

3. Empower stakeholders for better decision making — Hypothesis and Data-driven decision making for design and development

Many decisions are taken for a product based on the experience and the gut-feel of the stakeholders that impacts the product. The design – the creative problem solving – gets impacted by this as in real world, design decisions are always biased by the stakeholder’s view of the product and the market. A true DesOps should enable the stakeholder to take decisions based on a more data-driven way. Typical A/B testing, Hypothesis-Driven Development approach and analytics-driven decision making always help the stakeholder to evaluate the options and it guides him to take the more pragmatic decisions by reducing his baseness from his pre-conceptualised version of the product, user, and market. True DesOps, aspires to a world where decisions are taken by validating the data against the postulates that impacts the design as well as the success of the product itself in the hands of users and market.

4. Enable Design Thinking in the team

When we broadly speak about design, we do mean the core essence that is about creative problem solving which transcends beyond the typical professional design practices such as social context and business. Because of this, the Design Thinking strategies as solution-focused thinking fuels innovation and in today’s world, it is a popular approach that is employed in communities and organizations.

Many organizations, like IBM, KPMG etc. Have been improving the Design frameworks around the core concept of design thinking to come up with design strategies that would work with product life cycles and project management processes supporting Agile and Iterative approaches. For example, IBM Design Thinking (here is a quick guide  )

However, in many angles, all these versions of Design Thinking fail flat to impact the final deliverable products in a quick paced agile environment powered by continuous integration and delivery track. The workshops of such Design Thinking sessions do provide innovative outputs, but when it comes to implementations, the sync between these and the final MVP that goes out of the delivery track, is lost and in most of the cases the stakeholders feel that despite the investment into the design thinking approaches, the expected level of outcome in delivery is not met and in many cases changes in requirement in the middle, too many iterations leading to over budgeting, mismatch of skill set and resources requirements to the initial planning work and the feasibility aspects were blamed for the inferior quality of delivery in contrast to the grand outcome from the Design Thinking.

Some years back, I was part of a large UX team of a Software Conglomerate, where I practiced their version of the Design Thinking framework. And during many workshops with major customers, and also from casual discussions with some of the stakeholders and Design Thinking practicenors, I realised that though many of our design thinking workshops were successful and were received by the clients with excitement and sense of achievement, this in many cases died down after a few months of implementation happened over fast paced agile delivery modes, as the translation of the great solutions that came out from the design thinking sessions, didn’t actually live up to the expectations due to too many changes in requirements happened because of feasibility, resource management, technology and similar issues.

For me, the takeaway from there was that in fast-paced delivery track, the feedback loop must be connected across the design stages to be reviewed at the same pace to ensure that the overall speed of the delivery with quality remains intact. In many cases, because of the fact the issues that popped up during the implementation stages, were never efficiently part of the Design Thinking sessions of the next iteration or design cycle that runs, it was not effective in coming out more practical and pragmatic design solutions and make the necessary adjustments to the requirements. And in such cases the DevOps even when efficiently implemented, the lagging and relatively slow churning-outs from the Design Thinkings, the overall delivery gets impacted thereby resulting into inferior quality MVP than that of the envisioned one. As the Design and Development are two wheels of the bicycle that the product is riding on, even if the Dev wheel is made efficient by implementing the best possible DevOps, the overall pace and efficiency of the cycle is reduced and is equal to the other lagging wheel i.e. Design.

To overcome this, one of the core principles of DesOps is to empower Design Thinking to make it more efficient in a fast-paced DevOps enabled delivery process, thereby making it the best fit case for the organizations to adopt.

5. Advocate Lean Methodologies and Agile Philosophies

All “Lean” models typically focus on reducing waste in a process by removing it from the value chain of the usability process. One of the key goals of DesOps is about taking proactive measures in reducing waste and fundamentally support tries to bring the practical implementations of it. Therefore, DesOps, at the core advocates, Lean philosophies like that we see in Lean UX models. Along with the fact that Lean UX itself is based on 3 basic principles like “Design Thinking”, “Agile Software Development” and “Lean Startup methods” like “build – measure – learn”, it is an organic part of in DesOps philosophies.

6. Translate User-Centered Design into an actual process that can be used on the ground

DesOps supports User-Centered Design (UCD) process in which “the needs, wants and limitations of end-users of a product are given extensive attention at each stage”. Basically, in DesOps, the focus is same as on any optimized UCD process, where most of the priority is on understanding the behavioral aspect of the user interacting so that the user’s learning curve in using the system can be evaluated in order to optimize and reduce it. As DesOps, emphasizes on optimizing the product around “how users can, want or need to use the product, rather than forcing the users to change the behavior to accommodate the product”, it loads the philosophies of typical UCD model. So DesOps inherits the following factors from UCD, namely —

  1. Needs of Users
  2. Limitations of Users
  3. Preference of Users
  4. Business objectives of the Product. 

7. Cohesive play in the cross-functional team— designer, stakeholders and developers into the team play

As DesOps advocates LeanUX, it inherits one key attributes from Lean UX, which is about cross-functional team-play. Typically the Lean UX advocates that specialists from various disciplines should come together to co-create the product. Such team traditionally comprises of roles in software engineering, product management, interaction design, visual design, content strategy, marketing and quality assurance or testing disciplines. DesOps fundamentally enables this in bring these diverse roles to the same page and improves productivity through improving feedback loop and communication and providing a train of outcomes of the product development track that helps in “continuous discovery” and validation of product requirements and ideas.

8. Technology decisions should be guided by lowering the boundaries between roles and automation to reduce waste and repetitive jobs that work for the product and project.

Perhaps the biggest visible attribute of DesOps is the technology aspect, and the basic principle around technology is about the technology decision making. This is one of the most critical and impacting principles, as the right decision making for choosing the correct technology that will enable or help implement the most effective DesOps for the target organization/team. As DesOps involves the workflows, that touches the different aspects of Software Development Life Cycle and as the goal of DesOps is to achieve scale, the tracking, and traceability of workflows and responsibilities involved from different team members, technology, and tools employed to make it possible are carefully selected to meet the specific design culture that was redesigned with the re-engineered processes and workflows. Employment of automation, machine learning, and artificial intelligence plays a key role in the context of the technology selection to aid the DesOps implementation as well as improving the case for it to play a complementary role for DevOps to make the full-circle. We will elaborate on this aspect in details in coming article of the series.

Back in 2014-15, in one of my old exploration into visual design prototype called Specstra,I was exploring the possibilities to remove repetitive manual work of draftsmanship in the creation of visual design specs or style guide (part of static design systems) involving automation the process to reduce the efforts from days to just 2-3 minutes. It used standard design file formats including properitry ones like Photoshop (.PSD), Illustrator (.AI) and PDF, as input to generate completely detailed pixel perfect style guide with annotations and target resolution and device screen density specific specifications that can be used by the development team to create screens. You can read about this story at IBM Design Blog at or watch the video below :

(Video – In my experimental prototype Specstra the attempt was made to bring automation to visual design process to reduce repetitive manual tasks. )

9. Redesigning and re-engineering the Processes

Optimised and re-designed processes are key to reduce waste and remove repetition, At the same time lower boundaries between roles. Broadly the processes that are redesigned in a DesOps implementation include strategy and workflows for reducing wastage. Any repetitive blocks are removed or replaced with the ones that provide quick turnaround time for design deliverables as well as the access to all-around feedback -loops across the lifecycle including development, deployment areas. The goals of improvement of processes also include lowering boundary among different roles to enable a cross-functional team to quickly iterate and produce design outputs which can be fed into DevOps thread in the cycle. Also, process improvements include automation focus along with workflows for traceability and tracking and preparing benchmark data and validating the feedbacks and product performance against them in a seamless way. Also, alongside the focus of the process redesign as part of DesOps include the areas to customize and complement workflows to the existing SDLC if required, that is in the process where possible e.g. Agile, Iterative and Lean models.

10. Enable reviews based on data-driven benchmarks.

A DesOps implementation should support benchmarking and validating against those benchmarks for design as well as implementation aspects. You might have noticed, that the feedback-loop is fundamental to the DesOps philosophies. And you might have noticed that in the previous principles, most of them directly or indirectly pave the way for integrated feedback-loop that helps to enable faster delivery track for an efficient and productive product delivery with the tint of innovation. So, it is critical for the DesOps as a service design must make ways for benchmarking the various attributes of the product and the delivery method itself that contributes to the speed and agility so that the feedback loop can make good use of these to validate and support a faster and informed decision making. In one of my recent explorations into beta-testing for RedHat’s QE CampX and Idea Incubation prog, I had focused on this aspect and tried to come up with a prototype called BetaStudio,that tried to address how to create benchmark for attributes which are more on the creative side and fall in the design stages of a product’s lifecycle, and thereby using some kind of mechanism to validate based on such benchmarks. Read about Beta Studio at

The above diagram shows the high-level vision of BetaStudio that used benchmarking of design aspects which were used at a later stage (mostly the track covered by DevOps) to validate the feedback most of which were generated by automation. In later articles, I will be elaborating on this aspect in details.

(Video – In my experimental prototype BetaStudio the benchmark based review and feedback loop was explored )

While implementing DesOps in the organization if we contradict any of these principles, it would result in a half-baked design operation that would not help in achieving the goal. In one of the organizations I was part of in recent past, some attempts were made to improve the design process. And in the effort to make the design team’s activities streamlined, certain design tools licenses were bought and the team members are asked to follow certain fixed process and semi-automation plugins etc. Along with this an earlier design system was revamped to provide commonly used patterns and widgets to be used. In the name of improving the process Agile model was cut-pasted and was followed. But over the period it was noticed that the overall efficiency dropped in the team. The interesting part was even though the steps to improve the design work culture implemented some of the key principles we discussed, and missed many, which led to a failed process re-engineering. The whole agile process implemented was designed to make the design teamwork as a separate entity to match the organization structure of the team as a separate business unit in order to ensure easy budgeting and determine responsibilities of the team across multiple projects running. If we review this case, we can find that the putting the design team’s own process delivery cycle didn’t contribute to the overall product delivery cycle. It conflicted with the DesOps principles like Cohesive Team-play and supporting Lean model which advocated the arching DesOps should encompass and cut-across all the teams responsible for the product and not just the design team. Also making design team as a single entity, put it into a silo because of which the feedback loop was not effective, thereby it impacted the translation of UCD philosophies.

Well, we will elaborate on similar cases in upcoming articles of this series sometime later. Now as we covered principles, let’s see in the next article, what are the practices that contribute to an idea DesOps. Hope you enjoyed the DesOps journey!



(c) 2018, Samir Dash. All rights reserved.

The 3 Dimensions of DesOps

In recent times many have attempted to define the DesOps in easier words to the community. But many of those attempts never went beyond the explorations beyond the efforts put to define a Design System. In many cases in many UX communities and teams, the definitions of DesOps is limited within the scope of Design System, which in turn essentially is a meta-product i.e. a product that enables other products. Then what is the scope of DesOps?

In my view, DesOps is not only about tools or technology employed which is generally referred to the discourses about binging automation and improved process re-engineering in the engineering sense. Rather DesOps is about defining a culture of design through improved work practices and communication among the design teams with the inter-cum-intra project/product teams and stakeholders and aiding these practices with the help of technology to bring communications among the involved tools and the arching eco-systems.

So DesOps is rather a combination of —

Designing of Design Culture and Communications + Work practices EcoSystem of Tools & Technologies 

In the Designing of Design Culture basically the design process is involved to come up with a solution that takes into account the existing gaps and areas of improvement which is needed for a specific organisation where communities or a teams involved in product life cycles, (in case of Software industry, it’s more influenced from the Software Development Life Cycle ) to improve productivity, remove wastage (in terms of effort, delivery timeline, man-power etc. ) and in many cases establish a lean process and methodologies. As DesOpsis associated with these aspects, and especially the Lean Process and methodologies, it intern impacts the culture and how the team collaborate, work and communicate.

DesOps, in other words, empowers the philosophies of the Lean UX and Fail-Fast models of start-up organisations in a better way. So the process that involves the work-culture, team – communication, product feedback loops etc. are re-designed as a part of DesOpsimplementation and this is referred as Work practices.

To aid the above two, in DesOps implementation, the focus is more on automation involving certain workflow engineering to support the re-design process (referred in the paragraph above). Basically, this 3rd aspect is more about the translation of the about two aspects with the help of technologies and building and putting in places the tools to define the required eco-system that brings seamless delivery track and complement it with DevOps through continuous and integrated delivery approach with the arching feedback loop. The use of automation in this aspect improves efficiency and scales the whole process across the whole product delivery cycle and reduces wastage.

So here is a crude way to group the different dimensions of DesOps, which come into play while modelling DesOps solution for a target organisation or team. Let’s not take them literally as many of these dimensions have overlaps among them, for example, the way we work might involve components from the cultural shift dimension.

1. Culture – The social behavior and norms that It is internally affected by both forces encouraging change and forces resisting change — which are related to structures and events within the DesOps system of humans as well as machines, and are involved in the perpetuation of cultural ideas and practices within current structures, which themselves are subject to change.

i. Principles & Practices

ii. Cultural Shift towards Lean Philosophies

iii. The way the team works (Mostly Design team but not excluding the intra-team work-culture)

2. Process – Process, primarily, a sequence of interdependent and linked procedures, is an important aspect that is made up of the workflows and the over-arching feedback-loop that acts as the spine of DesOps. Being organically associated with different functions, it involves the actions on different spheres of the operations running within the organization as well as the systems involved.

i. Work-flows

ii. Feedback- loop

3. Eco-System – Eco-System being is a regularly interacting or interdependent group of entities forming an integrated whole, deals with the technology, tools and the design systems powered with automation, that makes DesOps real on the ground. Eco-system provide the required support to the culture as well as the processes to function as well as transform.

i. Technologies

ii. Tools

iii. Design Systems

iv. Automation architectures and approaches

Stay tuned and be part of the DesOps journey with me.



(c) 2018, Samir Dash. All rights reserved.

The 3C’s of DesOps (Design Operations)

The Living Design System is mostly perceived all about modular design. Mostly the patterns, being the referred as the “molecules” or “organisms” as a part of “atomic design process”, are made to allow the part of structure or group. This view of the living design system brings to focus, its two major aspects — first is, of course, the creation and maintenance of patterns. The later is about coming up with a process and ensuring that these fit into a workflow that both would touch both designer and developers and make the connections among their workflows. However, this latter aspect has remained challenging even for the experienced teams across the industry.

Historically and interestingly, DesOps at the beginning, without its formal name was focusing on the areas of creation and maintenance and sharing of its modular design systems. At the very beginning phases in last couple of years, it was more about the organisations having the design systems and making these socialised. Primarily these design systems have consisted of visual design languages and components and widgets. These design system had defined basic goals, principles, branding (for specific organisational identity) and a visual language that helped it maintain consistency in the creation of design artefacts and assets. Along with it the UI patterns and widget libraries included in them helped to bring consistency in terms of interactions across a wider scale of interfaces within the organisation or product portfolio.

Ensuring this became part of the strategic aspect of any UX or Design team, in the organisation that was responsible for driving this. Mostly this task became the primary share of the role of the Design Directors, Leads and Principals in the organisation as a part of their goal to ensure ringing the right maturity to their design team and practices.

This was definitely a low-hanging fruit in terms of what DesOps as the principle is geared towards. The return from such low-hanging fruit was helpful in many ways. Apart from the consistency, it actually helped in reducing the friction among the teams regarding the design aspect. Also, it helped to reduce some aspect of operational inefficiencies in the design workflow to some extent and helped in reducing waste thereby helping the team to deliver at a faster rate.

However the design work practices, unlike the development domain are more diverse and being the area with the most creative energy association in the whole lifecycle, the challenges to ensure the smooth amalgamation of the these design systems to the process blocks of the workflow was not easy. The fact is till the date writing this passage, it is still a challenge to fit the existing tools, to the design work-flows and then aligning it to the whole delivery track fuelled by the DevOps paradigm.

Recently the design team at AirBnB, came up with React Sketch App. Last year at RedHat UX team meet up Summit, as a part of a design challenge initiative I presented a concept Ditto, that was supposed to redefine the way the design can be integrated into a DevOpssupported environment. Will share the details of Ditto in coming articles of this series. ClearCleft also in recent times came up with Fractal that tried to reduce and even remove the distance between the design and development teams. Note that both the DevOps and DesOps are 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 the technological approach of use of “the single source of truth” can be a good starting point towards building a practical DesOps culture in the organisation. As the soul of DesOps based on the cultural shift and practices working towards Continuous Integration (CI) and Continuous Delivery (CD), it makes sense to use the 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 if we look at it, the typical 3 pillars of any framework also fits here —

1. Consistency — in the context of DesOps  the consistency plays the major role both in approach and workflows as well as from the design perspective

2. Continuity — mostly it fuels the continuous design aspect that provides agility to the design process.

3. Complimentary – no doubt as DesOps completes the full-circle, it complements the vision of DevOps. 

In the next article, we will dive into the different models associated with the DesOps framework.



(c) 2018, Samir Dash. All rights reserved.

The Maturity of Design Systems

To understand where a DesignSystem  of an organisation stands in context of implementing a DesOps, first step is to evaluate the existing DesignSystem that is in place and contributes to the organisation’s design process. (We will explore the process aspect in details, in later articles in this series.) To evaluate any DesignSystems  in a broadway we can easily form a metrics that takes care of the following two perspectives on the system.

Designer System Types

Typically the Design Systems can be broadly categorised into 3 types, namely: StaticDynamic and Generative :

Static: Most of the attributes and elements that make this system is mostly static in nature. For example in a Static type Design System, the style guide may be pre-defined print ready reference, defining basic color standards and typography etc. The user has to read through and manually refer it to decide those related attributes in his work. This kind of System mainly prescribes guidelines, rules, principles which does not automatically change or created in a dynamic way either in the stages of creation or implementation by the developers etc. Typical organisational style guides or UI pattern documentations where the system describes how and where to use the patterns with some sample code to refer are falling under this kind of categories.

Dynamic: This kind of Design Ssystem  have the content as well as the principles of implementations are designed and developed in a way that can be directly used in the code. The creation and implementation of the content are dynamic and mostly geared towards the actual elements that can directly be used in the code. This kind of Design System  is more than a reference system for the developer, rather as a part of the actual build of the actual products developed as a part of it. Most easily noticeable traits of this kind of design system  is that some special purpose frameworks, code libraries are part of it, which integrate into the actual builds of the products.

Generative: Generative Design System  are the ones, which generate the actual build ready outputs that can directly go into the build of the product. For example, instead of a static style guide, a generative Design System  can have the tool that will generate dev-ready HTML, CSS and JavaScript based output from the designer/developer inputs. The output of such system, take care of the context for which the design outputs is needed. Let’s say if the developer needs to build a cross-platform hybrid app, hen such system can generate the code that will take care of the scenarios for the interaction and behaviour for all target device resolutions, screen density as well as the behaviour for native wrappers as well as in-browser functionalities and restrictions. We will again journey into the details of the Generative Design Systems shortly.

Designer System Maturity 

The other angle to look at the Design Systems is to scale the maturity to measure how much the system has evolved. One of most important aspect of any Design System is to understand the maturity of it, as this helps to understand where it is in the overall DesOpsroadmap. Irrespective of the varied and complex categorisation of the same, we can still name the maturity as Low , Medium and High to get a quick and easy comprehension. And when we try to map the maturity, it takes care of the categorisation aspect.

Low Maturity: When the Design System has a low maturity, it mostly depends on the static attributes that we discussed above. The creation and maintenance of different attributes are mostly the result of manual effort and the most interesting point about this is that the designer and developers have the cognitive load to refer and comprehend and take decisions on what to use and not use in specific context of their work or product. It is also important, there may be some attributes which might have dynamic attributes , but most of them are out of the transition that the design system is having due to its evolution,

Medium Maturity: In the Design Systems with medium maturity, the most elements and attributes are mainly dynamic in nature. These systems mostly depend on the frameworks, libraries etc. There may be some overlaps in static and well as generative attributes.

High Maturity: Similarly in Higher maturity, apart from the fact that it mostly contains generative attributes, it involves the aspects of automation, computer-vision and may deploy artificial intelligence (AI) to provide continuous pipelines that aspires to remove the human intervention form the process blocks. On ground reality it might require the human intervention to feed in the creative juices or decision power that impacts critical human needs or contexts.

When we map these 2 perspectives horizontally and vertically, we get the the right insight into the DesignSystem’s position in the graph that allows us to clearly understand where the gaps are for the DesignSystem to evolve on which dimensions.

Note that the metrics that govern the success of a DesOps implementation is almost synonymous to this metrics we explored about Design Systems. The factors that adds to this metric on Design Systems,  includes aspect where we measure how impactful the Design System is in touching the different design process lifecycle blocks where each role like an Information Architect or an Interaction Designer , Visual Designer or even the Developer are attached to, in the delivery track. This aspect is more figuratively termed as a Living Design System. 

The Living Design System

The scaling of design is a classic issue. Moreover in recent times the explosive growth of technology across different devices, platforms and ecosystems, it became an ever-growing monster that every designer faces sooner or later. Native (Windows, Android, iOS, Linux etc. ) Web (HTML, HTML5, CSS, CSS3, JavaScript and frameworks etc. ) Along with the combination – the Hybrid – make the scaling of the design language an unending challenge.

The Salesforce design team tried to solve the challenges of applying similar designs across cross-platform product families by introducing a dynamically configurable design asset system which viewed the individual entities of any design system as design tokens.

Technically it was a single JSON file that was the “Single Source of Truth” that contained a set of name-value pairs that defined the properties and their relationships under different categories like text colours, backgrounds, border sizes, font sizes, etc. This JSON was consumed by the framework (i.e. The Lightning Designing System link: developed and templatized for different target platforms, devices, Operating Systems etc. The Lightning Designing System framework generated different formatted outputs for CSS via common CSS preprocessors like Sass, Less and Stylus. Also there was an output in XML format that is supported in Android and JSON for iOS specific development. The Salesforce Design Tokens open-sourced at

The second interesting aspect of this was the use of GitHub to host the design system. Unlike the design system of traditional organisation, where the design system was hosted as downloadable form (even in the cases where the version control like Git is used) these have to be either translated into desired formats for the target platform or hosted especially along with the code. But here the design tokens representing the styles definition and the properties, as hosted on GitHub, were directly integrated into the build process contributing to the Continuous Integration and Development approach of development. In this sense, it was more as a Living System acting a single source of truth, from which the required branch is pulled and be made as a part of the build.

Many other pattern library and/design systems like RedHat’s PatternFly is also available in similar approach at GitHub (i.e. at )as that of this second aspect we discussed now. But the idea of making the style guide being available as a single source of truth in a combination of this second aspect is what makes the case of the Salesforce design system unique among similar attempts for an approach to delivering a consistent design across different platforms.


(c) 2018, Samir Dash. All rights reserved.