UX and Product Design

Designed for trust,not just speed.

Qlarc is a B2B SaaS platform that turns the AI governance a vendor already has into regulation-mapped evidence a financial-services buyer is legally required to evaluate.

Role

Lead UX / Product Designer

Goal

Turn a vendor’s existing governance into a buyer-ready evidence pack before the deal stalls.

Validated with industry operatorsFinancial-services AI governance

app.qlarc.ai / evidence-mapping

Readiness as one number the buyer trusts

Evidence items mapped across 10 procurement questions in the prototype

Shipped in prototype

<2h

Target time from workflow start to full evidence pack export

Design target

>90%

Target source attribution rate. Every claim linked to API or document evidence

Design target

Automated send paths. Every export requires named human sign-off before it leaves

Shipped in prototype

01Overview

What is Qlarc

Qlarc is a vendor-side AI governance procurement platform for mid-sized AI companies selling into regulated financial services. Buyers operating under SR 11-7, the EU AI Act and ECOA require structured, regulation-mapped evidence before they approve any AI system. Vendors have the governance. The buyer cannot verify it. Qlarc is the infrastructure that closes that gap.

Primary user

A GRC or compliance lead. Not an engineer.

A compliance professional under deadline pressure, assembling evidence across systems they do not control. Every decision was made for this person: guided workflows over complex forms, evidence first, non-technical by default, and vendor control before anything leaves the platform.

02The problem

A revenue problem in a documentation costume.

Most deals don’t die with a no.
They die with silence.

The buyer’s governance team goes quiet, the purchase order freezes, and a deal disappears. It was never a documentation problem. It was a revenue problem, which set one tiebreaker for every decision: protect the deal, not the feeling of completeness.

$500K to $2M

Deal value frozen at a single governance review

15 to 20 days

To assemble one evidence pack by hand, each deal

Zero

Reasons the buyer gives before walking away

What research revealed

Discovery ran on interviews with compliance, GRC and procurement leads, alongside validation sessions with three domain experts in model risk and AI governance. The same three patterns surfaced in every conversation.

The block is silent and final.

Reviewers do not negotiate missing evidence. They stop the purchase order, and the vendor rarely learns why.

A half-built pack does more harm than none.

A partial submission signals that a vendor doesn’t understand its own governance. That reads worse than asking for more time.

Three gaps, and they only close together.

Visibility, documentation and translation into the buyer’s language all have to be solved in one motion.

✎ From the notebook

the thing that stuck with me wasn’t the rejections. it was the silence. no feedback, no second chance, the deal just stops moving and nobody says why. and if the vendor never hears the reason, they can’t fix it → they lose the next one the same way. kept coming back to this. the problem isn’t really the missing docs, it’s the silence around them.

03 Opportunities

How might we move the judgment earlier?

01Missing

How might we let a vendor see what a buyer will reject, before the buyer ever does?

Resolves in Decision 01Readiness before documentation

Barclays vendor review

Q3Escalation path and human overrideMissing
Why it failsBuyer requires a named escalation owner with a documented hand-off. None on file.
Q7AI output monitoringMissing
Why it failsNo monitoring cadence or alerting evidence provided.

The Product03 / 04 · The four-step workflow

Connect → Upload → Gap-Fill → Review & Export.

A vendor with critical gaps is routed to a Governance Readiness Report before pack generation begins. Below, the full system, screen by screen.

Information Architecture System map

Two doors, one gate, one pipeline.

Every vendor enters through one of two doors, new or returning. Only the first-time path creates a fresh assessment, and it runs through the readiness gate before anything else. The architecture makes that gate impossible to skip, so every evidence pipeline starts from a qualified baseline.

View the full system architecture diagram FIG 2.0 · expand ⌄

FIG 2.0 · SYSTEM INFORMATION ARCHITECTURE

A · ENTRY & QUALIFICATION

DOOR 01 · FIRST-TIME VENDOR

SCREEN

→ DECISION 01

QUALIFICATION GATE

3 Onboarding Questions

needs ≥ 1 of 3 to qualify

QUALIFIES
≥ 1 OF 3 = YES

Connect API &
Upload Documents

NONE
QUALIFY

HOLD · OFF-RAMP

Show what's missing

Save & return when ready →

DOOR 02 · RETURNING VENDOR

SCREEN

Already has an account with a connected API & documents → skips the gate entirely and lands straight on the dashboard.

DIRECT

QUALIFIED FIRST-TIME + RETURNING → CONVERGE

HUB

Dashboard

Previous Reports In Progress Create New →

B · EVIDENCE PIPELINE

01

Upload New
Questionnaire

OPTIONAL

Upload File

if new doc needed

02 · CORE

Evidence
Mapping

03

Gap Filling

04

Report
Generated

05 · TERMINAL

Export

NOTE

The gate is the only mandatory branch in the system. Returning vendors skip it because they cleared it once; new vendors cannot reach Evidence Mapping without passing it. Everything downstream of the dashboard is a single linear pipeline. The architecture concentrates all of the judgment at the entrance.

Key Design Decisions

04 / 04

The three decisions that earned the system its trust.

Each one carries the rejected approach next to what shipped, and what I tried first.

Decision · Gate

OWNED · Gate logic & routing

Readiness before documentation

Route the vendor to the truth before they can submit a half-built pack.

Three questions

Qualify the vendor before any pack is generated.

Hard routing

Evidence workflow, or a Governance Readiness Report.

"It protects them from the record."

What changed

Rejected

✗Generate the evidence pack first

✗Show a completeness score at the end

✗Let the vendor decide whether to submit

A partial pack becomes a compliance record of unpreparedness.

Designed

+Readiness assessment runs first

+Three questions route the vendor

+Unready → Governance Readiness Report

The gate adds a step before vendors see the product. That step is the product.

Tried first

The gate first required all three readiness checks to pass, a strict yes/yes/yes. Research showed mid-size vendors don't always have all three in place, so it turned away too many who were otherwise close. I relaxed it to a single qualifying yes, which still routes the unready toward the Readiness Report without shutting capable vendors out entirely.

✎ From the notebook

i was so sure about this one. three checks, all green, or you're not ready. felt like integrity at the time. then a vendor said it flat out in an interview: "nobody has all of this on a good day." sat with that for about a week before i dropped the gate to a single yes. felt like losing when i did it. it wasn't. i'd built a wall where i needed a door.

Decision · Core

OWNED · Per-claim tagging model

Source-tagged evidence mapping

Put the proof right next to the claim, at the level where the reviewer is actually reading.

EU AI Act · Art.14 SR 11-7 · §V ISO 42001 · 8.3

Source tag

API-verified · doc-extracted · vendor-provided, on every row.

Regulation citation

Article-level, drawn from a verified library. Never LLM-generated.

Source attribution

Name, date and document, all verifiable at the point of review.

"A claim without a source is an assertion. The tag makes it evidence."

What changed

Rejected

✗Polished claim summaries

✗Citations filed in a separate appendix

✗Section-level confidence band

✗LLM writes the claim text

Reviewers couldn't tell which specific claim was weak within a section.

Designed

+Source tag on every claim

+Article-level citation, inline

+Per-claim, always visible to the reviewer

+LLM extracts only, never generates

Every mapped item traces to a specific named source, verifiable at the point of review.

Tried first

I started with a section-level confidence band. But the reviewer could not tell which exact claim was not strong enough, or where each piece of evidence came from. So I moved the strength and the source onto each individual claim.

In detail, what a buyer reviewer reads

One governance question in full: the regulation citation, the evidence found with its API-verified source, the corroborating document, and the regulation it satisfies

Completeness dashboard, what the vendor sees before any export

                  Evidence typeItemsStrength
                

APIAPI-verified metadata 6 1.0

DOCDocument-extracted evidence 2 1.0

GAPVendor-provided gap-fill answers 2 0.75

MISSINGUnfilled, shown explicitly, never papered over 2 Flagged

Readiness score 78%

The vendor sees exactly what a buyer reviewer will see before any export begins.

Reasoning

SR 11-7 requires independent verifiability, not attestation. A reviewer must check each claim at the point of reading, not by navigating to an appendix. The LLM is used for extraction only; every mapped item traces to a specific source, not generated text. Per-claim tagging makes the screen denser than a polished summary would. That density is what makes it verifiable.

Decision · Sign-off

OWNED · Approval & attestation

Human review and accountability

No automated send path. Named approval, per section, is the gate.

Per-section approval

Named sign-off required on every section before export.

Hashed trail

Name, timestamp and version, cryptographically hashed.

"The vendor owns what they attest to. The system cannot."

What changed

Rejected

✗AI generates the full pack

✗Packages and auto-sends to the buyer

✗No human step required

An unaccountable AI output, the exact thing the buyer is screening for.

Designed

+Named approval per section

+No automated send path exists

+Hashed name · timestamp · version

+Each answer can be edited by the human reviewer

Named approval slows the export down. That slowdown is the accountability the regulation asks for.

Tried first

A single confirmation modal at the end, one approval checkbox before export. Validators flagged that a single sign-off for a multi-section legal document doesn't meet SR 11-7's attestation standard. Named per-section approval replaced it.

What the buyer receives

The Procurement
Response Pack.

Regulation-mapped, source-attributed, and built to mirror the buyer's questionnaire format exactly. It ships with a One-Page AI Governance Summary too, for the reviewer who only has thirty seconds to spare.

Regulation-mapped Source-attributed Named sign-off

Qlarc View and Export, the generated AI Governance Procurement Response evidence pack

Outcomes Targets · pre-launch

A pack the buyer can trust, and the vendor can stand behind.

PROJECTED TARGETS · design goals set for pilot, not yet measured in production

>85%

Intake workflow completion, vendors completing all four stages, setup to export

>90%

Evidence source attribution, every claim linked to verified or extracted evidence

60 to 80%

Reduction in prep time vs. cross-team documentation assembly today

60 to 70%

Pilots expected to report improved deal advancement after using the platform

Targets the design was built to achieve, validated with three governance and risk practitioners.

The part I'm still unsure aboutAn honest note

My whole argument is that friction builds trust. I still believe it. But I added three checkpoints to a product whose users are already exhausted and behind. And I designed every one of them for the reviewer at the end.

The person I’m least sure I served is the tired one at the start. The GRC lead opening Qlarc at 6pm, already two weeks late. If I had another month I wouldn’t add a feature. I’d sit behind five of those leads while they hit the gate cold, and count how many quietly close the tab. That count is the thing I’d want to know before I trusted any of this.

✎ Margin note · to self

if i could rerun one study: 5 vendors, no warmup, just drop them at the gate cold. count how many quit before they ever see the payoff.

kind of scared of that number tbh. which is probably why it’s the one to chase.

Next case study