DevOps Insights, internal CI/CD and DevOps portal Work in progress
The organization's internal DevOps CI/CD portal aims to become the central hub for AI-powered CI/CD for tens of thousands of developers across the company. Today, adoption is partial: some teams have just onboarded, some use it regularly, and others have abandoned it.
As Lead Product Experience Designer, I'm responsible for the DevOps Insights module, an AI-powered tool that gives teams DORA metrics, a security overview and product lifecycle health data, alongside AI-powered code reviews.
The goal is full adoption across the organization's development teams by the end of next year. This case study is about finding the real reasons behind the current adoption gap, and closing it.
Matomo session recordings and user flows, user interviews and feedback from teams.
Complex flows, unclear onboarding, errors and external blockers.
A new primary persona: the engineering lead and DevOps manager.
UX improvements for DevOps managers and a better journey for users without admin rights.
At the organization, our internal DevOps CI/CD portal is only partially adopted across the company. Some teams have just onboarded, some use it regularly, and others have abandoned it after setup.
As Lead Product Experience Designer on the DevOps Insights module, my responsibility is to research and understand why, and to propose solutions for a significant improvement in UX, adoption and product awareness.
The portal has an ambitious goal: full adoption by the organization's development teams by the end of next year. The main problems standing in the way are:
For them, onboarding simply failed. They followed the steps, got an error and were left lost in a broken process, with no clear way to continue.
Until now the portal was designed mainly for developers and DevOps engineers. But during our user interviews, developers told us clearly that they are not interested in the metrics. They simply want to write code, test and fix bugs.
Now we are researching the pain points of DevOps managers, so we can design the experience around their needs and increase adoption across their teams.
In this project I use Claude Code as my main working tool, not only Figma. I use it for research, for analysis with the Matomo MCP server and for prototyping with the Figma MCP server. This lets me move from a question to data, from data to a design decision, and from a decision to a working prototype much faster.
The real workflow is under NDA. The examples below are illustrative and show the way I work, not the internal setup or data.
Synthesise interview notes and feedback, grouped by persona.
Ask where users get stuck, then verify in session recordings.
Turn findings into a design decision together with PM and Tech Lead.
Use the Figma design context to build a working prototype.
Test with users and check the impact after release.
The quality of the output depends on the context. I keep my project knowledge in Markdown files: research findings, product knowledge, the SAP Fiori design system and the SAP product standards. Claude Code reads them before it analyses, designs or prototypes, so every result is grounded in our users, our business and our design system.
devops-insights-ux/ 1 · Research├── research/ │ ├── user-interview-analysis.md │ ├── heuristic-evaluation.md │ └── competitor-analysis.md 4 · Prototype├── product-knowledge/ │ ├── product-overview.md │ ├── personas.md │ └── glossary.md ├── sap-fiori/ │ ├── components.md │ ├── floorplans.md │ └── choosing-floorplans.md 5 · Validate└── product-standards/ ├── usability.md └── accessibility.md
| Heuristic | Finding | Severity |
|---|---|---|
| Help users recover from errors | Error doesn't explain what to do next | High |
| Visibility of system status | No progress shown across setup steps | Medium |
| Match with the real world | Technical terms without explanation | Medium |
| User need | Floorplan |
|---|---|
| Find and filter many items | List Report |
| See and edit one object in detail | Object Page |
| Work through a queue of tasks | Worklist |
| Complete a guided, multi-step process | Wizard |
Illustrative example of the structure and content. The real files are under NDA.
› Read the interview notes and update research/user-interview-analysis.md with pain points grouped by persona. Reading interview notes… Developers – want to write code, test, fix bugs – not interested in metrics Engineering leads – report delivery and product health – need reliable insights for the team
› Show the user flow for first-time workspace setup. Where do sessions exit? ● matomo · Users flow report ● matomo · Page exits Highest exits are on the step that needs rights in an external tool. Next: review session recordings for this step.
› Read /product-knowledge and /sap-fiori. Use the selected Figma frame and build a working prototype of a troubleshooting screen for users without admin rights. ● figma · get design context ● figma · get variables ✓ Prototype created ✓ Checked against /product-standards Ready to review with the team.
Illustrative prompts and outputs. No real data, file names or numbers from the project.
I believe that AI tools don't replace the designer. They remove the manual work between research, data and prototypes, so I can spend more time on the real questions: who the user is, what blocks them and how to fix it.
Improving the key flows and the DevOps Insights experience based on the pain points of our new primary persona.
We are analysing how to make the portal more accessible for people without admin rights. And when they cannot get these rights, we want to give them a clear and pleasant troubleshooting journey instead of leaving them lost in a broken onboarding process.
This is a work of continuous improvement. Our next steps are to validate the improvements with real users and to make a real impact on team productivity and product health, so the portal can significantly improve the whole product lifecycle and become the central hub teams choose to use.
One of my biggest learnings so far is that adoption problems are not always visible in the interface. The portal requires a Jira project to set up a workspace, but most of the people doing the setup were developers without admin rights for their team's Jira project. They followed the steps, got an error and had no clear way to continue, no matter how good the screens were.
This reinforced that choosing the right primary persona matters. We designed for developers, but in our interviews they told us they are not interested in the metrics. The value of DevOps Insights is for engineering leads and DevOps managers, who report on their teams' delivery and have the rights to set everything up, so they became our new primary persona.
I also believe that errors are part of the user journey too. When users cannot continue, they still need to understand what happened and what they can do next. Our next step is to validate these improvements with real users and measure their effect on adoption across teams.