Sylvie Lachine, UX and Serviceability Lead, Ericsson, discusses what it’s like to transition from being a B2C UX designer, to heading up a new DevOps team in the world of B2B.

Previously, I have explained the challenges of B2B when it comes to managing the user experience, as there are many different user groups, doing many obscure things with products.

I used to be a normal B2C educated UX designer, relying on usability testing, web analytics, surveys, journey maps, diaries and a few other techniques to understand my users, but when I made the transition from B2C to B2B, I had to ask myself ‘Could I apply all of my current knowledge to my new B2B reality?’

The challenges of B2B

The first challenge I decided to take on was to understand the deployment of our solution. Think software installation – like having a dialog box with a progress bar, only it can take weeks or months, involve a lot of people and hundreds of tasks.

To me it was a chance to get exposed to all of the moving parts of the system, way beyond the GUI, so I jumped at the opportunity. I figured deploying the solution was certainly something very procedural, something that I could follow from A to Z, where I would easily identify pain points.

I landed for two weeks on a high stress project with five engineers working 12 hours a day, fluidly accomplishing hundreds of tasks that would adjust and change based solely on the outcome of the previous tasks. They had to improvise in order to get around hurdles, while using many different systems and doing a lot of very obscure things. I could forget about creating a neat journey map and identifying the moment of truth!

One of the engineers was very keen on helping me though, so he began to write a daily journal with his observations. I managed to interview the others and understand their reality a lot better.

Documentation became one of the key pain points, as the engineers had to skate around the errors or omissions. The GUI also wasn’t great, but it was a very small piece of the puzzle. The bulk of the time spent was elsewhere. I left the deployment with a few actionable things to fix, but also with the feeling that I was just scratching the surface and unsure how to go deeper without drowning. Usability testing on a multi-user process that takes weeks if not months? Forget it… Doing journey mapping? Too many moving parts… Surveys, interviews? Sure, but I was still only staying at the surface.

I left the deployment with a few actionable things to fix, but also with the feeling that I was just scratching the surface and unsure how to go deeper without drowning. Usability testing on a multi-user process that takes weeks if not months? Forget it… Doing journey mapping? Too many moving parts… Surveys, interviews? Sure, but I was still only staying at the surface.

Tackling serviceability issues with DevOps

One of the engineers on the deployment was a member of an expert group whose mission was to help local teams with deployments all around the world. I realised that this expert group was actually conducting their own validation after each of our releases, and coming up with a list of things that they thought we should improve, but they were struggling with the fixes. The collaboration between Dev and Ops just wasn’t happening, we had two groups at odds with each other who were not understanding each other’s realities. alking to one of the leads in the Ops expert group, we came to understand that we were after the same goal, and that maybe, if we went about it together, we would succeed

After talking to one of the leads in the Ops expert group, we came to understand that we were after the same goal, and that maybe, if we went about it together, we would succeed at achieving it, and with the blessing of our top management, we started something brand new that we invented together and that we called the Serviceability Steering Group.

I led this steering group, which united everyone who was a doer or an influencer in the Ops and Dev groups. We had agreed that we would carve a swim lane in our program to tackle serviceability issues, and contrary to the usual model, where requirements come from the top and were executed by the R&D organisation, the needs would come from the ground. Dev and Ops would share their realities and come up with improvement ideas. We would all collectively decide on priorities and what to do next.

We had a guiding star: Industrialise deployment. So everything that would make deployment faster, more reliable, and simpler, was a candidate for execution. We would meet every two weeks and report on our accomplishments, express what was bothering/blocking us and plan what we would do in the next two weeks, with a little color gauge that could go from red to green. We started at red because the frustration was high. But quickly the gauge turned orange and then yellow and after a few months, it showed a bright green color.

Dev and Ops coming together

A couple of things happened: The first one is that we favoured all the tactics which would bring Dev and Ops closer together so that we had a tight and early feedback loop going. The goal was not for me to hijack and funnel the user feedback, it was to infuse it in the whole organisation. We relied on an internal gamified Q&A forum to let everyone in Dev and Ops freely exchange and talk to each other, which had never happened before. Dev took the habit to show our proposals for new features early, so that our Ops group would be able to influence the development. I would be able to conduct usability testing for the GUI intensive features every time I needed it and other team members working on other parts of the system would rely on the same availability of our Ops users. We would at every release have the Dev teams demo to all the users how to use the new features, allowing people to ask questions, which was a lot more efficient than shipping written documents, and hoping for the best. We would also get together on documentation reviews, Dev and Ops reading hundreds of pages and discussing them together. We would all contribute to writing missing parts, pulling our combined weight to improve documents page per page. We worked as a close-knit team with core values: Trust, transparency, and people over process.

The DevOps movement

In the DevOps movement, we wanted first and foremost to nail down the culture aspect by creating one group with shared interests. From this, stemmed a lot of innovations, especially when it came to tools and the procedures for deploying the system. For the first time in my UX career, I didn’t have users, people who you interact with briefly, controlling the interaction through UX methods. Instead, I had partners, and my role as the UX was to ensure that Dev and Ops could work together smoothly, while rallied around the same goal. It was to foster trust, communication and collaboration in order to improve the user experience of the system. We were calling our Steering group our little hippie commune. It is probably the best image that will stay in my mind.

We sometimes say that UX is the responsibility of everyone in a project. In a complex B2B system, there is no other way. Our responsibility as UX experts is to empower the whole organisation to deliver on user experience, and not to focus on our little GUI thinking that it is the centre of the world. There is no better way to deliver on the full user experience than bringing Dev and Ops as close together as possible, as it is only through a constant and relentless feedback loop that we can achieve a goal of building a delightful system, from deployment, to operations, to support and upgrade. And when we succeed, then we can go back to playing with colours.

This article was originally published on LinkedIn, and edited for web by Jordan Platt.