Matrix42

Matrix42 served several types of users, including support agents, administrators, managers, and employees using internal services. Their tasks, permissions, and levels of expertise differed significantly.

The product also needed to work across different platforms, support integrations with existing customer systems, and accommodate frequent updates. Different components were being developed by separate teams, so local design decisions had gradually accumulated into an inconsistent overall experience.

The task extended beyond refreshing the interface. We needed a shared structure that could support future functionality and bring coherence to the existing product.

One of the central constraints was the lack of direct access to end users. This limited our ability to observe real workflows and validate proposed changes with the people who would use them.

To build an evidence base, I held regular feedback sessions with customer support and interviewed support teams about recurring problems across different user groups. We also reviewed customer requests related to integrations, platforms, and devices.

Support teams could show us repeated patterns in customer questions, common workarounds, and areas where users needed additional help. Customer requests also helped us understand which technical environments and integrations required attention.

This evidence guided prioritization while retaining a lower level of confidence than direct user research. I cannot claim direct end-user validation for the resulting design.

The first major task was to rethink the information architecture and reduce fragmentation across the product.

We looked at the different user roles, the relationships between product modules, and the patterns that appeared repeatedly across workflows. Some inconsistencies were clear design debt. Other patterns had become familiar to experienced users and supported the way they worked every day.

That distinction shaped the modernization strategy. The product needed a clearer structure, but replacing every established pattern would create unnecessary friction.

We preserved recognisable workflows where they still had value and redesigned the areas that limited usability or future development.

A complex product developed by several teams could not be modernized through isolated screen improvements. The teams needed a common foundation for making interface decisions.

I developed UI standards and best practices, helped generalize interaction patterns across the product, and created the design system.

This work gave designers and engineering teams a shared reference for recurring components, behaviours, and visual decisions. It also reduced the need to solve the same interface problems independently inside each product area.

The standards and design system contributed to a broader unified UX platform. Its purpose was to help teams build visually consistent business applications and apply the same UX principles across Matrix42 product lines.

In an enterprise product, familiar patterns can carry real operational value. Customers may have built internal training, support documentation, and everyday procedures around the existing system.

This made change management part of the UX work. We needed to understand which patterns helped users work efficiently and which ones remained only because of the product’s history.

The design direction preserved useful familiarity while updating the product structure and visual language. Information from customer support was also used to communicate upcoming changes and help customers understand their effect on existing workflows.

The aim was a transition users could recognise and learn, rather than a visual reset detached from the way the product was already used.

Before committing to a new UI platform, I built a prototype that covered the core business needs and UX principles of the proposed system.

The prototype turned an abstract platform direction into concrete screens and interaction flows. It allowed the team to examine how the new information architecture, shared patterns, and visual language worked together.

This process exposed weak points in the concept and gave us an opportunity to adjust the direction before investing in full platform development.

Today, I would treat the lack of user access as a programme-level product risk rather than a local research constraint.

I would work earlier to establish direct contact through selected customers, beta participants, customer advisory groups, or structured usability sessions. When direct access remained impossible, I would document the source and confidence level behind each important assumption.

This would make the limits of the evidence visible and reduce the risk of support feedback gradually being treated as a complete representation of user behaviour.

This project shaped how I think about legacy products.

Familiarity has real operational value, even when an interface looks outdated. The hardest part of enterprise design is separating what is genuinely broken from what is merely old.

That perspective continues to guide how I approach complex products today.