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 DevOps teams bridge the gap between Development and Operations
The DevOps teams bridge the gap between Development and Operations as they work in small cross-functional teams to bring together all 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 into their cross-functional team. This is to ensure we solve the right problem and we understand the real user needs.
User experience (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 considers the business objectives and organisational strategy in order to deliver an end-to-end solution.
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!’
The new solution needs to be built again and the whole cycle repeats until they get it right. This very often means a lot of time and money is wasted as the delivery teams build the wrong thing – 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.
Ultimately, the users won’t be able to see if your team applies agile and lean principles or how many sprints you need to build the service they need, but they will definitely see the user experience and they may ask questions such as:
- what made you choose the systems you chose?
- who tested the service with people like me before it was released to public?
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 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 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.
Most of organisations also agree that DevOps focuses on driving business value, however they’re challenged to move beyond the typical IT-focused metrics. Although there are very good IT metrics, 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 solutions (or tools) 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 organisation. Instead, the teams can spend more time on delivering the real value.
This article was originally published on DevOps online.