Ended a recurring support problem in a core workflow
Clients kept losing context when moving between processes and frameworks. I redesigned the navigation without rebuilding the underlying table, and the issue stopped recurring in client feedback.
Overview
- Role
- Senior Product Designer
- Team
- 1 PM · 4 engineers
- Year
- 2025
Problem
With 30 to 40 processes and up to three frameworks each, opening and closing the table's accordion felt jerky and made it easy to lose your place. The issue kept returning in client support queries.
Direction
I replaced the accordion with dependent Process and Framework dropdowns after confirming the existing data model could support the change without rebuilding the table.
Outcome
The issue stopped recurring in client feedback, including from two clients who had repeatedly raised support queries.
01 · PROBLEM + CONTEXT
Nobody expected the old navigation to be the problem
Internal controls teams at large enterprises use the Risk and Control Matrix (RCM) to review risks and controls across business processes. In payroll, for example, a risk could be paying someone twice, with manager approval as a control to prevent it.
The screen we inherited
The RCM table was built by engineers before the team had a designer. It used an accordion to organise risks and controls under each process.
When I first worked on it, the brief was to bring it into the current design language without changing the interaction. So the accordion stayed.
Where the accordion broke down
Opening the Payroll process revealed a long list of risks and controls. Because controls could apply to more than one regulatory framework, the same risk could appear under ICOFR, SOX or IFRS, making the list harder to follow.
Checking another process meant closing Payroll, finding the next process and working through another long list. The jerky interaction made it easy to lose your place.
The problem surfaced through support
The pattern became clear through support. Two clients repeatedly raised the same issue: the navigation felt clunky, people lost track of where they were, and checking controls across multiple risks and processes was harder than it should have been.
02 · DECISION
The better interaction was cheaper than expected
The PM owned the requirements; I owned the interaction layer. Two constraints shaped the work: clients already knew the screen, so changing it carried risk, and engineering was busy, so significant rework would be hard to justify.
Two starting directions
The PM suggested the lower-risk option: keep the accordion and add a Business Process filter above the table. In the product, “Business Process” was the label for framework groups. This let users filter the table without changing the existing interaction.
I wanted to remove the accordion because support issues kept pointing back to it. I first considered combining Process and Framework in one dropdown, but with 30–40 processes and potentially several frameworks for each, it would create a long list mixing two levels of information. I dropped the idea.
Checking the real engineering cost
Before exploring another approach, I sat with the developers to understand what removing the accordion would actually involve.
The accordion already filtered the table by Process, and the backend knew which frameworks belonged to each Process. We didn't need to rebuild the table or backend. We only needed the Framework dropdown to show options for the selected Process. The change was smaller than expected.
Building both versions settled the direction
With the engineering effort clearer, removing the accordion became a practical option. The PM's accordion-and-filter proposal was still valid, so we built both versions to compare them.
My version used two dependent dropdowns instead of the accordion. Users selected a Process first, then the Framework dropdown showed only the frameworks mapped to it. This kept the two levels separate.
Both versions worked, but comparing them made the choice clearer. The dependent-dropdown approach offered a simpler, more direct way to navigate without the accordion. It also worked with the existing table and backend, so we decided to move forward with it.
03 · INTERACTION MODEL
The dropdowns adapt to what’s available
The Framework dropdown shows only the frameworks linked to the selected Process. If there's just one, it shows that value as confirmed. If there are several, users can choose. Changing the Process also resets the Framework dropdown, so a selection from the previous Process is never carried over.
Since the product is white-labelled, I used its existing active and muted styles to make this difference clear across client themes.
Nothing selected
Before users select a Process, the Framework dropdown stays muted and shows “Select process first.” This makes it clear what they need to do next.
Single framework
When a Process has only one framework, the dropdown shows that framework but stays muted because there are no other options to choose from. The help text confirms which framework applies.
Multiple frameworks
When a Process has several frameworks, the dropdown becomes active and starts with “All” selected. The table shows controls from all linked frameworks. Selecting a specific framework filters the table to that framework.
Full interaction
The three states work together as one flow: choose a Process, then use the available Framework options.
04 · OUTCOME
The support problem stopped coming back
During a walkthrough, a stakeholder from a major sovereign wealth fund pointed out that navigation was clearer than with the old accordion.
That fund was one of the two clients who had repeatedly raised navigation issues with support. After the redesign, neither client reported those issues again.