Complementing the Advantages of DevOps with Broader Design Thinking

Over the last few weeks, we have looked at what DevOps, design, and an embedded relationship looks like; the benefits of design integrated in DevOps; and design variants to optimize DevOps. A critical component of DevOps is the high-level communication necessary to maximize the advantages of DevOps.

This high-level of communication is usually achieved by breaking down the silos surrounding the development, IT operations, and design teams. However, once the silos have been torn down between DevOps and design teams, miscommunication may still arise. Synchronization doesn’t happen in the blink of an eye. Teams don’t always initially set out project expectations. DevOps teams don’t automatically adjust timelines during the influx of new collaborators.

Following the integration, design and DevOps may not be on the same page. However, once the dust settles from tearing down silos, it is evident DevOps and design teams could work together towards successful and functional products – all while staying consistent with a faster speed to market and a seamless user experience.

Here are some tools, methods, and advice DevOps wished designers knew.

Making design changes earlier rather than too late

Expressing design changes to DevOps teams in early stages is more beneficial than expressing those changes towards later DevOps stages. Earlier requests for design changes result in more time to consider what development changes need to be made to accommodate the new design request. The earlier reporting also increases lead time for designers to work on the design changes they’ve requested. By spending as much time possible, DevOps and design teams can find solutions to ensure consistent user experiences.

Waiting until the last minute increases the possibility for disruptions in user experience. Additionally, spending time fixing dysfunctional user experiences would hinder the advantages of DevOps, such as improving deployment frequency and shortened lead times between fixes. To sum up, saving changes until the last minute of development processes contradict the overarching goals of optimized user experiences and faster speed to market.

Feature creep diminishes advantages of DevOps

If an idea makes it to the DevOps team, it will get built or implemented. Only problem is, you can’t develop an application to accommodate every person in the world. The accumulation of features that don’t take user experience, primary audiences, or necessity into consideration can create an application oversaturated with unnecessary functions and lead to increased lead time between deployments. DevOps have to rely heavily on designers to ensure that feature creep isn’t happening.

Feature creep makes an application’s UX/UI clunky and dysfunctional and can be costly in terms of time, money, resources and user satisfaction. DevOps teams need designers to act as gatekeepers for the user experience to ensure that feature creep doesn’t get out of control.

Not all design ideas are feasible to develop right now

While there are several good design ideas to help solve some applications’ issues, they aren’t always feasible to develop based either on time, budget, or available resources. An updated design feature may require new code, new infrastructure, or maybe even a new approach than the one already used by an application.

In DevOps, it is important to understand the essence of time and how workflows should be distributed in this period. By phasing the implementation of larger effort ideas (or eliminating them altogether), DevOps teams manage time better and can deploy incremental features. As a possible solution, design teams can meet with DevOps teams or work side-by-side to understand the knowledge they possess and what types of design ideas are reasonable to develop with the existing time, budget, and effort constraints.

Thorough design annotation means less misinterpretations

Above all, developers use annotations to help decrease the chances of overlooking a UI interaction or UX problem. To help DevOps teams, designers should annotate designs as thoroughly as possible to clarify intent. Clear, in-depth annotations on a design request remove room for interpretation. When there is room for interpretation, DevOps has to fall back to their own interpretation, or resort to asking peers, PMs, or the design team what the intention was behind design decisions.

Thorough annotations from the beginning save time and can limit the back and forth clarification required when annotation is not provided.

Prototypes rather than static wireframes when possible

If there is time for prototyping, DevOps wouldn’t mind having them. Prototypes during DevOps decreases the possibility of misinterpretation when developing fixes and features to an application. Consequently, usability and functionality increase too. While the DevOps team can often work from lo-fidelity tools like wireframes, those tools are only effective when a style guide is also available. And even with a style guide, most DevOps teams would be hard pressed to be able to apply design best practices from what a style guide typically provides.

Building prototypes helps DevOps teams see the types of UI interactions needed. Our teams use Figma to provide working models of an application, perfect for providing specs for DevOps teams, and useful in visualizing an entire application or feature for our clients.

Overall, there are more parallels between advantages of DevOps and design-thinking

In conclusion, DevOps is as intricate as it is useful. Bringing down silos isn’t enough to effectively employ DevOps processes and maximize the advantages of DevOps. In addition, DevOps and design teams need to work on communication to ensure optimized updates and fixes. Teams can only accomplish the goals of DevOps with the proper collaboration and understanding of each other’s processes and goals.

Next week’s DevignOps article: things designers wished DevOps teams thought more about.