Integrating UX with DevOps

Source:- devopsonline.co.uk

Integrating UX with DevOps is essential for DevOps teams to ensure they solve the right problems and are understanding the user’s real needs.

DevOps is a rapidly evolving organisational model with teams arranged around a product or service to deliver value to their users more quickly. Through breaking down organisational silos, the delivery teams work on a product or product improvements instead of projects which are usually no longer maintained or supported after they’re completed. For many organisations, it is a significant culture shift when transitioning to product or service orientated teams and adopting DevOps practices helps to make the transition easier.

Nowadays, DevOps is much more than just getting development and operations teams to work together. This is a culture where trust, collaboration, communication and a failing fast mindset are a part of the day-to-day work of the delivery teams as well as the whole organisation. It’s also a model where our users are at the heart of everything we do. We identify the user needs by exploring the problem area, then improve our service based on the user feedback and continually learn about our users throughout the whole service lifecycle.

Therefore, the DevOps culture can also be described as a culture of continuous improvement where the teams continually learn about their users, innovate and evolve through creating new ideas and taking daily efforts to make things better, faster and more efficient.

The Build – Measure – Learn feedback loop is a very common practice through which the teams build a solution, measure the results based on data and learn based on the user feedback. This cycle can be repeated and applied to new ideas, experiments or product developments. Therefore, the ultimate goal is to deliver value to our customer, our customer’s customer and keep up with their changing needs through adopting DevOps practices.

The DevOps teams bridge the gap between Development and Operations as they work in small cross-functional teams to bring together all of the skills and capabilities needed to deliver DevOps solutions. They share tools and practices which include agile planning, agile software development (iterative and incremental development), continuous integration, continuous deployment, automated and continuous testing, and proactive monitoring of the production environment.

In order to identify what value you’re trying to deliver and what is your user’s biggest pain, many DevOps teams embed a UX professional (UX, product or service designer) into their cross-functional team. This is to ensure we solve the right problem and we understand the real user needs.

What is UX?

User experience (UX) is a scientific, psychological, and problem-solving side of product, experience, and service design. It focuses on having a deep understanding of users, what they need, what motivations and habits they have as well as limitations. It also takes into account the business strategy and business objectives with the purpose of delivering an end-to-end solution.

It is very important to understand your end user to make sure you deliver the service they need and that they’re going to use. UX helps you truly understand what your users need so that you know their needs early on, and you can decide to pivot or abandon the idea.

UX with DevOps!

When UX is integrated into the DevOps team, requirements are researched and designed, the solution is user-tested before the engineering team builds it. If the user or business stakeholder changes their mind, UX is a part of the process so the team can quickly adapt and change the direction of the service by implementing the user feedback.

On the contrary, when UX is not integrated into DevOps, the team receives the requirements from the client or the wider business and builds the solution straight away. Then, it gets to production and it’s delivered to the client who often says: ‘That’s not what I wanted!’

After the team receives the feedback, the new solution needs to be built and the whole cycle repeats until they get it right. As a result, a lot of time and money might be wasted as the delivery teams build the wrong thing or the user requirements change too many times – ultimately reducing speed to market.

If your DevOps team supports the internal development teams, their users are not only external customers but also development teams from other parts of the business who will use their DevOps solutions. The DevOps team’s goal is not to throw their work over the fence but to understand the developer’s needs and treat them as customers.

In this case, UX should be similarly integrated into the DevOps team. For example, I’ve been working with a DevOps team who have built different DevOps solutions, but the users preferred to use their own continuous integration / continuous deployment (CI/CD) pipelines and monitoring tools. As a result, none of the solutions have been used by the development teams. This means the user needs weren’t identified, and the problem area explored enough, to understand what solutions would have solved the user’s biggest problem and pain points.

‘What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?’ Identifying your users and value is one of the main ‘lean’ principles Eric Ries talks about in his book Lean Start-up.

A common challenge for many large organisations is that their development teams may struggle with different parts of the development process and have different needs depending on their maturity, therefore different opportunities may arise.

Design Sprint Concept

Apart from traditional user research techniques (one-to-one user research interviews, workshops and observations), the DevOps teams can use a ‘design sprint’ concept as a powerful UX technique to identify developer needs for the CI/CD pipeline.

On my most recent enterprise project, the centralised DevOps team and I created user personas and decided to implement the design sprint approach because the level of cloud experience within the development teams varied significantly. This is to understand the user needs and business value, find commonalities, create a prototype and validate a few CI/CD pipeline design concepts with the users to get feedback. All work has happened during four intensive days of work with the purpose of reducing the risk of spending six months and delivering the wrong thing.

The results have been impressive and the benefits outstanding to the whole organisation. The Proof of Concept (PoC) has been proven to reduce a significant amount of time – from a project initiation phase, to deploy, to production – but more importantly, it’s greatly improved the user and stakeholder engagement.

Engagement & Needs

Engagement is particularly important if you want to stay up-to-date with the user needs. The user needs change all the time so if you want them to remain fresh and timely, engage with your users regularly, do ongoing user research and user testing throughout the whole service lifecycle (Discovery – Alpha – Beta – Live), and not just during discovery when the project is initiated.

When organisations embrace the DevOps culture, engagement is also crucial for organisational change as face-to-face communication increases across all teams and departments and organisational silos are starting to break down.

Another principle that allows you to stay closer to your users is a ‘lean’ principle – go see for yourself. If you wonder what your users may like or what they struggle with, go and talk to them directly. You’ll see the benefits of engaging and interacting directly with your users very quickly. Even though the users can’t see if your team applies agile or lean principles or how many sprints you need to build the service they need, they will definitely see the user experience.

While most organisations agree that DevOps focuses on driving business value, they’re challenged to move beyond the typical IT-focused metrics. Even though there are very good team IT metrics (cycle time, mean time to recovery, deployment frequency, fewer support tickets, reduced time to deploy a ‘change’ to production), it’s important to remember what business change our IT initiative is going to drive and how are we going to measure its success.

User-focused metrics such as user satisfaction surveys or a number of adopted DevOps solutions should give you a good understanding of whether your internal users (development teams) are delighted with your service within your organisation.

Similarly, reducing cost and time spent by each development team building their own tech stack or components through identifying repeatable patterns and building common solutions will bring the most value to your organisational metrics. Instead, the teams can spend more time on delivering value to their end users or customers.

Lastly, if you’re working on an end-to-end DevOps transformation programme and using a DevOps framework assessing your organisation’s or team’s DevOps maturity, try to apply a variety of DevOps metrics within technology, people and process capability to adequately measure the DevOps transformation success.