External Post – DesOps is “DevOps 2.0”

DesOps is “DevOps 2.0” . Read it at Red Hat Developers Blog here – https://t.co/sBBhKsSpoQ


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

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

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

Read the full post at https://developers.redhat.com/blog/2018/06/27/desops-is-devops-2-0/

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

User-Centered Systems Design (UCSD)

(Originally first published on July 2, 2014 at https://www.linkedin.com/pulse/20140702065559-9377042-user-centered-systems-design-ucsd/ )

Also, this article is a part of the title UX Simplified: Models & Methodologies by Samir Dash (ISBN: 978-1-3115-9110-4 / ASIN: B00LPQ22O0 ).  Available at Amazon: http://www.amazon.com/dp/B00LPQ22O0/

User-Centered Systems Design (UCSD) is set of “usability design” process focusing on usability throughout “the entire development process and further throughout the system life cycle”. It is based on the following key principle:

  1. User focus: The goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should control the development.
  2. Active user involvement: Representative users should actively participate, early and continuously throughout the entire development process and throughout the system life cycle.
  3. Evolutionary systems development: The systems development should be both iterative and incremental.
  4. Simple design representations: The design must be represented in such ways that it can be easily understood by users and all other stakeholders.
  5. Prototyping: Early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the users.
  6. Evaluate use in context: Baseline usability goals and design criteria should control the development.
  7. Explicit and conscious design activities: The development process should contain dedicated design activities.
  8. A professional attitude: The development process should be conducted by effective multidisciplinary teams.
  9. Usability champion: Usability experts should be involved from the start of project to the very end.
  10. Holistic design: All aspects that influence the future use situation should be developed in parallel.
  11. Process customization: The UCSD process must be specified, adapted and implemented locally in each organization. Usability cannot be achieved without a user-centered process. There is, however, no one-size-fits-all process.
  12. A user-centered attitude must be established: UCSD requires a user-centered attitude throughout the project team, the development organization and the client organization.

The typical process flow of UCSD can be visualized as the following steps (based on ISO/TR 18529:2000):

  1. Pre-study and business analysis: It can be anything from a comprehensive analysis of work procedures, business processes, etc., to a brief statement or vision.
  1. Planning the user-centered systems design process: includes setting up the project with resources, activities, roles, methods, etc.
  1. Do iterative UCSD /Usability Design Activities: The usability design process approximately.
  1. Formal Summative Evaluation: It covers the usability of the resulting system, as opposed to the formative evaluations used in the usability design process to learn about details in the design .
  1. Introduce and Operate the System: includes installation, change management, user training, evaluating long-term effects and so forth.

The focus of UCDS is all about “changing the attitude among all professionals involved in the software development process” and these set of 10 principles are key for the “user-centered systems design process” which helps in giving “equal weight to interaction design, analysis and evaluation, combining interaction design, and usability engineering”.


(c)2012-13 : Samir Dash. All rights reserved.

Usability Design and User-Centered Design (UCD)

(Originally first published on July 2, 2014 at https://www.linkedin.com/pulse/20140702070557-9377042-usability-design-and-user-centered-design-ucd/  )


The Usability Design is roughly a subset of the UCSD process that matches the “Do Iterative UCSD” step of the UCSD process.

The usability design outlines the steps in the development process involving usability design aspects. The process can be divided into three main phases:

  1. Requirements analysis: This step is synonymous with planning and analysis phase of typical software development life cycle(SDLC).
  2. Growing software with iterative design: This is the design and testing phase and development phase of typical SDLC.
  3. Deployment: This is same as deployment phase of typical SDLC.

User-centered design (UCD) is a set of design processes in which “the needs, wants, and limitations of end users of a product are given extensive attention at each stage”. It is characterized as a multi-stage problem solving process involving designers who take the lead responsibility in foreseeing and solving the usability problems the users are likely to face while interacting with or using the system/product. UCD focuses on understanding the behavioral aspect of the user interacting for the first time so that the user’s learning curve in using the system can be evaluated in order to optimize and reduce it. User-centered design philosophy emphasizes on optimizing the product around “how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product”.

Constantine and Lockwood define UCD as :

‘. . . loose collection of human-factors techniques united under a philosophy of understanding users and involving them in design’. . . ‘Although helpful, none of these techniques can replace good design. User studies can easily confuse what users want with what they truly need. Rapid iterative prototyping can often be a sloppy substitute for thoughtful and systematic design. Most importantly, usability testing is a relatively inefficient way to find problems you can avoid through proper design’. (‘. . . loose collection of human-factors techniques united under a philosophy of understanding users and involving them in design’. . . ‘Although helpful, none of these techniques can replace good design. User studies can easily confuse what users want with what they truly need. Rapid iterative prototyping can often be a sloppy substitute for thoughtful and systematic design. Most importantly, usability testing is a relatively inefficient way to find problems you can avoid through proper design’.

Putting it straightforward UCD is all about 4 factors which are mostly related to the end user :

  1. Needs of users
  2. Limitations of users
  3. Preferences of users
  4. Business objectives of the product.

This helps in achieving the following benefits:

  1. User satisfaction through more user friendly product experience
  2. Increase in customer /user loyalty.
  3. Making the product more relevant and valuable for the user
  4. Product / system is more value added as users

