Services

AI Product UX

Design the relationship between people, models and product state so AI-native products, copilots, agents and AI features match the work users need to do.

  • AI product UX
  • Copilots and agents
  • Product responsibility
Bring the user decision and proposed AI role (opens in a new tab)

An AI feature is not one interaction pattern

Before choosing chat, copilot or agent, define the role the model plays.

  • Generate a candidate.
  • Transform supplied material.
  • Retrieve and synthesise evidence.
  • Recommend.
  • Predict or detect.
  • Orchestrate steps.
  • Act with delegated authority.

Each role introduces different uncertainty and control. A drafting assistant needs editing and source constraints. A recommendation needs basis and alternatives. An action needs permission, preview, state, stopping and recovery.

The AI product responsibility record

Each field connects an AI product design concern to the product decision it requires.

AI product responsibility record
FieldProduct decision

User work

Which decision or task deserves assistance?

Model role

What may the model produce or influence?

Evidence

What data and sources support the output?

Uncertainty

What can be missing, wrong or unstable?

Authority

What can happen without human approval?

Evaluation

What constitutes useful and safe performance here?

Recovery

How can a person correct or reverse the result?

This record follows the product into design and engineering. It prevents an interface label from carrying more certainty than the system has earned.

How product responsibility combines

Product responsibility combines product, design, evidence and engineering decisions.

  • Opportunity framing and product boundary.
  • Research with target users and domain experts.
  • AI interaction and workflow design.
  • Source, confidence and explanation patterns.
  • Human review, control and recovery.
  • Evaluation scenarios and acceptance.
  • Coded prototypes and product engineering.
  • Integration into existing product roles, state and design systems.

Tcules has worked on 12 AI products across copilots, AI-native tools, AI-powered products and integrations. The cases below show several distinct product conditions inside that experience.

Evidence across different AI conditions

  1. 01

    ConnectX

    An intent-led workspace bounded through eight product scenarios and demonstrated in code.

    ConnectX
  2. 02

    BuildTwin

    Evidence, correction and escalation for an engineer reviewing AI quality-control results.

    BuildTwin
  3. 03

    Eden AI

    Workflow creation and search for a developer-facing AI platform.

    Eden AI
  4. 04

    Novus

    A survey-builder product condition; public responsibility remains bounded by available source.

    Novus

AI-assisted delivery is a separate claim

Authority ladder

  1. 01

    Inform

    The product exposes information while keeping authority with the person using it.

  2. 02

    Suggest

    The model proposes a next step, with consequence, reversibility, evidence visibility, human gate and recovery considered before action.

  3. 03

    Prepare

    The system prepares work for review, correction or approval before it changes product state.

  4. 04

    Execute bounded action

    The system can act inside a defined boundary where approval, stopping and recovery are explicit.

  5. 05

    Act across steps

    The system coordinates multiple steps only when authority, evidence and recovery are clear enough for that product condition.

Start with a bounded decision

Bring the user work, the current product state and the authority you expect AI to receive. If that boundary is still uncertain, an AI Product UX Readiness assessment can create the first evidence.

Start with a bounded AI decision

Bring the user work, the current product state and the authority you expect AI to receive.

Bring the user decision and proposed AI role