Rethinking roles
The nature of this work is confidential, no images or key information will be disclosed.
The context
I started working in a Platform Engineering company, where the focus is to facilitate developer experience, eliminate team silos and accelerate time-to-market speed by providing modules around Governance, Deployment, Operations and FinOps.
The whole context of the company and the product was all new to me, whilst I had some knowledge of the developer world and had used Github in the past, the problematics needed to solve and the details of the framework were hard to understand at first.
Please understand that the nature of this work is confidential, therefore no images or key information will be shared.
Understanding DevOps
After my first 3.5 months, it was time for my first solo project, shadowed by one of my UX colleagues.
I love challenges, and that's why I was very excited to join the company, even if I came from a totally different world.
During those first months, I had to understand the framework and the details of my users, understand CI/CD, pipelines, automation and more. That's when, besides interviewing my colleagues, searching online and investigating the product, I decided to use my personal time to really get into the DevOps mindset and turn to literature. I read the Phoenix Project and really enjoyed it, it gave me a great perspective on the topic and hooked me along the way.
The problem
The problem was first described as the creation of a Self Service Portal, but the framework already provided that functionality, so what was really the problem here?
Clients have required the possibility of "simpler" users, who could use the product with fewer liberties, even prohibiting access to pipelines they deployed. Others wanted to restrict access to more tabs users saw when a project was created.
Could the problem be solved by giving some users fewer liberties through the assignation of a particular role?
The current interface
The product had a Role creation section already. It provided two default roles already (Admin and Read-Only) and gave users the chance to customize their own.
But there was a problem, a big one.
Checking our data we realized that the "Roles" section was hardly used, you could argue that you would enter, create a role once, assign it to a user and never go back. True. But the reality was that the interface was far too complex for our users to comprehend and therefore, they didn't use it.
The proposal
We need to create "simpler" users, restrict access to specific tabs and incentivize the use of roles.
Would it make sense to create an even simpler interface for just some users?
I disagreed. Our proposal was to redesign the role experience and interface, to simplify it.
The big challenge was to find the correct balance between simplicity (like Github roles for example, that are created by default and have access to specific parts/features and have certain permissions) and granularity (to allow users to fully customize the role to a tee).
Understanding pipelines
From the information gathered, a simple solution seemed to restrict access to the CI/CD pipelines and a great part of the job was done (since some clients found them too complex).
We knew our Ops and devs used them a lot, so how could that be a usecase? To fully grasp the use, we did interviews with Ops, Front End and Back End to see how they used them. We also interviewed a member of the Marketing team, to understand the interaction of "non-technical" users with them (they would trigger the pipeline for the website every morning).
Could we make pipelines easier?
The process
Not going to lie here, the process was long, very long. A lot of back and forth between simplicity and granularity every week.
Redesigning the roles meant having exhaustive knowledge of every single corner of the product and the use cases, such a bug challenge had to be able to really solve a lot of problems.
I worked along with the Ops, Solutions Architect and Back End to understand all the challenges. What do clients say? What do they need? What problems do they identify in their everyday work? Do we know of specific roles we need? Could we automate that?
Ideating part 1
It was time to go from research to ideas.
_We knew we needed to revamp the roles.
_We knew some specific roles were required: what we called the "simple user" that would only be able to create projects (deploy infrastructure or apps) and the "FinOps user" that would only be able to use the Financial feature of the framework.
_We knew we needed to extract information from the pipelines and showcase it somehow for users that would not have access to them because of complexity and/or security.
_We knew that the interface needed to reflect the sections of the framework for a simple understanding of it.
But this was not all, even these "preassigned" roles needed to have greys:
_"What about only viewing the financial feature but nothing else?"
_"Could simple users only see the projects they own? Not all of the Team/Organization?"
_"Could they be restricted to specific stacks to deploy very controlled infrastructure?"
Ideating part 2
How could we distribute the information?
We wanted to introduce a glimpse of gamification to the experience by adding predefined templates users could start from.
Since we needed to give the possibility of a simpler or more complex role creation depending on user preferences and needs, we decided to divide the experience into three:
_Part One: give a name and description and choose the default user/template
_Part Two: modify restrictions as wanted.
_Part Three: add Advanced Settings to further polish the role.
From the information we had gathered, Part One was the simplest to define.
Part Two, on the other hand, had a lot of complexity to it: we distributed the features by sections replicating the way the UI in the Framework is, but should we show all? Is it overwhelming? Is it really needed? Can some of these sections be moved to the Advanced settings (Part Three) and not be missed?
Part Three was very complex to tackle as well.
The Wireframes
Wireframes were a LOT. The constant battle between simplicity and granularity was at the center of the stage.
We tried a lot of combinations until we came to one that was not as complex, moving parts to the Advanced Settings section for a cleaner look. Great!
How can we standardize options for each section?
No Access-Read-Use-Manage these options were consulted a lot with users during testing and meetings since they had to work for every single section of the product.
How would we warn users about dependencies? Here we go again...
This topic was in the room until the end, automatic vs. manual? Warnings vs. blocked buttons to prevent from moving forward? You name it.
We ended up going for a warning within the section to inform users and help them make the correct decision.
The prototype
We came to a wireframe we considered solid. We had a meeting with our technical team to go through it with them and make sure we left no usecase behind. And great news, everyone was happy!
The time for testing is here!
Creating the prototype was not super easy, the wireframe had a lot of casuistics and we didn't have time to waste investing in some fancy prototyping tool, so Figma had to do it. Luckily, recent advances on Figma (we love you) made it a really smooth low-fidelity prototype thanks to the use of interactive components.
The testing
We did testing with Ops, Front End, Back End, and Solutions Architect from our company who weren't involved in the process at all. We were also able to arrange two tests with actual clients which were awesome!
We did the testing with at least two Designers + the tested user. This way, we could fully get all the information we needed with notes and the recording. We gave them four scenarios, ranking from simplest to hardest to help them with the learning curve.
The testing went great! We were able to try some subtle differences (A/B testing) on some users to see what worked better, and the general feedback was very positive. As a general note, all users understood the new order of the experience and how to create from simple to more complex roles.
Learnings and changes
My first solo project was a rollercoaster, had its ups and downs and I loved it. The autonomous way of working we have at the company gave me all the liberties to contact, meet and discuss with whoever I needed which was a great ride. At the same time, in times of frustration and needed help I could always count on a more experienced team mate to collaborate with me.
After the testing, the review of the notes and results it was time for this project to be handed over to the UI expert. Some changes were implemented (position if the "Give name and description part", some tabs that changed due to modifications of the overall product and some namings. It was great to see how it ended up and it will soon be part of the framework! Be sure to check Cycloid's public docs to see how the new roles work! (Coming soon!).