Choose Tools Your Team Can Use | Heidelberg AI Curriculum
T16-L02
Choose & Evaluate AI Tools · Power user
Choose Tools Your Team Can Use
Run a small voluntary trial on a real shared task and choose a workable team tool using evidence about quality, collaboration, accessibility, exports and realistic costs.
A tool can work beautifully for you and still make your teammates' work harder. Someone cannot open the result, comments vanish during export, or the person correcting the output spends longer than the person generating it saved. A team choice has to survive that handoff.
Choose a real shared task and invite a few willing colleagues or collaborators to try a small shortlist. Produce a useful shared result and a brief team decision that includes collaboration, accessibility, exports, total realistic costs, and data handling. The current tool, including a non-AI workflow, is allowed to win.
This is a power-user responsibility: your team may see a bad document or a wrong figure if the process fails. You will keep someone responsible for reviewing the shared result. You are not creating a central procurement process, connecting organisation-wide systems, or asking the whole team to migrate.
1. Structure: start with a shared piece of work
Ask the people involved: “What do we repeatedly produce together, and where does it become awkward?” Choose a task they recognise, not a demonstration selected to flatter a product.
Optional examples include preparing a meeting agenda from agreed notes, turning team feedback into a draft revision list, or producing a shared presentation from material the group owns. Use your team's actual task if it is different. Narrow a large project to one useful deliverable rather than replacing it with an assigned dataset.
Describe the input, the action, and the output. Then add the people: who prepares the input, who changes the draft, who reviews it, and who needs the final version? One person may fill more than one role. The point is to notice the handoffs that an individual trial misses.
Agree on three or four signs of success. For an agenda, they might be that agreed topics remain intact, contributors can correct their sections, unresolved decisions are visible, and the final agenda opens in the team's usual workspace. These are illustrative; your criteria should fit your shared work.
Ask each participant what would prevent them from taking part. Relevant answers might include an inaccessible editing control, an unsupported device, a new personal account, an unsuitable language interface, or a file format they cannot use. People do not need to disclose a diagnosis or private circumstances to explain a working requirement.
Set a small boundary: one deliverable or one short cycle, a few volunteers, an end date, and a spending limit. Agree that declining or withdrawing is acceptable. Keep the current method available so participation does not become an obligation disguised as an experiment.
2. Understand: inspect the whole handoff
Walk through the current workflow with someone who receives its output. Keep a recent suitable artifact or complete the next small instance as a baseline. Ask where information gets lost, where people wait, and where someone repeats another person's work.
A faster authoring step is not automatically a team improvement. If a draft takes five fewer minutes to create but leaves every reviewer struggling to locate changes, the work has moved rather than disappeared. Record effort by role as well as elapsed time. Label any remembered times as estimates.
From our own curriculum-building journey: manuscripts were written quickly, but preparation, handoffs and publication left the course owner waiting without a clear view of what was live. In the observed batch, publishing twelve books completed about four seconds after Payload initialised; the surrounding workflow and coordination took longer. This is one recorded experience, not a benchmark of a model or platform. For your trial, measure the whole interval from request to usable result, and keep four states visible: working, prepared, live, or blocked. Fast generation is not the same as fast delivery.
Identify where mistakes would become visible. An incorrect figure in an internal draft is different from a figure already copied into a client presentation. For this trial, keep a named reviewer between generated content and normal team use. The reviewer checks the things that matter to this deliverable: perhaps claims against the source, numbers against the calculation, or commitments against the team's actual agreement.
You do not need to construct a separate verification project. Review the shared work you genuinely intend to use. A polished assistant answer is still a draft until the responsible person accepts it.
Understand access and data before inviting people
For each candidate, establish who can see the input, who can edit, who can share, and who controls the workspace. A shared link is not a complete collaboration model. Check whether access is restricted to named participants, whether guests need accounts, and whether permissions come from a parent folder or workspace.
Google's official sharing documentation, checked on 9 September 2026, distinguishes viewers, commenters, editors, and owners, and explains inherited folder access. Those details illustrate why role names and the actual sharing location matter. They do not establish that another tool behaves the same way.
Use accounts and material already permitted for the shared task. Agreement among trial participants does not override someone else's data rights or existing workplace rules. Share only the material needed. If a candidate cannot handle essential input under appropriate conditions, exclude it; preserve the team's task rather than forcing an irrelevant substitute exercise.
Read the provider documentation for the actual plan and features you would use. Look for retention, training use, deletion, and any additional services receiving uploads or connector data. OpenAI's Data Controls FAQ illustrates one important distinction: opting out of training does not itself remove chat history. Do not treat a privacy claim for one account type as a promise covering every plan.
Keep this bounded. You need enough information to choose within the team's existing authority. If a candidate requires permissions or commitments outside that authority, mark it unavailable for this trial and use an appropriate alternative. Do not turn the lesson into a new approval bureaucracy.
3. Choose LLMs, Agents, skills, tools
Make a shortlist of two or at most three workable options. Include the incumbent as a candidate or explicit baseline. At least two options should be practical to try on the same shared task within your agreed limits.
The tools catalogue can help discover candidates by purpose. On 9 September 2026, the public API reported 145 entries and all 145 were unverified. Treat descriptions and tags as starting points for checking official documentation, not as a verified shortlist or endorsement. Stop searching once you have enough plausible options.
Choose the workflow, not just the model. A strong language model with awkward permissions may be less useful than a modest assistant inside an editor the team already uses. An agent adds value when its actions remove real work; it also introduces permissions and supervision. Add a specialist skill only for a demonstrated need. Manual review and ordinary document tools may be the best combination.
Before the trial, rule out candidates missing a must-have: permitted input handling, usable access for participants, the required export, or an affordable plan. For the survivors, compare the experience through actual work. A marketing feature list cannot show how smoothly your teammate picks up your draft.
Make cost mean the whole workflow
Use current official plan or billing information and record the date, currency, and billing period. Determine who actually needs a paid seat, whether guests can perform the required actions, and whether your current plan already includes the feature. Note seat minimums, renewal commitments, trial expiry, usage limits, storage, and required add-ons where relevant. Do not assume a per-month display means a monthly commitment.
Keep cash and effort visible separately:
Expected recurring cash cost =
required seats at the applicable rate
+ expected usage charges + necessary add-ons or storage + applicable tax
One-off effort = setup + learning + moving the needed material
Recurring team effort = preparation + operation + review + export + support
Use the provider's actual pricing structure; the lines above are a reminder, not a quotation. Count only costs relevant to your task and avoid double-counting included usage. If comparing money and time, use an agreed hourly value and state the assumption, or simply report currency and minutes side by side.
For variable usage, make a low and a plausible busy-period estimate based on the team's expected frequency. Leave unknowns visible. A free trial establishes neither the later bill nor the value of an annual commitment. Do not buy a subscription merely to complete this lesson.
Copy this template into the team's existing shared document. It is both a trial agreement and the decision artifact; short factual entries are enough.
TEAM TOOL CHOICE — [date]
Shared task / input / usable deliverable:
Participants who opted in; trial end date:
Current workflow and baseline artifact:
Success criteria; access and accessibility must-haves:
Time and spending limits:
Who reviews the result before team use:
Shortlist: [A, B, optional C; identify incumbent]
For EACH candidate:
- Product / model if visible / plan / trial date:
- Official feature, pricing and data-handling links; dates checked:
- Who prepares, edits, comments, reviews and receives:
- Input allowed; workspace owner; sharing restrictions:
- Output location; criteria met; mistakes and corrections:
- Handoff, accessibility and export observations:
- Observed minutes by role; one-off learning kept separate:
- Trial spending; recurring cash estimate and assumptions:
- Unresolved questions or excluded features:
Decision: [choose / keep incumbent / defer]
Reasons tied to the evidence; disagreement or untested needs:
Use only for [scope]; review responsibility:
Final editable artifact and accessible reading copy, if needed:
Fallback location and person keeping the files:
Trial cleanup owner; renewal/cancellation action if applicable:
Next review trigger or date:
4. Build: run a limited voluntary trial
First, agree on equivalent work
Give the candidates the same task brief, appropriate source material, success criteria, and required output. Keep separate drafts so nobody accidentally overwrites the baseline. Use each tool's ordinary workflow; a non-AI editor does not need to imitate a chat interface.
Include the purpose, audience, and constraints in an assistant's instructions. Ask it to identify missing information rather than invent it. Record the brief and relevant settings. Let participants receive a similar short introduction to each unfamiliar tool and record that learning time separately.
If trying the second candidate benefits from understanding gained during the first, note that limitation. You can reverse the order for a second small portion when convenient, but this is a practical team trial, not a requirement for a controlled study.
Next, make someone else use the draft
Have one volunteer create the initial output and another open it through their own account or normal access route. The recipient should complete a real next step: correct a paragraph, comment on a disputed item, revise a figure, or prepare the final version.
Observe whether the recipient can find the right version, see useful context, and make the permitted change. Check whether the author notices the correction and whether conflicting edits can be resolved. Use history or recovery features on a harmless edit in the trial copy if undoing mistakes matters to the workflow.
Inspect the share settings and test intended viewer or commenter access where relevant. Do not share account passwords to make the trial appear easier. If an advertised collaborative feature requires a higher plan, record that limitation and its checked cost rather than pretending the feature was tested.
Make accessibility part of doing the task
Ask volunteers to use their normal devices and interaction methods. Check the important path: opening, navigating, editing or commenting, and obtaining the output. Try keyboard operation with visible focus and zoom that makes text comfortable to read. For media tasks, inspect relevant captions or transcripts, including whether corrections are possible.
The W3C Easy Checks guidance provides practical starting points, but a quick pass cannot establish full accessibility. Record what was actually tried and what remains unknown. A participant's reported barrier should not disappear into an average satisfaction score.
An alternative can be appropriate if the affected person finds it workable: for example, an accessible reading copy for someone who only needs to read. A PDF is not a replacement for accessible editing when the person's role requires editing. If a must-have remains unmet, keep the incumbent or narrow the proposed use with the team's agreement.
Export and finish the deliverable
Export to the format the team actually needs, then have a recipient open it outside the candidate tool. Check the elements your task depends on: headings, tables, formulas, links, comments, images, or speaker notes. An export button alone does not show that these survive.
Distinguish a readable copy from an editable one. A flattened image might look correct while making the next revision impossible. Preserve an editable artifact where revision matters, and note any information that must be kept separately.
Have the named reviewer inspect the result before it enters normal team use. Record important corrections and their effort. Stop a candidate's trial when it hits the agreed time or spending limit or cannot meet an essential requirement. A failed attempt is useful evidence when you can say where it failed.
Decide together from the evidence
Collect a short response from each volunteer: what helped, what created extra work, and whether they could complete their role. Compare quality, handoff friction, accessibility, data handling, and total costs alongside the incumbent. Keep observations separate from assumptions and features you only read about.
Do not average away an essential constraint. A workflow that excludes a necessary contributor is not rescued by several enthusiastic ratings. Where both options meet the requirements, favour the one whose benefit justifies its recurring effort and cost. Choosing the familiar tool is a valid outcome.
An illustrative team decision
Imagine a small project group preparing its regular progress update. It compares its existing shared editor with a new AI drafting workspace, using the same agreed notes. This is an optional illustration, not an observed trial or a prescribed assignment.
Suppose the new workspace creates a clearer first draft, but a reviewer cannot use its commenting controls with their normal keyboard workflow, and comments disappear in the export. The existing editor requires more drafting but supports the complete handoff.
The group could retain its editor. It might later consider AI-assisted drafting within a permitted workflow, but the trial has not established that broader option. Its decision should say what the evidence supports today: “Keep the current editor for shared progress updates because everyone can review and revise the usable artifact.” No invented timing or vendor price is needed to make that reasoning concrete.
What to keep, and what comes next
Keep the reviewed deliverable, completed decision note, and files needed to continue in the current workflow. Name who keeps the shared output and who checks future AI-assisted drafts for this task. Close unneeded trial sharing, retain necessary work before deleting copies, and handle any trial renewal or cancellation on the agreed date.
You are ready to leave when volunteers have completed a real handoff in at least two options, the output has been reviewed and reopened in its intended destination, and the team can explain its choice and limitations. If participation or access prevented that, keep the note as a proposal and name the missing observation; do not report a completed team trial.
A small voluntary sample does not prove suitability for every colleague, workload, or future version. Revisit the decision when participation needs, terms, costs, or the task changes. If colleagues will depend on software you build or connected organisational systems, the responsibility has moved beyond this bounded team-tool choice.
For running an ongoing project workspace, use T02-L02. For connecting a tool to local inference, use T11-L02. For helping a colleague try a workflow, use T13-L02. This book owns the team choice; those books teach the specific work.
Source and editorial notes
All following sources were fetched on 9 September 2026. Provider documentation is evidence about documented behaviour, not proof of performance in this team's environment.
Payload level definitions (opens in a new tab): L02 is Power user, responsibility “Your team sees a bad document or a wrong figure”, with a 1,500–3,000-word range. The Structure, Understand, Choose, Build sequence follows T06-L01.
Public tools API (opens in a new tab): 145 total entries, matched by 145 returned as the total for an unverified-status query. Catalogue inclusion is not independent product verification.
W3C WAI: Easy Checks (opens in a new tab): primary guidance supporting initial checks of keyboard focus, zoom, captions, and other barriers. The fetched page is labelled a draft update and explicitly limits the scope of these checks.
OpenAI: Data Controls FAQ (opens in a new tab): primary example distinguishing training preferences from chat-history retention. Check the applicable account and plan rather than generalising from this example.
Original drafting: Astra / OpenAI (openai/gpt-6-astra). The journey note records the course owner's reported experience and publication job 35042 on 9 September 2026. No learner team trial, accessibility session, vendor-price verification, or classroom result is claimed.