Risk & Compliance
Intapp Risk manages conflicts, compliance, and confidentiality for law firms — high-stakes software on an aging platform. The brief was a facelift and a design-system integration, under a timeline that did not move.
The brief
Intapp Risk identifies conflicts of interest, enforces regulatory compliance, and protects client confidentiality for law firms and professional-services organisations. The users are compliance professionals whose mistakes have legal consequences.
The ask was blunt: give this legacy product a major facelift and integrate the design system into it. The challenge was equally blunt — a strict timeline, and technology old enough that it might not support what we drew.
I joined with another associate at the halfway point. The Senior Designer and PM had already defined the initiative, drafted the timeline, and assigned verticals; generative research and a sitemap of Risk had been completed before we arrived. Mine was the Overview Request Form and Files.
That is a real constraint worth naming. Coming in at the midpoint means inheriting decisions you did not make and finding the room that remains inside them.
Breaking the surface down by component
The approach was to take my assigned area apart by component type, then integrate the design system — including in combinations it had not been used in before. I rebuilt the forms from components in the Intapp Design System, working against the sandbox as reference.

The change I would defend
Rebuilding the forms surfaced a problem the design system did not have an answer for. These request forms frequently need more than one person to complete them, and nothing in the interface told you where the thing stood — whether anyone had looked at it, who, or what was left.
Taking inspiration from form-tracking tools like Asana, I introduced a state showing whether forms had been viewed and by whom, and hyperlinked the “complete” subtext so a user could jump straight to that part of the form rather than hunting for it.

We produced competing layouts and continued iterating in preparation for A/B testing, and the mocks had to carry the unglamorous completeness that enterprise work demands: every component state, error messaging across all components, and file filtering.
Files, and the grid system
On the Files page I used our grid component system — building on previous grid work I had done — to give users a place to see the documents uploaded against a request. That ran through several iterations and tickets: row actions, attach file, and related grid behaviours.

Final designs were copied into the master file for the Senior Designer’s approval, and brought together for critique and the client demo.
What I would tell you in an interview
There is no outcome metric here and I will not manufacture one. I was an associate UX designer on a ten-week initiative I joined halfway through, and I do not know what the A/B test returned or whether the collaborative form state survived to production.
What this project taught me is the thing I now do first on any design-system work: build the existing screens out of the system before designing anything new. Every genuine gap I found — including the collaborative state, which was the most valuable change I made — came out of that translation, not out of the brief. The brief said facelift. The rebuild said the form did not know it had more than one author.