In low-maturity organizations, even good research gets shelved. Not because the findings are wrong, but because designers have no tool to show which ones are worth the engineering investment. This is how I built one.
Before explaining what DITRIX is, it's worth explaining when it matters. UX maturity describes how embedded user-centred thinking is inside an organization's development process. In Germany's industrial sectors, most companies are at an early stage. UX exists, but sits at the edges.
DITRIX is not designed for high-maturity organizations. It's designed for the middle of that journey, where UX has earned a seat at the table but hasn't yet earned the budget and bandwidth to run a full HCD cycle on every decision.
Bilfinger Digital Next was squarely in the middle column. Research happened. Recommendations were written. But at sprint planning, the designer's priority list and the engineering team's effort estimates were two separate documents, and they rarely met.
The insight came from video analysis on PIDGraph. I was reviewing session recordings and started counting, not just whether an interaction caused errors, but how often it occurred. A bad button is not equally important in all contexts.
Certain core interactions were performed over 200 times per hour. Every second of friction multiplied across the entire working day. That's not a usability issue anymore, it's a productivity cost with a calculable value.
Example from PIDGraph: "Save and download buttons look identical" — medium severity on its own. But 100% of engineers hit this every session, and 67% manually verify the file afterwards every time. Suddenly this isn't a medium finding. It's a daily productivity drain.
The insight came from video analysis on PIDGraph. I was reviewing session recordings and started counting, not just whether an interaction caused errors, but how often it occurred. A bad button is not equally important in all contexts.
I ran DITRIX in combination with a standard HCD process on the same PIDGraph data, comparing them on efficiency, agile alignment, and coverage of user needs. The results were clear, and so were the limitations.
DITRIX isn't a replacement for HCD — it's a different tool for a different organizational moment. As maturity grows, the full HCD cycle becomes both feasible and necessary. But in the early stages, DITRIX gives you a path to visible wins that earns the space for deeper work later.
I don't apply DITRIX as a named, structured process anymore. What changed is how I think about prioritization — and those changes show up in every project, whether or not anyone calls it DITRIX.
Working across Bilfinger, Diconium, and CARIAD, I kept encountering the same conditions: limited trust in UX process, engineering teams with legitimate concerns about scope, and pressure to show results within sprint cycles. The questions DITRIX taught me to ask turned out to be just as useful in a multi-brand automotive context as they were in industrial SaaS.