You can read a related article Translating Value at Different Stages of Design with Minimal Waste here: http://desops.io/2018/05/12/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/ )
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
(Apart from some details about my prototype in Beta Testing, this also explores the interesting definitions from ISO regarding quality that brings “reviews in context” that fundamentally lauds usability philosophies. (Originally first published at RedHat Blog in January 2018)
Beta testing is fundamentally all about the testing of a product performed by real users in a real environment. There are many tags we use to refer to the testing of similar characteristics, such as User Acceptance Testing (UAT), Customer Acceptance Testing (CAT), Customer Validation, and Field Testing (more popular in Europe). Whichever tag we use for these testing cases, the basic components are more or less the same. To discover and fix potential issues, this involves the user and front-end user interface (UI) testing, as well as the user experience (UX) related testing. This always happens in the iteration of the software development lifecycle (SDLC) where the idea has transformed into design and has passed the development phases, while the unit and integration testing has already been completed.
The beta stage in the product lifecycle management (PLM) is the ideal opportunity to hear from the target market and to plan for the road ahead.
As we zoom into this phase of testing it has a board spectrum of ranges. On one side is the Front-End or UI related testing involving UI functionality (Cosmetic, UI level Interaction and Visual look and feel). At the other end is the User Experience (UX), including user testing involving more from A/B (split) testing, hypothesis, user behavior tracking and analysis, heat maps, user flows and segment preference study or exploratory testing and feedback loops.
Beta testing relies on the popular belief that goodness will prevail, which defines the typical tools that carry out such tests. Examples are the shortening of beta cycles, reducing the time investment, increasing tester participation, improving the feedback loop and visibility, etc.
The Importance of Beta Testing
If we dive deeper into the factors behind the existence of tools from different angles, we find two major reasons that advocate the importance of beta testing:
1. Left-right brain analogy, which points to the overlap between humans and technology.
The typical belief is that the left-hand side of the brain mostly processes the logical thinking, while the right-hand side is more about the emotional thinking. Based on this popular analogy, when we map the different aspects involved in different stages of SDLC for a digital product across a straight line from left to right (refer to the diagram below), we will notice the logical and more human-centered aspects are divided by an imaginary line from the center. We will also notice the gradual progression of the emotional index for the components from left to right.
When we map these to the beta testing phase, we notice these right-hand components are predominant. As users of the products (like humans), we are more emotionally connected to such aspects of the product, which are validated or verified in a beta test. This makes beta testing one of the most important testing phases in any SDLC.
Another interesting point to note is that when we look from the traditional software approach to define “criticality”, the areas that are tested during user acceptance testing (UAT / Beta), mostly fall into Class 3 and 4 type of criticality. But because these touch the core human aspects, they become more important. This Youtube video (Boy Receives Enchroma Glasses From Father) helps to illustrate the importance of technology touching the human emotions. It was posted by a popular brand of glasses to demonstrate how they can correct colorblindness in real time for the end user.
Interestingly, this is an aspect of “accessibility”, which is typically covered during a beta test. Considering this video, the aspect of accessibility naturally raises the question about what we can do for this father and son as a tester, as a developer, or as a designer? And when we look at the stats, we find that the number of people the accessibility impacts is huge. One in every five people is challenged by some kind of disability. And unfortunately, some reports indicate that a majority of websites do not conform to the World Wide Web contortion’s (W3C) accessibility guidelines (in 2011 almost 98% of websites failed the W3C’s accessibility guideline).
This helps to demonstrate the human angle, which advocates why beta testing is important to ensure these aspects are validated and verified to ensure the target user needs are completely met.
2. A second reason for advocating the importance of beta testing is evaluating it from the international standards perspective (ISO/IEC 9126-4). This helps to define the difference between usability and quality.
The International Standards Organization (ISO) has been focused on the standards around quality versus usability over time. In 1998 ISO identified efficiency, effectiveness and satisfaction as major attributes of usability. In 1999 a quality model was proposed, involving an approach to measure quality in terms of software quality and external factors. In 2001 the ISO/IEC 9126-4 standard suggested that the difference between usability and the quality in use is a matter of context of use. ISO/IEC 9126-4 also distinguished external quality versus internal quality and defined related metrics. Metrics for external quality can be obtained only by executing the software product in the system environment for which the product is intended.
This shows that without usability/human computer interaction (HCI) in the right context, the
quality process is incomplete. The context referred to here is fundamental to a beta test where you have real users in a real environment, thereby making the case of the beta test stronger.
Beta Testing Challenges
Now that we know why beta testing is so very critical, let’s explore the challenges that are involved with a beta stage.
Any time standards are included, including ISO/IEC 9126, most of these models are static and none of them accurately describe the relationship between phases in the product development cycle and appropriate usability measures at specific project milestones. Any standard also provides relatively few guidelines about how to interpret scores from specific usability metrics. And specific to usability as a quality factor, it is worth noting that usability is that aspect of quality where the metrics have to be interpreted.
When we look at popular beta-testing tools of today, the top beta testing tools leave the interpretation to the customer or to the end-user’s discretion. This highlights our number one challenge in beta testing, which is how to filter out pure perception from the actual and valid issues and concerns brought forward.
As most of the issues are related to user testing (split testing and front-end testing), there is no optimized single window solution that is smart enough to handle this in an effective manner. Real users in the real environment are handicapped to comprehend all the aspects of beta testing and properly react. It’s all a matter of perspective and all of them cannot be validated with real data from benchmarks or standards.
The World Quality Report in 2015-16 Edition indicated that expectations from Beta testing is changing dramatically. It hinted that the customers are looking for more product insights through a reliable way to test quality and functionality, along with the regular usability and user testing in real customer facing environment.
It’s not only the Beta Testing, but more user-demand is also impacted by the rising complexities and challenges due to accelerated changes in the technology, development, and delivery mechanisms. The 2017-18 World Quality Report states that the test environment and test data continue to be an achilles heel for QA and Testing. The challenges with testing in agile development are also increasing. There is now a demand for automation, mobility, and ubiquity, along with smartness to be implemented in the software quality testing. Many believe that the analytics-based automation solutions would be the first step in transforming to smarter QA and smarter test automation. While this true for overall QA and testing, this is also true for Beta Testing, which deals with the functional aspect of the product.
Let’s see where we stand today. If we explore popular beta testing solutions, we will get a big vacuum in the area where we try to benchmark the user’s need for more functional aspects, along with the usability and user testing aspects. Also, you can notice in the diagram below that there is ample space to play around with the smart testing scenario with the use of cognitive, automation, and machine learning.
(Note: Above figure shows my subjective analysis of the competitive scenario.)
Basically, we lack “smartness” and proper “automation” in Beta Testing Solutions.
Apart from all these, there are some more challenges that we can notice if we start evaluating the user needs from the corresponding persona’s viewpoint. For example, even when assuming that the functional aspect is to be validated, the end-user or the customer may have an inability to recognize it. The product owner, customer, or end-user are part of the user segment who may not be aware of the nuts and bolts of the technology involved in the development of the product they are testing to sign it off. It’s like the classic example of a customer who is about to buy a second-hand car and inspects the vehicle before making the payment. In most of the cases, he is paying the money without being able to recognize “What’s inside the bonnet!”. This is the ultimate use-case that advocates to “empower the customer”.
So, how do we empower the end user or the customer? The tools should support that in a way so that the user can have his own peace of mind while validating the product. Unfortunately, many small tools which try to solve some of those little issues to empower the user are scattered (example: Google Chrome extension that helps to analyze CSS and creates the report or an on-screen ruler that the user can use to check alignment, etc.). The ground reality is that there is no single-window extension/widgets based solution available. Also, not all widgets are connected. And those which are available, not all are comprehensible to the customer/end-user as almost all of them are either developer or tester centric. They are not meant for the customer without any special skills!
When we look at the automation solutions in testing as part of much Continous Integration (CI) and Continuous Delivery (CD), they are engaged and effective in mostly “pre-beta” stage of SDLC. Also, they require specific skills to run them. With the focus on DevOps, in many cases, the CI-CD solutions are getting developed and integrated with the new age solutions looking at the rising complexities of technology stacks, languages, frameworks, etc.. But most of them are for the skilled dev or test specialists to use and execute them. And this is something that does not translate well when it comes to Beta testing where the end-user or the customer or the “real user in real environment” are involved.
Assuming we can have all these automation features enabled in BETA, it still points to another limitation in the existing solutions. It’s because the employment of automation brings in its own challenge of “information explosion”, where the end user needs to deal with the higher volume of data from automation. With so much information, the user will struggle to get a consolidated and meaningful insight of the specific product context. So what do we need to solve these challenges? Here is my view — we need smart, connected, single window beta testing solutions with automation that can be comprehensible to the end-users in a real environment without the help of the geeks.
For sometime since a last few years, I have been exploring these aspects for the ideal beta testing solution and was working on the model and a proof of concept called “Beta Studio”, representing the ideal beta testing solution, which should have all these — Beta-Testing that utilizes data from all stages of SDLC and PLM along with the standards + specs and user testing data to provide more meaningful insights to the customer. Test real applications in real environments by the real users. Customer as well as end-user centric. Test soft aspects of the application — Usability, Accessibility, Cosmetic, etc.. Be smart enough to compare and analyze these soft aspects of the application against functional testing data.
Use machine-learning & cognitive to make the more meaningful recommendation and not just dump info about bugs and potential issues. Here is an indicative vision of Beta Studio:
Mostly this vision of the ideal beta testing solution touches upon all the aspects we just discussed. It also touches upon all the interaction points of the different personas; e.g. customer, end-user, developer, tester, product owner, project manager, support engineer, etc.. It should cover the entire Product Life Cycle and utilize automation along with the machine learning components such as Computer Vision (CV) and Natural Language Processing (NLP). Then gathering this information to be processed by the cognitive aspect to generate the desired insights about the product and recommendations. During this process, the system will involve data from standards and specs along with the design benchmark generated from the inputs at the design phase of the SDLC, so that meaningful insights can be generated.
In order to see this vision translated into reality, what do we need? The following diagram hints about the six steps we need to take.
- First we should create the design benchmark from the information at the design stage that can be used in comparing the product features against metrics based on this design benchmark.
- Then automate and perform manual tracking of the product during runtime in real time and then categorize and collate this data.
- This involves creating features to support the user feedback cycle and user testing aspects (exploratory, split testing capabilities).
- Collect all standards and specifications on different aspects — e.g. Web Content Accessibility Guideline (WCAG) Section 508, Web Accessibility Initiative Specs ARIA, Design Principles, W3C Compliance, JS Standards, CSS Standards & Grids, Code Optimization Metrics Error codes & Specs, Device Specific Guidelines (e.g. Apple Human Interface Guideline) etc.
- Build the critical components such as Computer Vision and Natural Language Processing units which would process all the data collected in all these stages and generate the desired metrics and inferences.
- Build the unit to generate the model to map the data and compare against the metrics.
- The final step is to build the cognitive unit that can compare the data and apply the correct models and metrics to carry out the filtering of the data and generate the insights which can be shared as actionable output to the end-user/customer.
While experimenting for BetaStudio, I have explored different aspects and built some bare bone POCs. For example, Specstra is a component that can help create Design benchmark from design files.
With Specstra I was trying to address the issues related to the cosmetic aspect or visual look and feel. Typically when it comes to cosmetic issues, more than 30% are non-functional and mostly cosmetic. There is no reliable solution that helps in benchmarking these kind of issues against specific standards. One third of the issues found during the beta / UAT stages of testing are mostly cosmetic and alignment issues, including category 3 and 4 types. And these happen mostly because the two persona’s involved (developer and designer) have their own boundaries defined by a mythical fine line.
When a developer is in focus, roughly 45% of them are not aware of all the design principles employed or the heuristics of UX to be employed. Similarly, half of the designers are not aware of more than half of the evolving technological solutions about design.
And in 70% of the of the projects, we do not get detailed design specs to benchmark with. Detailing out a spec for design comes with a cost and required skills. In more than two-thirds of the cases of development there is the absence of detailed design with specs. Many of the designs are not standardized and most of them do not have clear and detailed specs. Design is carried out by different tools so it is not always easy to have a centralized place where all the designs info is available for benchmarking.
Specstra comes in handy to solve this. It is an Automation POC that is more like a cloud-based Visual Design Style Guide Generator from the third party design source files. This is a case where the user would like to continue using his existing Design tools like Photoshop/Sketch or Illustrator, PDF etc..
You can view the video of the demo here:
View the demo of the BetaStudio POC here:
I understand that reaching the goal of an ideal beta testing solution might require effort and will likely evolve over time. Rest assured, the journey has started for all of us to connect and explore how to make it a reality.
Originally published at the RedHat Blog at https://developers.redhat.com/blog/2018/01/05/beta-testing-automation/
This post talks about one of my weekend experiments, back in 2013, to explore the possibilities of automation to create visual design specification documents. (Originally published in March 2017 at Design at IBM Blog and other sites. )
‘Automation’ is the buzz now in every nook and corner of the tech industry. When we try to resolve productivity issues involved in design domain that is now powering Design driven Software Development Life Cycles (SDLC), we always end-up with a little innovation and that’s what the story of ‘Specstra’, is all about.
Automation is one of the trending phenomenon of the current technological world. Manufacturing industry has been pioneering it for decades. Other verticals are following it. In software development, testing and deployment field, automation is popularized by Dev OPS and Continuous Integration (CI) which help speed-up the software development life cycle (SDLC). But the SDLC includes the design process components along with the technology driven ones.
In today’s world, while design 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 automation is to, bring it to the creative process. In cthe ontext of 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. This also is the reason automating designing process is a lot more challenging than building solutions for automation of purely technology driven process.
Few years back, at an R&D center of a leading mobile brand in Bangalore, I was part of a creative team, where almost 70% of the crowd were visual designers. Many of the creative crowd, complained about the design process that involved creation of style guide of the apps that they were working on. Every app-project used to be developed for different flagship phones models with different resolutions as well as screen densities. And being developed in native languages for Android view-ports, designer used to develop each style guide for each project separately for each model of phone. Each style-guide has to be detailed to pixel level which the designer has to calculate and define taking calculation of the view port Pixel Density (PD). Many designers have to maintain different versions of the mock-up and the create specs for each version, which was more like a “drafts man’s job” with lesser creative moments for expressions and innovation than the previous phase where the designer has to follow the wire-frame and come up with pixel perfect mock-ups of the app screens.
Almost all the designers tried to grab their hands on the creative part of the job, getting engaged with the stake-holders and the designers preferred to avoid working on the style-guide, though they would love to review one. The ‘not-so-seniors’ worked on the drafting of the guide and churned out the specs document, yet do the crying that it is less creative even though it is one of the most critical part of the design process. On calculating how much effort we are giving to a creative phase of creating a visual mock-up vs. a drafting work, it turned out that roughly on average, one view of a single screen to be mocked up in something around 4–8 hours. Creation of a very detailed spec. might need 4–6 hours of job. But if it is designed for multiple view-ports of an operating system with significant pixel density change along with varied resolutions, then this drafting time gets multiplied. So by creating 4 generations of phone models running different generation of Android might need 16–24 hours. So the designer actually takes roughly one week of work for a view in this case from wire-framing stage to finished design with specs ready for the developer. Averagely an app can have 10 views, so the whole app would need approximately a month of work to be designed and be ready for 4 different models. Even though this is a very high level bare-bone calculation, it indicated a few things –for the designer 1/4th of his work remains creative whereas the remaining 3/4th of his time is a purely drafts-man job, leading to an unsatisfying job experience.
Similarly for the organization, they are is paying higher fee for lower type of work, as the typical higher salary of the designer is spent in that 3/4th of the lower type less creative work. Moreover, even though the 3/4th of the job is lower profile job, which could have been automated, consumes more from the delivery time. if we look at the timeline of the delivery of the design deliverables, we see that 1/4th of the delivery time is actually spent in creative way. So actually if there is a scope to automate the low profile manual work, where the designer does not need to use his right brain, then the deliverables could have been delivered in just 1 week instead of a month! Also note that time is money for industry, so the organization is actually spend 300% more than it should and that too on a higher price point. Again, apart from this there are other factor that contributed to above problem. Being in a world of rapidly changing requirements, many industry are following “Agile” or “Iterative” approach of work. Which means in the short notice things can change even to the look and feel and UI aspect which would mean a change to the style guide if view of standard control lines are affected. This has a cascading effect that flows through the style guide work. So any change in such requirement means the wastage of effort and addition of new efforts to keep the specs aligned.
Again, apart from this there are other factor that contributed to above problem. Being in a world of rapidly changing requirements, many industry are following “Agile” or “Iterative” approach of work. Which means in the short notice things can change even to the look and feel and UI aspect which would mean a change to the style guide if view of standard control lines are affected. This has a cascading effect that flows through the style guide work. So any change in such requirement means the wastage of effort and addition of new efforts to keep the specs aligned.
Specstra is a pet prototype that I had started working on, 3 years back (around 2013) to explore a possible solution for design related automation process. The user can upload Adobe Photoshop ( PSD), Adobe Illustrator (.AI), or PDF formatted exported from any design tool (Corel draw, Paint etc.) and within minutes Specstra can generate style guide which other wise would have taken the user days to complete and that with prone to error.
Based on these findings, in 2013, I had started working on a pet experiment Specstra, to explore a possible solution for design related automation process specially creation of the visual style guides out of different design file formats. Basically, my focus was to automate the blocks that were more aligned to less creative activity so that these blocks can be removed from the creative process flow. As of today, Specstra become one of the proof of concept software of its kind where the user can upload Adobe Photoshop (.PSD), Adobe Illustrator (.AI), or PDF formatted exported from any design tool (Corel draw, Paint, InDesign etc.) and within minutes it can generate style guide which otherwise would have taken the user days to complete and that with chances of having human error.
Basically, it proved that the typical designer pain-points like tedious manual process, higher consumption of effort, time and cost of coming out with style guides can be removed with automation. Bigger than that, this experiment proved that automation is possible in design creative process!
[ Originally published on March 4, 2017, at Design at IBM ]
Each design is a proposed business solution which is essentially is a hypothesis. Any design process — as strives to get the answer or solution to a fundamental problem — essentially starts with the problem in mind and some assumptions in mind, which is mostly a hypothesis. And to solve the problem, with the assumed hypothesis or the business value in mind, the designer iterates and if he uses User-Centered Development (UCD) approaches, he would go into the cycle of Think – Make – Test cycle. And this implicit way of solving the issue creatively uses references to different aspects of business, namely :
- The complete business offering
- Customer orientation and service innovation for customer relationship
- Business Infrastructure
- Revenue Streams
- Productivity and Cost control structures
As DesOps principles and practices have Hypothesis Driven Design & Development (HDD) and UCD process as its core components, it also refers to the same business value propositions. Implementing DesOps actually takes these into consideration and tries to use technology to improve the process around these.
If we refer to any standard business model frameworks such as Business Model Canvas, a template that is popularly used for developing and investigating every important aspect of the organization. The framework in such a template outlines investigations for areas such as key partners, key activities, key resources, value propositions, customer relationship, channels, customer services, cost structure and revenue streams, which always helps to understand and identify the core goals, strengths and priorities of the business that provides the context in which the UX has to be seen. This can be seen in the following equation: “Customer needs + Business context +Technological feasibility = Successful UX making the successful product”.
In a business model, we refer to UX when we plan a strategy for “Value Proposition”. In the typical Business model Canvas, value proposition involves areas like the following, which can be seen traced back to DesOps principles & practices.
- Newness: In DesOps, this is associated with “Continous Discovery” and “Design Thinking” practices.
- Performance: Improving performance by optimizing the process blocks through Agile & Lean methodologies through the implementation of automation through service design approach.
- Customization: DesOps implementation focuses on customizing the process blocks through service design approach and defining business process redesign/engineering.
- “Getting the Job Done”: This is fundamentally the result oriented approaches taken in DesOps which touches upon different aspects like roles, cohesive team play, removing wastage through Lean methodologies and the similar.
- Design: This is core to DesOps, and is seen as the creative problem-solving.
- Brand/ Status: Brand and Status is well associated with the feedback loops that include the real users in context and feeding the design process with continuous feedback including brand perception and related mental model of the user of the target segment.
- Price: Though purely a market associated component, the price can be dramatically reduced through implementation of DesOps, as it focuses on reducing waste and improving efficiency through automation and process improvements
- Cost Reduction: It is one of the fundamental components of ROI on DesOps in an organization. DesOps helps reducing cost through service design approach to optimize and redefine business process.
- Risk Reduction: DesOps helps reducing ambiguity by the implementation of optimized process and automation powered by the feedback loop that touches all the roles and the aspects be it human or machine in context. This improves reliability and thereby reduces risk.
- Accessibility: Through the implementation of Design Thinking, UCD model like contextual and participatory designs and continuous feedback loop, DesOps helps to ensure the accessibility factors are in consideration while iterating over a design.
- Convenience/ Usability: Through its advocacy of UCD models and Design Thinking and integrated feedback loop, DesOps help in ensuring usability aspects in all design delivered.
From a product manager’s standpoint, the successful UX meant for a business must balance between the needs of the users and the feasibility of implementation of the UX solution within the business context, and all the practices and principles of DesOps converge towards this.
(c) 2018, Samir Dash. All rights reserved.
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:
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 —
- 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.
(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 —
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 —
- Needs of Users
- Limitations of Users
- Preference of Users
- 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.
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.
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.
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.
To understand where a DesignSystem of an organisation stands in context of implementing a DesOps, first step is to evaluate the existing DesignSystem that is in place and contributes to the organisation’s design process. (We will explore the process aspect in details, in later articles in this series.) To evaluate any DesignSystems in a broadway we can easily form a metrics that takes care of the following two perspectives on the system.
Designer System Types
Typically the Design Systems can be broadly categorised into 3 types, namely: Static, Dynamic and Generative :
Static: Most of the attributes and elements that make this system is mostly static in nature. For example in a Static type Design System, the style guide may be pre-defined print ready reference, defining basic color standards and typography etc. The user has to read through and manually refer it to decide those related attributes in his work. This kind of System mainly prescribes guidelines, rules, principles which does not automatically change or created in a dynamic way either in the stages of creation or implementation by the developers etc. Typical organisational style guides or UI pattern documentations where the system describes how and where to use the patterns with some sample code to refer are falling under this kind of categories.
Dynamic: This kind of Design Ssystem have the content as well as the principles of implementations are designed and developed in a way that can be directly used in the code. The creation and implementation of the content are dynamic and mostly geared towards the actual elements that can directly be used in the code. This kind of Design System is more than a reference system for the developer, rather as a part of the actual build of the actual products developed as a part of it. Most easily noticeable traits of this kind of design system is that some special purpose frameworks, code libraries are part of it, which integrate into the actual builds of the products.
Designer System Maturity
The other angle to look at the Design Systems is to scale the maturity to measure how much the system has evolved. One of most important aspect of any Design System is to understand the maturity of it, as this helps to understand where it is in the overall DesOpsroadmap. Irrespective of the varied and complex categorisation of the same, we can still name the maturity as Low , Medium and High to get a quick and easy comprehension. And when we try to map the maturity, it takes care of the categorisation aspect.
Low Maturity: When the Design System has a low maturity, it mostly depends on the static attributes that we discussed above. The creation and maintenance of different attributes are mostly the result of manual effort and the most interesting point about this is that the designer and developers have the cognitive load to refer and comprehend and take decisions on what to use and not use in specific context of their work or product. It is also important, there may be some attributes which might have dynamic attributes , but most of them are out of the transition that the design system is having due to its evolution,
Medium Maturity: In the Design Systems with medium maturity, the most elements and attributes are mainly dynamic in nature. These systems mostly depend on the frameworks, libraries etc. There may be some overlaps in static and well as generative attributes.
High Maturity: Similarly in Higher maturity, apart from the fact that it mostly contains generative attributes, it involves the aspects of automation, computer-vision and may deploy artificial intelligence (AI) to provide continuous pipelines that aspires to remove the human intervention form the process blocks. On ground reality it might require the human intervention to feed in the creative juices or decision power that impacts critical human needs or contexts.
When we map these 2 perspectives horizontally and vertically, we get the the right insight into the DesignSystem’s position in the graph that allows us to clearly understand where the gaps are for the DesignSystem to evolve on which dimensions.
Note that the metrics that govern the success of a DesOps implementation is almost synonymous to this metrics we explored about Design Systems. The factors that adds to this metric on Design Systems, includes aspect where we measure how impactful the Design System is in touching the different design process lifecycle blocks where each role like an Information Architect or an Interaction Designer , Visual Designer or even the Developer are attached to, in the delivery track. This aspect is more figuratively termed as a Living Design System.
The Living Design System
The Salesforce design team tried to solve the challenges of applying similar designs across cross-platform product families by introducing a dynamically configurable design asset system which viewed the individual entities of any design system as design tokens.
Technically it was a single JSON file that was the “Single Source of Truth” that contained a set of name-value pairs that defined the properties and their relationships under different categories like text colours, backgrounds, border sizes, font sizes, etc. This JSON was consumed by the framework (i.e. The Lightning Designing System link: https://www.lightningdesignsystem.com/downloads/) developed and templatized for different target platforms, devices, Operating Systems etc. The Lightning Designing System framework generated different formatted outputs for CSS via common CSS preprocessors like Sass, Less and Stylus. Also there was an output in XML format that is supported in Android and JSON for iOS specific development. The Salesforce Design Tokens open-sourced at https://github.com/salesforce-ux/design-system.
The second interesting aspect of this was the use of GitHub to host the design system. Unlike the design system of traditional organisation, where the design system was hosted as downloadable form (even in the cases where the version control like Git is used) these have to be either translated into desired formats for the target platform or hosted especially along with the code. But here the design tokens representing the styles definition and the properties, as hosted on GitHub, were directly integrated into the build process contributing to the Continuous Integration and Development approach of development. In this sense, it was more as a Living System acting a single source of truth, from which the required branch is pulled and be made as a part of the build.
Many other pattern library and/design systems like RedHat’s PatternFlyhttp://www.patternfly.org is also available in similar approach at GitHub (i.e. at https://github.com/patternfly )as that of this second aspect we discussed now. But the idea of making the style guide being available as a single source of truth in a combination of this second aspect is what makes the case of the Salesforce design system unique among similar attempts for an approach to delivering a consistent design across different platforms.
(c) 2018, Samir Dash. All rights reserved.