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: http://desops.io/2018/05/09/infographic-the-ten-practices-of-desops-aka-designops/

 

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 https://medium.com/eunoia-i-o/quick-guide-notes-on-the-ibm-design-thinking-78490d7433dd.

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 https://www.linkedin.com/pulse/20140702070557-9377042-usability-design-and-user-centered-design-ucd/. 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: https://www.linkedin.com/pulse/20140706143027-9377042-challenges-in-ux-integration-with-different-sdlc-models/

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:https://www.linkedin.com/pulse/20140710010240-9377042-lean-ux-another-agile-ux/?

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 Automationhttps://medium.com/eunoia-i-o/re-imagining-beta-testing-in-the-ever-changing-world-of-automation-3579ac418007 )

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 – https://medium.com/eunoia-i-o/re-imagining-beta-testing-in-the-ever-changing-world-of-automation-3579ac418007 .

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  https://www.linkedin.com/pulse/desops-next-wave-design-part-6-10-principles-driving-its-samir-dash/  )


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: http://desops.io/2018/05/08/infographic-the-ten-commandments-of-desops/

 

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 https://medium.com/eunoia-i-o/quick-guide-notes-on-the-ibm-design-thinking-78490d7433dd  )

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 https://medium.com/design-ibm/specstra-experimenting-with-automation-in-design-industry-4641c0b4244d 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 https://developers.redhat.com/blog/2018/01/05/beta-testing-automation/

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.

DesOps : the Next Wave in Design

DesignOps or DesOps is an approach to design, inspired by the culture of DevOps. In this article series, we will be touching upon the practical approaches on how to prepare for this next-wave in design that compliments DevOps in the concepts of a cultural shift, collaboration and automation. We will also see what are the available solutions today that contribute to bringing the full circle of design in the context of software development lifecycle.

In today’s world, while design as a discipline is getting more and more recognition across the entrepreneur world and many industry efforts like IBM Design Thinking and similar frameworks, trying to create a synergy between the Agile approach of SDLC and the Design Thinking. It is an interesting crossroad in time where the next big thing in product delivery is to bring scalability as well as automation to the creative process. In the context of the Software industry, I always see “Design” as an intersection between creativity and the technology where both shape each with the help from user-needs and blending of these results into successful products. Any typical software product delivered involves many complex as well as diverting technologies, processes, people and visions. Though mostly a software delivery happens with the team members decided in two major groups – developers and designers, ultimately the best outcome always depends on the fact that how these two teams communicate with each other and how efficiently the thoughts and ideas are shared, propagated and translated.

When it comes to product development, the amount of complexity and the variety of aspects starting from the diversified thinkings, technology, tools and processes that go into it, is significant. Attempts have been made over the period to improve various aspects of it ensure the delivery process can be optimised to scale upto the ever-expanding needs. In software and IT infrastructure industry, recently one such phenomenon was DevOps that focused on rethinking the development and operations to improve productivity and efficiency. DevOps started in the industry towards the last part of the first-decade post-millennium. Back in 2008, there was a fine separation between the roles who code and the roles who deploy them. Basically, the coders or the programmers were responsible with code generation while the infrastructure guys were looking after the process of deploying them.

Due to the rise of Agile process, this code generation and deployment as a part of delivery became more frequent and continuous unlike the age-old waterfall model, when it used to happen every 6 months or a year. In all major software services industry, it was common to have fixed calendar dates in the year that represented the release or deployments. The 2-3 weeks sprints of Agile approach made it obsolete in many. As the continuous delivery became the defacto standard, this narrowed down the gap between the development team and infrastructure team. This also gave rise to the need of multidisciplinary roles or individuals who can bridge the gap between the production environment and the development server, allowing their code to be deployed in a more efficient way and faster. As the DevOps took shape, the practices around it grew from a few talented hackers to a profession with a culture of its own involving its own set of tools, practices, technologies and workflows which became the norm in the industry today.

Most of the DevOps today focuses on the process blocks mostly impacted Engineering or technical aspects of the product rather than the design aspect. To bridge that gap, in recent times many attempts are being made to define a consistent approach called DesOps. The DesOps or DesignOps is a relatively new term. Many, to comprehend better, refer to DevOps, which has the prominent similar underlying philosophies and goals. Design operations (aka DesignOps ) is though relatively new concept yet is a growing area of concern for design teams seeking to help their teams increase the value they produce for their host organizations and that organization’s customers. The term and the practices exist inconsistently in many attempts made by different organisations since many years.

Even when we try to implement a DevOps geared process to run a Design driven process model, still the actual challenges, the gaps between the design and development or the design and testing blocks are not fixed. So without implementing a DesOps or DesignOpsto fix the design and other endpoint blocks in the process, the implementation of DevOps will never yield the desired outcome and will not be able to sustain the core philosophies behind it.

DesOps and DevOps both are complementary to each other. The Design delivery process improvements try to optimise the overall delivery process and thereby contributing to the DevOps. For example the aspects such as testing of the product that involves design aspects, usability, accessibility etc. In the testing phase needs some benchmark to referee to that can only come from a process where the DesOps has implemented that outputs and feeds the benchmark to the DevOps phase where the testing block can use it. In addition to this when we are in Agile or iterative and continuous process models, at each sprint cycle the end to end flow is executed and thereby making the Continous Integration(CI) and Continous Delivery (CD) truly meaningful.

DesOps, was primarily born out of the primary need of how to design at scale. The factors that shaped it are of similar nature that shaped DevOps. With the new age software delivery in recent times, with the Agile process and Continuous Integration and Deployment of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over the period with Agile and Then the DevOps to its current shape.

However, as the design was an integral part of any product delivered, the necessity to ensure the gaps between traditional design life cycle working along with the fast track of development life cycle using DevOps are bridged. The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During recent two-three years, the top five big companies heavy investments into this area pave the way for other organisations and design communities to be more explorative in this area. The implications of DesOps is reflected in the outcome, where the silos among the teams and disciplines get reduced. Along with this, it improves the collaboration among cross-functional team and working practices, that contributes to minimising wastage in the delivery process.

Keep tuned in… next, we will start explorations with the basic blocks for DesOps – i.e. the Design Systems.

 

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

[This was originally first published onMarch 26, 2018 on Linkedin at https://www.linkedin.com/pulse/desops-next-wave-design-part-1-samir-dash/]