Designing trust into
an AI-mediated
product

Confidential AI product client · UX / Product Design · 2025–Present

I lead UX and product shaping for an AI-enabled product exploring how fragmented development information can become useful context for cross-functional teams.

01

The problem

What was built is visible.
Why it exists often isn’t.

  • Code
  • Release notes
  • Assets
  • Features

Visible, structured, easy to find

  • Decisions
  • Context
  • Reasoning

Scattered, implicit, disappear over time

Complex product work produces information across tools, conversations and technical systems. The opportunity was not to generate more information. It was to help people understand what is happening, what changed, what matters and what they can trust.

02

My role

UX Lead /
Product Design

Responsibilities

I lead UX and product shaping: framing opportunities with product leads, designing the experience, running live pilots with cross-functional teams and evolving the product hypothesis from what we learn. The underlying AI system is built by the technical team.

Scope
Product discovery · Product shaping · Interaction design · AI experience · Live pilots
Working with
Product leads · Cross-functional teams · Technical leads
Not mine
The models and infrastructure behind the product

03

The hypothesis

Recover context from the traces the work already leaves behind.

Instead of asking people to document every decision manually, we explored whether signals from everyday work could be interpreted and turned into useful context. The chain below is the product-learning model the pilots were built around.

  1. Signal
  2. Context
  3. Human fit
  4. Ritual fit
  5. Reuse

04

Live pilots

More signal did not create more understanding.

At first the problem looked like collecting and summarising activity. The pilots showed that more signal did not necessarily create more understanding. The experience needed to move from raw activity toward contextual information that was scoped, prioritised and understandable in the moment.

Product evolution across the pilots Four abstract panels: a dense stream of raw activity, the same activity grouped under headings, a single scoped brief with source and freshness markers, and a question box with an answer assembled on demand. RAW ACTIVITY High noise GROUPED UPDATES Clearer grouping CONTEXTUAL UNDERSTANDING Scoped · prioritised · sourced ON-DEMAND QUESTIONS Context on request
Conceptual product model drawn from the design logic of the pilots. Interface details are abstracted; no client screens are shown.
  1. Raw activityHigh noise
  2. Grouped updatesClearer grouping
  3. Contextual understandingScoped · prioritised · interpreted
  4. On-demand questionsContext on request

05

What we learned

  • Activity to Context

    More information did not automatically create better understanding.

  • Generated documentation to On-demand understanding

    Testing validated value beyond scheduled documentation, including letting people ask directly for the context they needed.

  • Core team to Downstream reuse

    Context became especially valuable outside day-to-day working conversations.

  • More sources to Trusted sources

    Authority, freshness, scope and traceability became part of the design problem.

06

Trust became part of the product architecture.

As the product moved from activity toward interpreted context, the question people asked shifted from “is this summary good?” to “can I act on it?”. Five questions kept returning in the pilots. They were treated as requirements for the experience, worked through progressively rather than solved at once.

Source authority

Where did this information come from?

Context is only as credible as its origin. Making the origin visible, rather than implied, let people weigh it.

Freshness

Is it still current?

In fast-moving work, yesterday’s context can be wrong today. Recency had to be part of the information, not a footnote.

Scope

What does the system actually know about?

People needed to understand the boundary of what was covered, so silence was not mistaken for “nothing happened”.

Traceability

Can someone understand why the system produced this context?

A conclusion people could follow back to its signals was one they could check, correct and reuse.

Human validation

Where does human judgement still belong?

The design assumed people stay in the loop. The open question in each pilot was how much validation effort was reasonable before the context was used.

07

Moment of use

A useful artifact is not automatically a useful product.

The pilots showed that quality alone was insufficient. A well-formed piece of context still needed a real moment of use.

  • Who

    Who needs the context, and how far from the work are they?

  • When

    When do they need it: on a schedule, at a decision point, or on request?

  • Validation

    How much checking effort is reasonable before people rely on it?

  • Fit

    Does it fit an existing workflow or decision point, or does it ask for a new habit?

Artifact quality and ritual fit turned out to be separate problems, and both had to hold for the product to be used.

08

Where value emerged

Context becomes more valuable as distance from the work grows.

Close to the work

Core team

Already knows much of what happened

Context

Further from the work

Adjacent teams · Operational roles · Later joiners

Need context without being part of every conversation

09

Current direction

One maintained understanding. Many contexts.

Maintain understanding

Assemble context

  • Handover
  • Re-onboarding
  • Planning
  • Questions

Useful · Trustworthy · Low effort · Stays current

The core design challenge became less about generating information and more about designing the conditions under which AI-generated context becomes trustworthy and useful.The product is still in pilots. What has changed through them is the hypothesis.