Fostering UX on a DevOps culture

Having worked my entire life on the technical side, it was only recently that a colleague I’ve come to respect a lot brought my attention to the importance of UX.

This was a breaking point for me, as I came to understand that the DevOps mindset should not only be focused on the unification of two distinct groups that do their own thing, but rather on how to improve the experience people has while delivering their software to better align with business expectations.

Evolution of Infrastructure solutions.

Over the last decade the way of working of Infrastructure teams has evolved from the old days of racking servers up and making sure you copied all the necessary configurations manually, to the present day where tools have enabled us to programmatically create and tear down entire platforms with a single command.

A lot of improvements have been made into the quality of life of engineers around the globe.

There was one common denominator across the different paths brought up by this journey and that is the fact that these solutions were heavily oriented towards what we like to call the power users. Those that have a deep understanding of the intricacies of how the systems work underneath the complexity, who have vast knowledge of all different moving parts and the ins and outs of the solutions they are building. They are the experts in the field.

For the last few years, there have been some interesting new trends on the infrastructure tooling world, strongly empowered by the DevOps culture and Development teams directly.

10 years ago you needed to create your servers, copy or manually create your configurations and hope for the best. If you were not pressed for time, you might have been lucky enough to be able to automate all of your setup using custom bash scripts and boy were you lucky!

Nowadays you can have most of your infrastructure defined as code. You build it once and reuse it, you have your configurations stored on a configuration management system, or directly baked into your systems. Things have come a long way and it’s a good place where we are right now.

What issues do we face on Infrastructure when thinking of solutions?

However, infrastructure teams are slowly morphing, shifting into something that we used to fight before. As someone leading a team, lately the question has shifted from “what’s the best way we can do this for us” to give way to “how we can make this easier for everyone so that they don’t rely on us”.

Crucially, with managed services like AWS/Azure/Google Cloud, my infrastructure teams are moving into the mindset of how we can empower the organization. Creating simple enough integrations for everyone to easily consume this new set of tools so that they do not need to have full knowledge of this before they can actually make good use of it.

The trick here is not as much the how we do this, but rather how we start thinking about solutions that do not require exceptional levels of understanding. That’s when I started getting more into how User Experience actually contributes to this.

I’ve started by taking steps on 4 different fronts:

User Research

Research is paramount to creating a new service, we need to understand how and why we are doing what we are doing. This is the first step on every development process, and it’s no exception when dealing with Infrastructure.

However, the interesting part of this stage when working with my team was not so much what we wanted to do, but rather making the shift on our mindset to who we wanted to do it for.

Infrastructure has normally been run in silos, we were the kings of the production castle and no one but us had the keys to the kingdom. This of course has been changing with these new ways of working. Infra was used to creating tooling that was used just by them, with their requirements, their use cases and their own set of constrains regarding how complex they could get as they already had the underlying knowledge.

When defining what we are creating, we need to think about who we are actually building for.

It’s not the same if we are building an infrastructure management service where we can define our networking to the last bit than if we are building it for developers, who might not really care about how the backbone of the systems work and just want their apps to be able to run quickly and smoothly.

Some useful guiding questions are:

• Who are we building for? Who is the end user of our tool?
• What are they trying to achieve? What goal does the user have?
• What is the level of knowledge you are building for? What’s the overall knowledge of our user base?
• How can we improve adoption rather than imposing a working tool?
• Are we building with our users in mind or based on how we would like it to work for us?

User Behaviors

Understanding should be our first stepping stone when trying to solve a problem for someone else that not many understand. Having a deeper understanding of who the user of our tool is and how they interact with it is fundamental. We are no longer building things for us; those who will be using these tools are not the power users that have all the knowledge but rather people who need to get things done with as little complexity as possible on their interactions.

For this, one of the most important strategies for me was User Interviews. Even though these can be really structured and scripted to get exactly the qualitative information you might want out of the user, in my particular case they were really useful to have these even if they were on a more relaxed setting. In either case, you need to have a clear plan of action of what you expect to get out of your user and what questions have the qualitative value to get meaningful output of the exercise.

As my users would be internal customers within my organization, having something that didn’t feel scripted but rather raw allowed them to better express their emotions and feelings regarding the challenges they had with our systems.

Usability

This is the big challenge ahead of us. Usability should be critical on our design.

If we are not building something that simplifies our users experience with our systems, no matter how beautiful it is, we are not building a good service.

Whatever we build should be simple enough in solving our users problem, clear enough that they need as little input from us as possible and efficient enough so that we do not put a burden on their processes.

At this stage we need to have a strong focus on how users are conducting their daily activities. Our solutions should have a strong correlation with their interactions and usage patterns. This enables them to seamlessly interact without having to change the mindset they are used to.

A clear example of this for us was our CI/CD pipelines efforts. Those were aimed to speed up developer productivity. Creating an external tool for them to interact in a way they are not accustomed to would have created adoption friction, which is why it was key that what we built was integrated into their development process. Everything could be managed directly from within their application repositories, a usage flow they know like the back of their hand.

Iteration

Once we have as much information gathered from our users as we deem appropriate, and we have designed our solution, we can actually start working on it.

Iteration is the key component of a good design process.

Personally I think that creating a massive solution in one go is a terrible idea, some might not agree with this, but shipping in small increments enables us to test and validate what we are building.

As long as we are providing value on each iteration to our users, we can then correct and adapt based on their feedback. This is something of vital importance as we are now delivering something useful and the more we hear what our users have to say, the more we can learn and change on the next release.

It is at this stage of our development process where we can validate that we are solving the right problem with the right design. Building a complex solution over a large period of time, only to find out that we’ve gotten our core understanding of the problem or expectation of our users wrong is a massive waste of effort and time. This is where shipping MVPs (minimum viable product) fast and often is critical.

Closing thoughts

As I’ve mentioned here, this is a process, one that those on the Infra / SysAdmin side might not be accustomed to, but nonetheless is important in this day of ever changing ways of working.

Good intentions and excellence in code does not ensure us that even the smartest people in the company will actually use our tool if we don’t take the user flow and experience seriously.

For anyone interested in building solutions, large or small, I encourage them to get involved on the User Experience field. Even small steps there would prove useful to better understand the users needs and how to actually deliver something that you won’t just be proud of because of the technical challenges involved, but for the sake of making someone’s life a little bit easier. That feeling is something worth striving for.