Creating a consistent UX framework for a mature SaaS product

A ten-year-old placement management system that experienced users had learned to work around and new users could not learn at all. The product could not be rebuilt in one go, and customers could change its terminology, colours and labels, so no fixed screen design would have survived contact with it.

Instead of an ideal interface, I delivered rules: a severity-ranked UX review, redesigned priority screens, an interactive prototype and a product-specific style guide that developers could apply page by page. The product director described it as the team's bible.

Understanding a product that had grown over time
I began with detailed walkthroughs with the product owner and developers to understand how the system worked, why particular decisions had been made and which constraints could not be removed.
I combined this with user interviews, shadowing and a heuristic review of the existing interface.

The research showed an important difference between experienced and new users. Experienced users generally found PEMS helpful and were comfortable with familiar, spreadsheet-like screens. However, new users found the product complex and unintuitive. They had to learn and remember workflows rather than being guided by the interface.

Several recurring problems contributed to this:

• similar pages used different navigation and interaction patterns;
• primary actions were difficult to identify;
• useful features were present but not discoverable;
• features added for individual customers increased complexity for everyone.

Designing within the existing architecture

PEMS was built using a combination of ASP.NET WebForms and newer MVC pages. The two parts looked and behaved differently, even though both relied heavily on Telerik components such as data grids.

The older WebForms pages would eventually need to move to MVC, but the entire product could not be rebuilt at once. The design therefore had to support an incremental transition and remain compatible with existing components.

The product was also highly configurable. Customers could change terminology, colours and labels, and one major implementation was localised into Swedish. This made it difficult to rely on fixed wording or customer-specific screenshots when defining reusable patterns.

These constraints changed the nature of the work. Rather than designing an ideal interface in isolation, I needed to create rules that could be applied gradually by different developers across old and new parts of the product.

Turning the review into practical decisions

I evaluated the interface using usability heuristics and principles covering hierarchy, consistency, grouping and accessibility. Problems were classified by severity so the team could distinguish important structural issues from cosmetic improvements.

The review covered recurring elements including colours and feedback states, buttons, grids, filters, forms, modals, navigation and keyboard focus.

This gave the team a shared way to evaluate new requests. Instead of treating every page or customer request as a separate exception, they could refer to an agreed set of interaction patterns.

Considered and rejected

Replacing the interface outright. The obvious reading of the problem was that the product looked old. Rebuilding it in one pass was not available to us, and it would have removed workflows experienced users relied on to do their jobs quickly.

Removing the spreadsheet-like grid. It was the source of much of the complexity, but also the reason experienced users were fast. The flexibility stayed; what changed was how much of it appears at once.

Simplifying the Student List

The Student List was one of the priority workflows I explored in more detail.

The existing screen mixed three different activities within the same set of tabs: finding a specific student, finding a group of students, and choosing an action to perform on selected students.

I reorganised the screen around these tasks. The revised concept separated individual and group search, reduced the initial table to the most relevant columns and placed actions in the context of the selected students.

The aim was not to remove the flexibility of the existing grid. It was to reveal that flexibility progressively, so users could begin with a manageable screen and access additional controls when needed.

Outcome

The final work included a UX review, redesigned priority screens, an interactive prototype and a product-specific style guide.

The guide used examples from PEMS itself. It showed how common page types, forms, tables, tabs, panels, buttons and navigation should be structured, giving developers something concrete to apply as pages were updated or moved to MVC.

The work gave the product and development teams a shared reference for improving PEMS incrementally. As the product director later explained:

"It's become a kind of bible and helped us be much more disciplined when implementing new UI."

How I would measure it

I do not have post-delivery figures for this work. If I were measuring whether the guide earned its place, I would look at three things:

• How long a new user takes to complete a first placement task without asking a colleague, which was the original problem;
• How often new customer requests are met with an existing pattern rather than a one-off exception;
• How closely pages migrated to MVC follow the guide once several different developers have worked from it.

Closing principle

Redesigning a mature operational product is not about replacing what is familiar. It is about understanding why existing behaviours survived, removing the inconsistency that has no reason, and leaving the team a way to make better decisions without me.