← AI lab

Copilot documentation agent

Documentation should not need a blank-page expert.

Project
UX Documentation Assistant
Type
Workplace initiative, AI lab
Role
Agent workflow, documentation model, adoption guidance
Year
2025
Status
Private workplace tool
  1. 01 A short conversation
  2. 02 A structured draft
  3. 03 A findable record
Conversation, draft, findable record: the third box gets skipped

TLDR

I built a Copilot agent that turns rough notes into structured design documentation. A colleague used it on a live project and raised it with senior management. A team habit never formed, and nothing was measured.

01

The missing record

Designs survived handover; the reasoning behind them often did not.

I joined a team with a nearly empty Confluence space. People explained the gap as lack of time, but documentation also meant a blank page and an unclear standard. On a client portal, inherited comments could not explain why a direction had changed. A record would have shown what everyone was assuming.

02

The workflow

A short Teams conversation produces a draft with a predictable home.

The agent covers screen design, flows, research and workshops. It accepts fragments and marks gaps To be confirmed. I paired it with page names and a Confluence structure. A person reviews and copies the result: Copilot and Confluence are not connected. Project Meadow below is a fixed, fictional demonstration of separating decisions from feedback, assumptions and unresolved actions.

  • Type 01 Screen and feature design

    What it does, what was agreed, which states exist.

  • Type 02 Prototypes and user flows

    The route through, and what it assumes about the person taking it.

  • Type 03 Research sessions

    What was asked, what came back, what it does and does not support.

  • Type 04 Workshops and ideation

    Who was there, what was generated, what was actually chosen.

  • UX design space
    • Project
      • Overview and goals
      • Screen and feature docs
      • User flows and prototypes
      • Research and testing
      • Workshops and ideation
Proposed Confluence structure organised around four design documentation types
Walk through the four steps of the Project Meadow record

Fictional demonstration

Project Meadow, a team scheduling service

An invented product and an invented design review about a notification filter, from a handful of fragments to a page someone else could act on.

  1. Part 1

    The notes

    Notes from a design review, the way notes really get written. Everything in them looks equally important.

    • notification centre filters
    • people need to find urgent shift changes, current list all mixed together
    • proposed chips: All, Action needed, Unread
    • support lead liked Action needed because apparently people miss shift changes
    • product manager asked whether Updates would be easier language
    • engineering can support the three states for pilot
    • agreed keep Action needed after discussion
    • default All so people do not think messages disappeared
    • not sure what happens when a filter has no results
    • need product manager to confirm empty state before handoff
    • think this makes important changes easier to find but no testing yet

  2. Part 2

    Sorted

    It works out this is a screen and feature record, not research or a workshop, so it knows which questions to ask and where the page will live. It asks four quick ones, takes fragments back, then sorts the pile.

    Screen and feature design Not research Not a workshop

    • Decision

      Three filters: All, Action needed, Unread. Default All, and newest first stays as it is.

      Agreed in the review
    • Feedback

      The product manager suggested Updates instead of Action needed. The group kept the original after discussion.

      An alternative, not a label
    • Reported signal

      Support hears that people miss shift changes. The underlying tickets have not been reviewed.

      Not research evidence
    • Assumption

      Filtering will make important changes easier to find. Nobody has tested this.

      Untested

    Engineering’s go-ahead is kept as a constraint, and the empty state as an action with an owner.

  3. Part 3

    Off limits

    The draft is ready to review, not to approve. These are the things the agent isn’t allowed to do.

    • It must not turn support feedback into user research.
    • It must not state that the filters reduce missed changes.
    • It must not decide the no-results behaviour.
    • It must not present Updates as an agreed label.
    • It must not invent a deadline, an owner or a design link.
    • It must not publish anything without a person reading it first.

    Here the reviewer checks who attended, adds the design link inside the private page only, and publishes with the empty state still open. That’s fine, because it has an owner and a deadline.

  4. Part 4

    The page

    Fictional record

    Notification filter, UX documentation

    One behaviour unresolved
    Problem

    Shift leaders receive several kinds of notification in one chronological list, so changes that need a response can be hard to distinguish from general updates.

    Decision

    For the pilot, filter by All, Action needed and Unread. Default to All so nothing appears to have vanished, and keep newest-first ordering inside each filter. The team considered Updates and kept Action needed, because the label signals that a response may be required.

    States and behaviour
    State Expected behaviour
    All Selected by default, every notification, newest first.
    Action needed Notifications that require a response or an action.
    Unread Notifications not yet marked as read.
    No results To be confirmed
    Open action

    Confirm whether a filter with no results reuses the generic empty state or explains the selected filter and offers Clear filter. Owner: product manager. Required before design handoff.

    Evidence and assumptions
    • Reported: support hears about missed changes, tickets not reviewed.
    • Confirmed: engineering can support the three states for the pilot.
    • Assumed: filtering makes important changes easier to find. Untested.

03

What happened

A colleague documented part of a project with it, then raised it with senior management.

I tested incomplete real input, used the agent myself and gave selected designers access. That colleague recalled a draft taking about five minutes, which is a recollection, not a controlled comparison. I do not know usage frequency, correction effort or whether the proposed Confluence structure was adopted. Neither team time saved nor documentation quality was measured. I was then asked to share it with the wider product owner team. It went out as a link, with no session and no owner, and no feedback came back.

04

What I would change

Next time, a committed pilot and an agreed measure come before the link.

I shared a link without establishing a committed pilot, a workflow owner or a working session together. Next time I would document one live piece of work with a participant who agrees to continue, and agree measures first: accuracy, editing effort and whether open items get confirmed. Connecting reviewed records to delivery tickets remains a direction, not a current feature.