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

[This is the SECOND part of the half-day workshop titled “Applying DesOps in Your Enterprise” I conducted at the “UX India Conference 2018” on 4th October, 2018, Bengaluru. This part focused on ‘Design System’ aspect of DesOps, and tried to address the challenges that designer face when they collaborate using around either two or more design systems. Neither of the design system as of today talk to each other in the same way, nor is the fact that that none of the design systems organize and define their patterns in the same structure.

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

The code can be downloaded from https://github.com/OpenDesignSystem/ODS-CDN .

You can explore more at

http://desops.io and http://opendesignsystem.org/portal/nuclear-design/

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

]

 

 

You can explore more here:

https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-3-heredity-samir-dash/

‘Semantic Design System : Redefining Design Systems for DesOps’ https://www.slideshare.net/MobileWish/semantic-design-system-redefining-design-systems-for-desops-v10-1sep-2018

Nuclear Design: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-2-nuclear-model-samir-dash/

Open Design System Ontology: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-3-open-ontology-samir-dash/?

 

 

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

 

 

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

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

You can explore more at http://desops.io/2018/10/03/workshop-at-ux-india-international-conference-2018-applying-desops-in-your-enterprise/ ]

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

Meanwhile, you can explore more here:

https://youtu.be/J5Igx25pj5A

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Fig. Ref: https://www.linkedin.com/pulse/desops-prepare-today-future-design-samir-dash/)

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

(Fig. Ref: https://www.linkedin.com/pulse/desops-prepare-today-future-design-samir-dash/)

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

(To be Continued to the next post)

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

Previous post of this series:

https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-1-background-samir-dash/

https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-2-roles-pattern-samir-dash/

You can also explore the following links:

‘Semantic Design System : Redefining Design Systems for DesOps’ https://www.slideshare.net/MobileWish/semantic-design-system-redefining-design-systems-for-desops-v10-1sep-2018

Nuclear Design: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-2-nuclear-model-samir-dash/

Open Design System Ontology: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-3-open-ontology-samir-dash/?

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: https://en.wikipedia.org/wiki/Milgram_experiment ) 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 http://desops.io/2018/05/13/infographic-the-vicious-circle-in-teams/ )

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 https://www.linkedin.com/pulse/desops-next-wave-design-part-12-teams-vicious-circle-avoiding-dash/]

 

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 http://desops.io/2018/05/10/infographic-the-full-stack-roles-in-desops/ )

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  https://www.linkedin.com/pulse/desops-next-wave-design-part-11-translating-value-different-dash/ )

Infographic: The Full-Stack Roles in DesOps

 

©2018,”The Full-stack Roles in DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License.

Download PDF from https://www.slideshare.net/MobileWish/infographic-the-fullstack-roles-in-desops-desopsio

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).

Infographic: The Ten Practices of DesOps (aka. DesignOps)

 

Download the PDF version here: https://www.slideshare.net/MobileWish/the-ten-practices-of-desops-aka-designops

©2018,”The Ten Commandments of DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License

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


(This article was originally published onApril 29, 2018 Linkedin Blog at https://www.linkedin.com/pulse/desops-next-wave-design-part-10-whenif-tool-capture-samir-dash/


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 http://desops.io/2018/05/07/when-if-then-tool-printable-version-for-a4-size-paper/

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 UX : Another Agile UX?

Agile is the most popular and successful SDLC model as of today as it allows better scope in providing continuous and iterative refinement to the product. Historically when developers out of their frustrations with waterfall model turned to the growing Agile Movement to regain their control over the process, they found that “like its ancestors, Agile also didn’t take UX into account. Several of the Agile methods, such as Scrum and XP, recommended users sitting with the team during the development process, but that isn’t the same as design. Everyone who figured out how to get what they wanted from plugging UX into a phased waterfall approach was now struggling to work inside the Agile methods. The Agile principles, that focus more on communication and less on contracts, didn’t fit the status quo UX processes”.So efforts were made again to implement UX into Agile methods just like the way it was implemented into waterfall model . But it was not easy as , in waterfall model there are 2 things which helped implemented UX :

  1. The objectives of the project stays same from kickoff to the point where the finished product is launched.
  2. The designers created the set of design specifications as a contract which the developers had to implement into the final product.

And above two cannot be expected from Agile model as it is based on iterations and gradual exploration of what is best fit for the final product . On ejust simply cannot predict the final design from the start of the project. So many attempts were made to get the best agile SDLC practices that can incorporate the UX , before “Lean UX” was born.

As the above figure shows the documentation and guidelines are stripped to their bare minimum components, providing the minimum amount of information necessary to get started on implementation. Also Long detailed design cycles are discarded in favor of very short, iterative, low-fidelity cycles, with feedback coming from all members of the implementation team early and often.

Challenges with Agile model of SDLC to implement UX

There are several challenges in implementing UX in Agile model effectively and these challenges include:

  • Different approaches. Usability methodologies are centered on the user and holistic view of the user needs whereas agile methodologies take a broader view and focus on the stakeholder. Agile methods primarily focus on delivering working software early.
  • Different goals: Software engineers focus on the technical design, implementation the system where as UX practitioners focus on “developing systems so end-users can use them effectively”.
  • Organizational challenges: The agile methodologies focus on strategy where teams are self-organizing whereas UX focuses on a centralized UX groups within some organizations so that the needed practices, tools, and standards can be provided.
  • UX practitioners struggle to be heard: Many UX practitioners often complain that the results of their work are not considered in the design decisions and even if it is heard, there seems to be focus more on engineering decisions over the usability decisions.

Lean UX and Agile Model

Many of UX practitioners see “Lean UX” as the answers to the challenge we see in implementing UX into an Agile SDLC where it uses “taking the best parts of our current UX practices and redesigning them specifically for use in an agile world”. Lean UX, is about reducing waste in a process by removing it from the value chain of the usability process..

The proactive measures for border engagement in Agile model has paved path to a new and more practical implementation of UX discipline and methods called “Lean UX” Lean UX once blended with any exiting Agile SDLC, helps to “create a more productive team and a more collaborative process” .

The basic principles Lean UX uses to provide positive refinements to SDLC are through the following 3 foundation stones for it:

  1. 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”.
  2. Agile Software Development: Core values of Agile are the key to Lean UX.
  3. 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

Lean UX and UX in Agile SDLC

“Lean UX” is seen as the answers to the challenge we see in implementing UX into an Agile SDLC. As discussed in the earlier chapters, Lean UX principles use “taking the best parts of our current UX practices and redesigning them specifically for use in an agile world”.

Lean UX solved many issues were even there with the practices and usability process used in waterfall and different derivative iterative models. In Lean UX practices, there is no more requirements for the “objectives will stay the same and that you can design for a single solution throughout the project”. Also there no more need for the designers to create bulky guidelines and documentations for the developers to be used as a contract. Rather the Lean UX practice upholding agile approach, only focuses on each independent design iteration as a “hypothesis” which has to be validated from a “customer perspective” and from a “business perspective” . The beauty here is because of the Agile process being followed, fast iterations can happen to quickly test hypotheses and get to a great design in the end of the project.

In context of a real world situation the Lean UX is something like:

“The traditional paper work is discarded, while the focus is turned to making sketches of the idea. Then the sketch is presented and discussed with the team. The initial prototype effort is very small comparing to detailed documents, so it’s easy to make changes. After it’s agreed internally, rough prototype is made and tested with users. The learning from users help refine the idea and iteration starts over again”

And this makes case for “collaboration with the entire team” as it becomes critical to the success of the product and the whole project.

The Beauty of Lean UX: Everything is familiar

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.

Lean UX is not Same as Agile UX

Lean UX is a totally different term than Agile UX.Lean UX details methods and their practical application in dynamic environment of a Lean StartupIt is the converging point for product development and business, through constant measurement and so called “learning loops” (build – measure – learn).

Agile UX defines update of Agile Software Methodology with UX Design methods. It aims to unify developers and designers in the Agile process of product development.

However Lean UX uses Agile UX methodologies, tools to coordinate their software development.

Foundation Stones of Lean UX:

The key ingredients of Lean UX which act as foundation stones for it are:

  1. 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”.
  2. Agile Software Development:
    Core values of Agile are the key to Lean UX. It forces on 4 major principles of Agile development to product design:

    • Individuals and interactions over processes and tools: This principle louds the concept of exchange of ideas freely and frequently in a team. “The constraints of current processes and production tools are eschewed in favor of conversation with colleagues”
    • Working Software over Documentation:This focuses on bringing out solution quickly so that it can be “accessed for market and viability”.
    • Customer Collaboration over Contract Negotiation:Collaboration with teammates and customers builds consensus behind decisions which results in faster iterations and lessens heavy documentations.
    • Responding to change over following a plan: “The assumption in Lean UX is that the initial product designs will be wrong, so the goal should be to find out what’s wrong with them as soon as possible” and this helps in finding the right direction quickly.
  3. 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. Typically startups are “free to build products in a manner which differentiate on quality”. Also startups can focus on “intrinsic value and usefulness of the product, rather than on a long list of mostly irrelevant features”. Startups have a distinguishable feature of reducing long product cycles into smaller, shorter chunks and validating these iterations with people that will use the products, actually opens the gate for important information needed to avoid expensive development cycles that come withsome kind of risk. ”The secret sauce of lean startup people is that they advocate for user experience research and design as one of the primary solutions to their business problems, and they do it using plain language”.

Lean Startup method: The concept of “Build-Measure-Learn”

The fundamental activity of a startup is to “turn ideas into products” at the first step. Next it has the aim to measure how customers respond and then to learn whether to pivot or persevere. So basically a startup’s success depends on this feedback loop. To be successful a startup has to accelerate that feedback loop. The feedback loop being employed here includes three primary activities: build the product, measure data and learn new ideas.

However the Lean Startup method employed in Lean UX , is slightly different – it’s basically about “Think-Make-Check”. The difference lies in the fact that in latter case the “feedback loop incorporates your own thoughts as a designer, not just ideas learned through measurement”.

Minimum Viable Product (MVP) – Prototyping at it’s best in Lean Startup Method

Minimum viable product is a version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The MVP is, in fact, an early prototype that serves as a tool to learn and test the team’s assumptions.

Lean UX is where prototyping is best promoted, focusing the prototype on major components of the experience. Once created, it will be immediately testable by any and all users to start the feedback loop. In most of the case the fidelity of the prototype is not a road block, rather the only mission is to get a quick prototype that can be tested quickly. However where the need for better visualization has priority, the best practices and tools are used to develop high fidelity prototypes in shortest time possible.

Principles of Lean UX

There are some guiding principles behind Lean UX which can be used to make sure the methodologies used in a Lean process is on track.

  1. 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).
  2. 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 smaller team as keeping track of status report , change management and learning.
  3. 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.
  4. 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”.
  5. 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.
  6. Small Batch Size: Lean UX focuses on “notion to keep inventory low and quality high”.
  7. Continuous Discovery: “Regular customer conversations provide frequent opportunities for validating new product ideas”
  8. 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.
  9. 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.
  10. 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.
  11. Externalizing Your Work:“Externalizing gets ideas out of teammates’ heads and on to the wall, allowing everyone to see where the team stands”.
  12. 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”.
  13. Learning over Growth: “Lean UX favors a focus on learning first and scaling second”.
  14. 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”.
  15. 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 artifacts the team uses to gain that knowledge are irrelevant.”

(c)2013-14, Samir Dash

This article a part of the title UX Simplified: Models & Methodologies by Samir Dash (ISBN: 978-1-3115-9110-4 / ASIN: B00LPQ22O0 )

“When/If – Then” Tool : Printable Version ( A4 Size Paper)

This “When/If – Then” tool helps to formalize hypothesis or assumption for any Hypothesis -Driven Design or Development.

This tool is 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.

Feel free to download and use.

Licence:

(c) 2018, “When/If – Then” Tool by Samir Dash

Creative Commons Attribution-Share Alike 4.0 International License