Model Edge

Background

Much of the MVP had already been designed for beta release, so my goal was to identify usability issues in the beta, understand user needs and pain points, and determine what to prioritize next.

Before joining, I wasn't familiar with financial models or model risk management. Getting up to speed mattered more than it might sound, because the users of this platform do model risk work professionally and I needed to understand what they were accountable for before I could design for them.

Discover & Define

Once I got up to speed, I dug into the existing system to find areas that needed improvement and interviewed beta users to understand their workflows and pain points. What came out of those conversations was that the biggest problems weren't visual. They were about finding information inside a lot of it.

Key Findings

• Users had mixed feelings about the Digital Assets Overview page. Some found the dashboards sufficient, while others were confused and didn't realize there were more charts below the fold.
• Some of the icons were unclear.
• Users wanted more information in their inventory of assets, or the ability to customize tables.
• There were too many steps when adding new content in a modal.
• Asset profiles were hard to navigate and digest because of the amount of content on them.

The instinct here would be to cut content, but that wasn't an option. The fields on an asset profile map to documentation obligations, and hiding something a reviewer is accountable for creates real risk. So I reframed the problem as one of progressive disclosure rather than reduction, which is what most of my "How might we" statements ended up circling:

The sample was small and drawn from the beta user pool, so this was directional input to help choose a direction rather than statistical validation. The expandable table and sticky navigation concepts resonated most clearly, and those are the ones I refined.

Model documentation exists to be reviewed and scrutinized, and that scrutiny is most acute in the approval flow, where each state needs to be legible: what's pending, who it's waiting on, and what's already been signed off. In a governance context, the status of a review is as important as its content.

Both of these write to the Audit Trail, which had its own section. The challenge there is that a complete history is by definition long and mostly routine, but the entries that matter (a material change, a rejected approval, a re-validation) are the ones someone is looking for under time pressure. I explored several concepts for making that record scannable rather than exhaustive to read, and tested them with beta users.

I also designed the exported output, including the printed and PDF versions. This was a different design problem from the screen work. There's no viewport, no scroll, and no interaction, and the document has to hold up on its own once it leaves the platform. That meant thinking about pagination and where content breaks, how tables behave when they cross a page, and what identifying information carries in headers and footers. The exported report is often what actually reaches a regulator or an audit committee.

Accessibility

The design system already adhered to WCAG guidelines, so the foundation was sound. My job was making sure the patterns I built on top of it held that standard, since dense tables, expandable rows, sticky navigation, and modal content entry all introduce accessibility risk at the point of composition rather than the component level.

Practically, that meant every interactive element had a visible keyboard focus state and could be reached in a sensible focus order, icons carried accessible names rather than relying on shape alone, and images had meaningful alt text. The parts that needed the most attention were the ones where information appeared or moved visually, such as expanded row content, sticky section navigation, and modal flows. Those are the cases where something obvious to a sighted mouse user can be silently unavailable to someone using a keyboard or a screen reader.

Prototyping & Handoff

After gathering feedback, I hand-coded prototypes in HTML, CSS, and JavaScript rather than sharing static designs. This allowed me to test behavior that's difficult to convey, like transitions between hover and expand states, scroll behavior of sticky elements, and how content overflow should be handled.

Working this way also changed the handoff. I shared the prototypes on GitHub alongside guidelines and specs, so developers had interactive prototypes to reference rather than a static designs to interpret. I partnered closely with the lead developers and PMs, and the documentation covered the things that would otherwise have to be inferred from the designs, such as empty and default states, how users clear data, and how a collapsible column reacts to scroll events.