Back to selected work

Responsible AI · Industry-sponsored capstone

RADARs

Designing trust into an AI transparency product

How can Responsible AI become useful to an early team before it has dedicated governance resources?

A hosted, human-editable decision-support prototype designed to help early-stage AI teams examine current practices, understand priority areas, and prepare a transparency report.

Role
AI Product Manager
Timeline
September 2024–March 2025
Team
Four graduate students
Context
UW GIX capstone · Sponsored by RIL
RADARs prototype composition showing tailored Responsible AI report sections and an editable AI practice disclosure report.
Hosted interactive prototype. Users could complete the flow and edit or download a report; scoring and generated guidance were not production-validated.

The 45-second version

Problem, ownership, response, and outcome

Problem
Broad Responsible AI guidance competed with survival, sales, and immediate product work for early-stage teams.
What I owned
Product vision, research strategy, synthesis, framing, requirements, prioritization, product flow, intended AI architecture, and coordination.
Product response
Tailored questions, explanations, visible input-to-output mapping, editable reports, and actionable next steps.
What changed
Research redirected the team to transparency, and seven formative tests exposed exactly where trust broke in the experience.
Boundary
Hosted interactive prototype; scoring and generated guidance were not production-validated.
Core evidenceAfter 400+ cold-outreach attempts yielded too little founder participation, I helped recover the research plan and led the synthesis that moved the product from broad Responsible AI guidance to a transparency-first experience.

The user and stakes

“Be responsible” is not an actionable product requirement.

Responsible Innovation Labs asked our team to research and develop a tool for AI startup founders and investors to examine risk, strengthen trustworthiness, expand responsible adoption, and help shape regulatory conversations.

Early-stage teams face expectations around privacy, safety, fairness, transparency, and accountability, but much of the guidance assumes legal, policy, and governance resources they do not have. Founders needed a practical entry point: what matters to this product, why now, what to do next, and how to communicate current practice honestly.

The research recovery

We stopped asking founders to care more.

Our original research plan depended heavily on interviews with early-stage AI founders. After 400+ cold-outreach attempts yielded too little participation, I led the research-strategy recovery and we broadened discovery through investor, technical, design, healthcare, policy, founder, and Responsible AI perspectives.

The synthesis revealed a product constraint, not a values problem: founders could care about Responsible AI while survival, sales, and immediate product work still came first. I led the synthesis and pivot narrative that helped the team choose transparency as an actionable entry point.

That decision shifted the product from broad guidance toward guided decision support: tailored questions, explanations of why they mattered, visible input-to-output relationships, a human-editable report, and prioritized next steps.

Transparency became the connective layer between current product practice, customer trust, and the next decision a team could actually take.
01400+ cold-outreach attempts
02Research through the ecosystem
03Founder reality: survival competes
04Transparency-first product hypothesis
More than 400 cold-outreach attempts yielded too little founder participation, so the team broadened discovery, surfaced founder constraints, and chose a transparency-first direction.

What I actually did

My role and decision authority

I functioned as the strategy lead on a four-student team whose members all brought product or UX backgrounds. We worked collaboratively; I led the core framing and product-strategy workstreams while contributing across delivery and evaluation.

I led

  • Product vision, research strategy, problem framing, and research synthesis
  • Requirements, prioritization, product flow, and intended AI architecture
  • Mid-quarter pivot narrative and the transparency-first opportunity
  • Team coordination and synthesis of pilot evaluation changes

I shared or contributed

  • Sponsor presentations, user interviews, research synthesis, UX design, testing, and integration
  • Prototype direction and major product decisions with the full student team
How we made decisions

The student team shaped major product decisions collaboratively and reviewed the direction in weekly sponsor syncs. RIL contributed ideas and approved the direction; UW GIX faculty provided guidance.

Trust, translated

The decisions that changed the product

01

Recover the research instead of waiting for ideal participants

Signal
More than 400 cold-outreach attempts produced too little founder participation for the original research plan.
Decision
Expand discovery through the surrounding ecosystem and synthesize patterns across founder, investor, technical, design, healthcare, policy, and Responsible AI perspectives.
What changed
The team found the tension between Responsible AI intent and startup survival pressure.
Tradeoff
The broader sample recovered momentum but did not replace direct validation with a larger founder cohort.
02

Choose transparency over a broad framework product

Signal
Framework volume did not answer why a founder should act now or what to do next.
Decision
Use transparency as the first useful wedge: connect current practice, customer trust, and practical improvement.
What changed
The product moved toward tailored questions, a disclosure report, explanations, priorities, and next actions.
Tradeoff
The concept narrowed its ambition and did not attempt to deliver a comprehensive governance program.
03

Explain sensitive inputs before collecting them

Signal
Participants questioned unfamiliar terms, data handling, and why the system needed specific business details.
Decision
Add contextual guidance and make the purpose of each sensitive input visible in the flow.
What changed
Trust requirements became interface requirements rather than a final disclaimer.
Tradeoff
The flow became more instructional and required careful pacing to avoid overwhelming users.
04

Preserve review and editing before disclosure

Signal
Users could not safely rely on generated scores or recommendations they could not trace or interpret.
Decision
Show input-to-output mappings and let users review, edit, and download the report before sharing it.
What changed
Human authority became part of the primary experience, not an exception path.
Tradeoff
The product demonstrated decision support rather than automated risk or compliance assessment.

From decision to system

A hosted prototype built to make the direction testable

Without a dedicated engineering team, we used a low-code stack. The workflow evolved across the capstone—from early RAG exploration, to a Webflow/Zapier/Sheets/OpenAI prototype plan, to a later Firestore, rules, model-assisted generation, CMS, and PDF handoff.

  1. 01

    Onboard

    Capture domain, base model, core function, intended use, audience, and current Responsible AI practices.

  2. 02

    Tailor

    Map product context to relevant questionnaire modules across privacy, fairness, safety, misuse, and synthetic content.

  3. 03

    Assess and explain

    Combine answers, rule-based scoring, and model-assisted analysis to assemble risk areas and recommendations.

  4. 04

    Review, edit, and export

    Render a draft disclosure report that the user can inspect, modify, and download before external use.

RADARs product-flow diagram showing onboarding, tailored assessment questions, scoring, report generation, review, editing, and download across user, system, and database layers.
One prototype-flow iteration used to align onboarding, assessment, and report generation. The low-code pipeline evolved and remained partially implemented; this does not represent a production architecture.

Working or demonstrated

  • Structured onboarding and product-context inputs
  • Tailored Responsible AI questionnaire modules and guidance
  • Submission and report-generation flow
  • Rendered report with review, limited editing, and download path
  • Configured low-code data/model workflows and technical handoff documentation

Not production-ready

  • Independent validation of generated guidance or reliable assessment
  • Calibrated scoring, confidence, and source-grounded recommendations
  • Production-grade security, privacy, access controls, and monitoring
  • A completed RAG system or verified post-handoff adoption

What the evidence says

Seven formative tests showed exactly where trust broke.

Evaluation method

Seven-person formative evaluation spanning technical practice, AI startups, product design, and AI transparency. The metrics describe this small study only and are not evidence of market adoption or assessment accuracy.

The topline numbers helped locate friction; the questions underneath them drove the product changes.

85%
reported task completion in the formative study
1.2
reported errors per participant
7 min
reported time per module
4.2 / 5
reported average satisfaction
  • People struggled to see how early inputs mapped to questionnaire modules and report outputs.
  • They questioned sensitive-data handling, the trustworthiness of generated content, and what scores meant.
  • Guidance, progress, and download controls were too easy to miss.
  • The team prioritized clearer progress, terminology, input-to-output mapping, report structure, next steps, and explanations for requested data.

Outcome and impact

A broad brief became a concrete, testable product direction.

The team delivered and handed off a hosted interactive application prototype plus technical reconstruction guidance. A real user could complete onboarding, answer tailored questions, wait for report generation, review and modify the draft, and download it.

The product and team impact is clear: a recovered research plan, a shared transparency-first direction, a testable workflow, and evidence-backed changes. The scoring and AI guidance remained partially simulated or unvalidated, and sponsor continuation after handoff is unknown.

Strategy impact
broad brief → transparency wedge
Product impact
hosted human-editable prototype
User evidence
seven-person formative study
Handoff
prototype + technical guidance

Current boundary

What this work does not establish

  • The deliverable was a hosted interactive prototype, not a validated compliance or risk-assessment system.
  • The low-code data, scoring, and generation workflow was partially implemented and changed across the project.
  • Security, privacy, access control, monitoring, calibrated confidence, and generated guidance were not production-validated.
  • Grounded retrieval and production RAG were future architecture, not completed capability.
  • The project was handed off; sponsor continuation and adoption are unknown.

The next honest release

What I would build next

  1. Introduce least-privilege access, explicit retention, and consent for sensitive inputs.
  2. Add deterministic checks, citations, and source-to-recommendation mappings.
  3. Calibrate confidence and make uncertainty visible throughout the report.
  4. Require human approval before disclosure and add audit logs and regression tests.
  5. Validate the assessment logic with qualified Responsible AI, legal, and technical reviewers.

Reflection

Trust is not the polish added after an AI feature works. It is the behavior that lets people understand why information is requested, trace how inputs become outputs, question uncertainty, and retain authority.

Continue exploring

The human approach behind the work

About my approach