In the first blog of our “DevignOps” series, we summarized design and the DevOps process and gave a brief overview of the embedded relationship they share.
In the second blog of our “DevignOps” series, we outlined a couple of the benefits of integrating design throughout different DevOps stages.
The benefits of DevOps are very much enhanced by design not only at different stages of DevOps, but also through different design types and practices. Three design variants are continuous design, UX design, and architectural design.
These design options offer distinct advantages to DevOps teams, including a lower failure rate of deployments, consistent user experience, and reliable system foundation. We continue our “DevignOps” series with an outline of these different design variants and how they can be embedded in DevOps.
Minimum Viable Design with Continuous Design
In line with DevOps’ continuous deployment, delivery, and testing approaches, DevOps teams should also implement a continuous design approach. DevOps is all about continuous processes to shorten lead time between updates and fixes and lower the failure rate of new releases. Why wouldn’t you apply the same approach to design?
Traditionally, dev teams consult design before or during the commencement of the software development life cycle (SDLC). Limiting design to only one stage of the DevOps process can increase the risk of rework due to insufficient consideration of the user experience, information architecture, or database design. By implementing a continuous design approach, design teams would weigh in on the design of a system as it’s updated, minimizing the risk of rework.
A good starting point for a design team would be to prototype a minimum viable product (MVP), or minimum viable design (MVD) in this case, before the DevOps team begins their work. Throughout production of a system’s update or fix, the design team can revisit the MVD prototype as updates are deployed and feedback is given. An MVD prototype gives design teams the opportunity to continuously modify the initial design as needed, or keeps the DevOps team on track as appropriate.
In short, implementing continuous design in DevOps ensures the concerns of users and the business goals of stakeholders are being considered in updates or fixes to an application, software, or system.
Avoiding UX Debt throughout the DevOps Process
As mentioned previously in our “DevignOps” series, DevOps engineers are engaged to continuously deploy functional updates. As a result, they may not be able to foresee the unintentional cost a feature may have on a system’s information architecture, sort of a forest for the trees scenario. Including UX design teams who are focused on UX details helps avoid these types of unintended consequences.
The unintended consequences on the system’s information architecture and overall user experience results in what is known as UX debt. This accumulating debt caused by the exclusion of UX designers in DevOps results in costly, time-consuming rework efforts as the user experience degrades over time. In addition, UX debt is detrimental to the overall DevOps process. For instance, the debt can increase the failure rate of deployments and extend delivery frequencies.
The time-consuming, costly rework efforts to information structures can be avoided by regularly including UX designers throughout DevOps. Your design team should be engaged at the beginning of any process to think through the application as a whole, but should also be engaged in the development of new features or changes to the structure of an application. Their role is to keep the bigger picture in mind, in this case the overall user experience, while ensuring that possible complications to the user experience are addressed and not compounded as more and more updates are made.
Collaborative environments between UX designers and DevOps engineers ensure a consistent UX result when developing system updates or fixes. By simultaneously working on an app’s fixes and updating the app’s user experience, DevOps and design teams can avoid UX debt and address UX concerns in real time.
Usability Testing Between DevOps Processes
The purpose of DevOps is to reduce the time between developing a fix to a system and having the update placed into normal production. However, in doing so, some DevOps teams focus on the code and infrastructure updates and neglect important UI design modification considerations. This inadvertent negligence can cause several disruptions to the updated application or software’s user interface.
Subsequently, a dysfunctional user interface causes dev teams to undergo lengthy revisits and costly rework of the updates they have made to software or applications. Rather than increasing speed-to-market of the system’s updates, DevOps teams must spend additional time and effort reviewing the different ways to maintain a seamless user interface.
DevOps teams can prevent disruptions to the user interface or experience by including design teams in its testing approach. This inclusion can be accomplished by including a “design QA” process between the development and testing stages. A “design QA” process allows design teams to review the planned change before it’s deployed, giving them a chance to see their concept in action. While not exactly an opportunity to revisit the overall idea (it should have been thought out long before you reach the testing phase), it does give the design team a chance to ensure the concept is being developed to spec, nothing was misinterpreted, and the concept works in reality. This process is similar in nature to usability testing, though in this case it’s carried out internally. By incorporating a “design QA” in its regular testing approach, DevOps teams are more likely to consider the usability of an update, before and after development, lowering the failure rate of deployments.
How can this be incorporated seamlessly? Engage the same team that designed the UI in your design QA or get your stakeholder team on a regular schedule of usability testing. Don’t be afraid of engaging the stakeholder team – they should already have seen the initial design and signed off on it; having them get in and use the application with its new features or changes should give them a greater sense of confidence in the updates. And if the design doesn’t work from the user standpoint, it’s better to know that now than when the change is deployed to the end user.
Dev teams can ensure they aren’t overlooking usability specifications during development by implementing usability testing or design QA. An effort to simultaneously test usability during the development of a system’s new feature ensures minimal disruptions to the UI and the application overall.
Application Style Guides Supplement DevOps Design Thinking
The design variants mentioned previously are great tools and practices to use in coordination with DevOps efforts, decreasing the amount of UX debt and minimizing UI disruptions. With the exception of back end or infrastructure only changes, updates delivered to end users usually involve some sort of UX/UI change. The DevOps process from concept to delivery can be significantly accelerated by developing an application style guide.
Application style guides outline the specifications of an application, such as button features, typography, interface layouts, toolbars and menus. Style guides are meant to supplement the design thinking of DevOps teams rather than replace the process of consulting design teams for insight and recommendations.
For example, maybe a DevOps team has a time-sensitive application update to make and there is no time to have an in-house designer create hi-fidelity mockups. With a style guide available, DevOps teams can instead rely on lo-fidelity designs like wireframes, which are much simpler for a designer to pull together. This process ensures that a designer is still considering significant elements of the application – should it be a toggle or checkbox? Should it be a new page, live on an existing page, or be a modal? – but eliminates the need for a designer to define specific details. Those details, which can get as granular as the amount of rounding on a button corner, have already been defined in the style guide, and need only be properly executed by the DevOps team. This course of action decreases the time required for DevOps teams to implement a new feature. It also helps maintain consistency across an application or system before and after the delivery of new updates.
Style guides are valuable supplements to any DevOps team. However, don’t substitute style guides for design teams; rather, let the guides take the thinking out of the design details and focus on the bigger UX picture with your designers.
Complex Design Variations in DevOps Process = More Uptime
In conclusion, there’s no excuse to exclude design throughout your DevOps stages. With various design types and practices, design teams have plenty to offer during the development of application or software updates. Overall, there are several methods to ensure an update or fix built during DevOps doesn’t negatively affect a system’s user experience or user interface.
Whether it’s by implementing a continuous design approach or including UX/UI design at specific steps in the DevOps process, the outlined design variants should be embedded in your team’s thinking. These design variations help DevOps teams avoid costly rework, wasted time, and unmet business goals.
Stay tuned for the next article in the series: what developers wish designers knew about DevOps.
Dan is the CEO at Palador. He has been helping companies solve complex technological problems for over 12 years.