Agree what the tool is for before trying it

What we found in the news

In January 2025, the FDA issued draft guidance for AI-enabled medical-device software (opens in a new tab). Among its proposed documentation was:

“A description of the intended users”

— U.S. Food and Drug Administration

The document was a draft, explicitly not for implementation, and concerned medical devices. We are drawing a modest design lesson from it, rather than treating a community tool as a regulated device: explain who will use a tool and what they will use it for before judging whether it is useful.

Why this matters to us

A pilot can begin with a broad ambition and end with several people trying different things. One colleague wants help preparing an invitation. Another expects advice on whom to invite. Someone else assumes the tool can contact people automatically.

Those are different tasks, with different information needs and consequences.

Imagine a community-program team choosing a single task for a small trial: prepare a first draft of a public activity invitation from confirmed details. A participant joins the discussion and helps identify what a useful invitation should explain.

The laptop can wait a moment. Agreeing on the work gives the team something meaningful to try.

Put one ordinary task into words

Describe the starting material, the person using the tool, and the result they expect to review. Keep the description concrete enough that another colleague can recognize the same task.

For the imagined invitation, the input might be an approved activity card with a venue, time, and contact. The intended result is draft wording for a staff member to check.

Identify the people affected beyond the operator. The participant receiving the invitation may need an access detail that staff overlook, while the colleague answering questions needs the final information to match the actual program.

Ask what the tool should do when a detail is missing. Leaving a clear gap for review is more useful than producing a confident sentence that nobody has confirmed.

Keep the boundary visible during the trial

Set aside related tasks that need a separate decision. Choosing who should attend, inferring someone’s preferences, and sending an invitation may require different authority and information.

In the workshop, picture cards can make those distinctions easy to discuss. One card goes into the agreed trial; others remain in a tray for later consideration.

Give staff a clear way to raise an unexpected use. An apparently helpful suggestion can expand the trial without anyone noticing, especially when a tool responds fluently to many questions.

The boundary should help people work, rather than become a document nobody reads. Put the relevant instruction near the task and check that colleagues explain it in the same way.

Agree what would justify the next step

Before trying the tool, decide what the team needs to observe. Does the draft preserve confirmed details? Can a reviewer spot uncertainty? Does the participant find the resulting invitation understandable?

Use a few representative examples and record the limitations of that small exercise. A good result on a simple invitation may justify another test, while leaving more complex uses unsettled.

Name the person who can approve a change to the trial. If the team wants to use private information or add an action such as sending messages, pause to review the new purpose and arrangements.

Make the decision visible afterward. Explain what will continue, what needs adjustment, and what has not yet been agreed. A narrow trial can provide useful learning without quietly becoming a much larger service promise.

What this means for the people you serve

People should be able to understand the role technology plays in a communication or service they receive. Their contribution can help define what a useful result looks like. A clear purpose also gives them a better basis for asking questions when the experience does something unexpected.

The genus connection

Today, genus partner-portal workflows can support configured preparation and staff review, with AI assistance scoped to enabled functions and appropriate information access.

That makes an agreed task a sensible place to begin. Confirm the available function, the reviewer’s responsibility, and the intended audience, then try the workflow with realistic examples. Further uses can be considered on their own merits when the team knows what would change.

One question to take away

Can everyone involved describe the same task, the same audience, and the same point where a person decides what happens next?