ThirdPartyTrust served two completely different user types in one shared UI, and neither felt like it fit. I was part of the research that drove the decision to split it into two dedicated products, Bitsight VRM and TMH, then redesigned the navigation and feedback patterns around each one.
A platform built without a design team
ThirdPartyTrust was a third-party risk management (TPRM) platform. Before Bitsight acquired it in Q3 2021, it had been built entirely by engineers — solid technically, but without a user-centered design process from the start.
When I joined, there was no UX team, no research infrastructure, and no clear picture of who was actually using the product. Two completely different user types — customers (companies managing vendor risk) and vendors (companies being assessed) — were navigating the same interface, with the same navigation, even though their goals had almost nothing in common.
The signal was already there: a high volume of support tickets, no subscription support for many users, no way to distinguish what was a usability problem from what was a feature gap. My job was to build the process to read the signal — and then act on it.
Once the product split into two teams, I landed on VRM, the customer-facing side. I kept working closely with the TMH team throughout, since I carried the product context forward from the original ThirdPartyTrust platform, back when both experiences still lived in one codebase and one team.
Two users. One navigation. Zero clarity.
The platform's core problem wasn't any single broken feature. It was structural: customers and vendors were forced to share the same mental model of the product, even though they were there for completely different reasons.
The top bar and left sidebar served both user types at once. Customers looking for their vendor list and vendors looking for their pending assessments landed in the same place — with no clear path forward.
Users couldn't tell if an action had succeeded. No confirmation after sending a questionnaire. No status on submitted responses. Empty screens with no guidance on what to do next.
Users without a subscription had no support channel. Their frustration generated support tickets — but without research, there was no way to distinguish a usability problem from a missing feature.
Understanding two different worlds
The research goal was exploratory: understand how each user type thought about their work, what they needed from the platform, and where the experience was breaking down. I used three methods, each chosen for a specific purpose.
To understand motivations, mental models, and day-to-day workflows. We talked to subscribed and unsubscribed users on both sides — customers and vendors. The goal was to hear how they described their own work before asking how the product fit into it.
To synthesize observations across participants and surface shared themes. I ran sessions with the VRM and TMH teams together — so the findings weren't just mine. They became a shared understanding across the two product teams.
To validate the new IA after the product split decision was made. Testing whether users could navigate the new structure before committing to building it.
The research team
This wasn't something I did alone. I worked with 2 product designers, 2 product managers, and 5 customer success teammates to plan and run the interviews — customer success in particular gave us direct access to users on both sides of the platform, since they were already talking to them every day. Subscribed users were the primary signal; unsubscribed users, who had no support channel to complain through, showed us where the experience was silently failing.
Affinity diagram and Journey map — User research findings
Two personas emerged
Out of the interviews and the affinity diagramming sessions, two personas emerged, one per side of the platform. They became the shared reference point for design decisions on both the VRM and TMH teams — proof that customers and vendors needed genuinely different products, not just different views of the same one.
Sarah Chen and Tiago Ferreira — the customer-side and vendor-side personas that came out of this research.
What the affinity diagram surfaced
After clustering observations across all participants, five themes emerged consistently. Each one became a design principle for the new IA.
- Time. Customers needed to jump between the Requirements tab, Data, and External Questionnaires just to review what a single vendor had submitted. Workflows had to be linear and fast, with no dead ends or unnecessary steps.
- Customization. Neither user type felt the platform was built for their context. Customers needed control over how their assessments were set up, like custom questionnaires; vendors needed control over their profile. Customization had to be a first-class concept, not a buried settings page.
- Collaboration. Both sides described their work as inherently cross-functional. Customers coordinated with internal security teams; vendors coordinated across legal, engineering, and finance. Contacts, roles, and delegation needed to be core objects in the navigation, not utility features.
- Automation. Manual repetitive work was the biggest source of frustration on both sides: chasing vendors, tracking progress in spreadsheets, re-sending the same documents. Automation touchpoints needed to be integrated into primary flows, not optional add-ons.
- Navigation. Users couldn't orient themselves: a customer looking for their vendor list and a vendor looking for their active assessments ended up in the same place. Navigation was the symptom, not the cause, since the platform had no conceptual model matching how either user thought about their work. The IA needed to be rebuilt around user mental models instead.
A product that finally talks back
The "No system feedback" problem identified early on (section 02) had a simple root cause: there was no shared vocabulary for how the product talked back to users. Before any of the structural redesign work began, the very first patch shipped on ThirdPartyTrust was smaller: setting up Pendo guides for user onboarding. Those guides carried over when the platform moved to Bitsight and are still in use today.
No confirmation after sending a questionnaire. No status on submitted responses. Empty screens with no guidance on what to do next. Users landed on the platform and didn't know what to do without reaching out for technical support.
Every screen accounts for the same four states: empty, loading, success, and error. Actions confirm themselves. Empty states point to the next step instead of leaving a blank screen.
Feedback patterns, standardized
Bitsight DS already had a complete feedback pattern library — the gap wasn't a missing pattern, it was inconsistent use. I made a point of running every new design against it, covering the four states every screen needs to account for, so none of the four got skipped.
Empty states guide users on what to do before there's any data, instead of showing a blank screen. Loading and progress states confirm an action is in motion, so a click never feels like it went nowhere. Success confirmations give a clear signal when something completes, like sending a questionnaire. Inline errors surface next to the field or action that caused them, not in a disconnected banner.
The four-state checklist, kept close at hand on every project since.
Objects first, not features
The research revealed something deeper than a usability problem. Customers and vendors weren't just different personas — they were operating with fundamentally different conceptual objects. Merging them in the same navigation was the root cause of the confusion.
Core objects — Customers and Vendors
These two object sets didn't overlap at all. Sharing a navigation between them was the root cause — not a symptom. The IA decision followed directly: split the products. VRM for customers. TMH for vendors.
Before & after
ThirdPartyTrust used a dual navigation — a top bar for primary sections and a context-sensitive left sidebar. The redesign moved to a single left sidebar per product, each organized around its own object model.
Top navigation bar + context-sensitive left sidebar. Both user types shared the same primary nav. The sidebar changed depending on which section you were in, but both customers and vendors saw the same top-level structure.
Two separate products. Each with a single left sidebar organized around its own core objects. Customers navigate Vendors, Assessments, and Findings. Vendors navigate Profile, Requests, and Certificates.
New information architecture — Before and After
Inside the customer-facing product, that same "objects, not features" thinking went one level deeper. In the old UI, opening a vendor meant launching a full-screen dialog with its own internal tab bar (Tiering, Requirements, Data, and several more), a completely separate navigation paradigm bolted onto a global top bar and an unlabeled icon-only sidebar. There was no URL-level "you are here," no way to tell from the nav that you were even inside a vendor. The redesign folded Vendor Profile into a single, unified left sidebar as a real nested section. Overview, Tiering, Requirements, and the rest each became genuine nav destinations with persistent context and an active-state indicator, instead of tabs trapped inside a modal.
Vendor Profile moves from a full-screen dialog disconnected from the main nav to a nested section inside one unified sidebar. Every former tab becomes a real, addressable destination.
Two things brought support ticket volume down: splitting the UI into two products meant customers and vendors were each looking at a navigation built around their own objects instead of someone else's, and the feedback patterns from the previous section meant that once they were there, the system actually told them what was happening instead of leaving them to guess.
The same object pattern, reused twice
Once Vendor was modeled as an object with defined sub-pages, two of those sub-pages, Security Profile and Requirements, got redesigned around the same underlying idea: stop treating each artifact type as its own UI pattern, and start treating every artifact as an instance of the same object, a requirement with a status. These two are only a sample: the same redesign process touched 10+ flows across the integration. Security Profile and Requirements are shown here because they illustrate the pattern most clearly.
The two pages answer different questions, and they render differently on purpose. Security Profile shows everything a vendor has shared, published once to their Trust Management Hub profile and often more than what's strictly required, so it's a card grid built for browsing an open-ended set. Requirements shows the specific checklist of artifacts a customer's program actually requires from that vendor, so it's rows grouped inside an accordion, built for checking a defined list. Both are the customer's view into the vendor relationship: a reviewer looking first at everything a vendor shared, then at their own requirement checklist mapped against it.
Security Profile — what a vendor has shared
On ThirdPartyTrust, a vendor's shared documentation didn't even live in one place for the reviewer. It was split across two separate sections, Assurance Program and Questionnaires, each with its own navigation and its own UI pattern: large cards with logo thumbnails for Questionnaires and Certifications, plain tables for Insurance and Audits/Assessments. Metadata was buried under visual noise, and nothing looked consistent from one section to the next, let alone between the two sections. The redesign merged both into a single Security Program section and collapsed all four object types into one card grid: one card per item, a type label, a status chip, and inline metadata, all using the same chip style whether it's flagging severity or marking an item as "Required," since vendors often share more than what's asked for. The information got easier to scan for two reasons at once: it stopped pretending to be four different things, and it stopped being split across two pages.
Security Profile — four inconsistent card/table patterns become one unified card grid, one card per shared artifact, using the same chip style to flag severity or mark an item as required.
Security Profile — the redesign in action
Requirements — reviewer's view
The Requirements page took that same row pattern and reused it a level up, but the bigger problem here wasn't visual inconsistency: the tab couldn't do anything. Requirements lived inside a giant modal packed with tabs (Tiering, Data, External Questionnaires, and others), and the Requirements tab itself was read-only. It could only tell a reviewer what was required, not let them act on it. To actually review a questionnaire response or a piece of documentation, the reviewer had to leave the tab entirely, jump over to Data or External Questionnaires, do the review there, and come back, repeating that trip for every artifact in every requirement.
The redesign made Requirements fully actionable. Documentation opens inline in a side sheet, without leaving the page. Questionnaires open in their own dedicated page instead, since their size doesn't work in a sheet, but reviewers get there directly from the requirement rather than hunting through Data or External Questionnaires first. Either way, review starts from the requirement itself, not from a separate tab. The accordion, the summary, and the per-artifact status all sit on top of that one change.
Requirements — from a read-only tab that sent reviewers back and forth to Data and External Questionnaires, to a fully actionable view with direct questionnaire access and inline document sheets.
Requirements — the redesign in action
The through-line across all three: define the object once, a requirement with a status, and reuse it everywhere it shows up, in a single artifact row, in an accordion of requirements, and in the nav hierarchy that gets you there.
From questionnaire review to AI-powered SOC2 analysis
During this project, I participated in an internal hackathon exploring generative AI within the Bitsight product. The idea: instead of manually reviewing SOC2 Type II reports, a process that could take hours, hand that work to an agent that reads, extracts, and analyzes the report on its own, then summarizes it into actionable insights. Designing it meant deciding how the agent shows its work: what it found, where in the report, and how confident it was, so reviewers could trust the output without redoing the analysis themselves. The prototype was compelling enough to become a real product, Instant Insights, in the Vendor Risk Management application. Manual review time went from hours to minutes.
What I'd do differently
Loop customer success in earlier. Customer success teammates were part of the research team, but mainly to help recruit and run sessions. They had direct, daily contact with these users. If I'd brought them in to help shape the research questions from the start, not just to execute them, we probably would have surfaced some of these insights faster.
Use the affinity diagram as a kickoff, not a synthesis. The cross-team affinity session was one of the most valuable moments of the project. VRM and TMH stakeholders building the diagram together, instead of receiving a report, meant they owned the insights. I'd use this format at the start of the research phase, not just at the end.
IA decisions precede UI changes. The rename from "Connections" to "Vendors," and the move from dual navigation to a single sidebar, these were IA decisions first, UI decisions second. I'd be more explicit about documenting that sequence, so the team understands what's driving what.