Redesign the form everyone hates.

What the AI will do

• Investigate user friction, required information and downstream use.
• Build and test a working form, and revise the process map and form as owners and receiving teams work through changed intake/routing responsibilities.

What you can provide

• The form, relevant process evidence and available tools.
• Actual contributions from intake owners and teams receiving or reviewing requests.

Where you'll take part

• Resolve consequential requirements and involve the affected teams in working through the new intake flow or responsibilities.
• Review a working path and the shared arrangement; authorize any production rollout separately.

What you'll get

A working revised form or prototype, a checked field-to-output map and a jointly worked-through intake/routing arrangement, with missing production integration and unresolved issues identified.

Activity context

The form everyone hates may be asking sensible questions at the wrong moment, using internal vocabulary or making people enter information the organization already has. Find what the process truly needs, then make the form work for the person completing it. Work with process owners and receiving teams to redesign the shared intake and routing arrangement around it.

For the user

Give AI the form and process context. It investigates, builds and tests a revision. Work through revised intake/routing responsibilities with process owners and receiving teams, then have AI incorporate their actual contributions and recheck the form. A solo prototype is preparation; production rollout is separate.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Redesign a frustrating form and build a working revised version. Investigate the experience and required information, preserve the process's necessary outputs, implement the new interactions and test them. Keep prototype checks, production integration and feedback from real users distinct.

1. Inspect the form and the work around it

Start with the supplied form, link, screenshots or description. Try available form-builder access and inspect every reachable page, branch, error state, help text and confirmation. Identify who completes it, why, on which devices and what happens after submission. Examine a blank form and permitted example submissions; use synthetic data for test submissions.

Search relevant accessible completion-error records, abandonment or analytics data, support emails, chats, user feedback and process documents. Look for repeated misunderstandings, information people cannot easily supply, duplicated entry, unclear vocabulary and requests that do not match the way users think. Search operations correspondence and workflow documentation for what recipients actually do with each answer. Separate recorded user complaints from your interpretation of likely friction.

Inspect whether you can read and edit a safe copy, run a local prototype and inspect outputs. If access fails, investigate export or other supported routes before asking me for a specific action. Screenshots can support a redesign but do not establish hidden validation or routing; explain consequential gaps early and seek the missing configuration where possible.

2. Establish which information the process really needs

Build a field-to-output map containing each current question, its purpose, required or optional status, validation, conditions for appearing, downstream destination and evidence for the requirement. Include identifiers, attachments, notifications, approvals, calculations and exports where they are part of the process. Check whether removing or renaming a field breaks a receiving system's expected schema.

Distinguish confirmed requirements, inherited convention, duplicate information and requirements no source currently explains. Do not delete a field merely because its purpose is unclear. Ask the responsible question one at a time and wait before making a consequential change. Use existing user decisions when they already settle the issue.

If the form serves materially different users, establish their roles and situations from actual records. A first-time supplier may need different explanations from an internal requester; do not invent their attitudes. Translate genuine differences into necessary branches or help, preserving a common path where possible.

3. Develop a clearer flow and resolve material choices

Separate requirement investigation from design exploration. For a substantial form, give bounded agents the current form and relevant evidence: one checks required data and downstream use, another explores sequence and wording after the requirements are established. Require explicit proposed fields, branches, unresolved choices and acceptance checks. Track field and path coverage, run independent work in waves and reconcile centrally.

Design around the user's task:

• Group related questions and ask them in an order that makes sense to the person answering.
• Use plain labels, explain unfamiliar terms and show examples where helpful.
• Show a question only when its answer is relevant, and explain why difficult information is needed.
• Reuse already available information where verified and appropriate; let the user correct it.
• Use specific, recoverable validation messages and preserve valid entries when errors occur.
• Make the review, submission and confirmation states clear.

Write the actual copy and branching rules. Where a consequential choice exists, show two concrete alternatives, explain their effect on user effort and downstream work, and recommend one. Confirm unresolved changes to required information, routing or data use before implementing those parts. Continue independent work while waiting.

4. Build the working revision

Implement the agreed design in a safe copy of the existing form builder or a runnable local artifact, depending on actual capabilities. Include functioning navigation, required-field checks, conditional logic, attachment behavior where supported, review and confirmation. Provide visible labels and usable keyboard focus, and inspect the layout on relevant screen sizes.

Preserve required machine field names or supply an explicit mapping from the new questions to the receiving schema. Implement the agreed output, such as structured submission data, a formatted request or an export, and compare a sample with downstream requirements. Include all necessary values and correct formats; a pleasing screen that drops required data is unfinished.

When the production backend is unavailable, build and test a local submission or export path and label it as a prototype. Distinguish a simulated confirmation from a real saved record. Do not replace the live form or send test notifications to real recipients without authorization for that rollout or test. Continue to a reviewable working result within the available scope.

5. Test completion paths and the actual outputs

Create a compact test matrix covering ordinary completion, each material branch, missing required inputs, invalid values, optional blanks, back navigation, corrected answers and submission. Include representative edge cases from the complaint and error records. Verify hidden irrelevant answers are handled intentionally and repeated submission does not falsely suggest a new success.

Run the tests, inspect the rendered form and resulting records or exports, and repair failures. Where an integration is connected, verify the destination received the expected data through a permitted test route. Record exactly what ran and what remains untested.

Give a fresh reviewer the actual working form, requirements, source evidence and test scenarios, without your design rationale. Ask it to complete realistic paths, identify unclear questions and check required downstream outputs. Treat agent personas and synthetic runs as simulated use. Do not report improved completion time, lower abandonment or user satisfaction without measured evidence.

Without separate agents, use bounded passes or fresh sessions with a handoff of requirements, sources, artifact, decisions and remaining coverage. State when review shares drafting context. Resolve material findings and rerun affected paths.

Work through the intake arrangement with process owners and receiving teams

Before calling the shared-work change complete, involve the actual people who own intake and use the submitted information. I can host a working discussion and return notes or a transcript, or provide their contributions in an agreed document. Prepare a clear current-versus-proposed process map and specific choices. Do not treat an AI persona, a quick access check or one person's review of a prototype as these teams working through a changed process.

Have them work through who supplies information, when it is needed, how a request is routed, who reviews it and who handles an exception. Use their actual responses to correct the field-to-output map and design the changed responsibilities or flow. Preserve necessary outputs, validation and data restrictions; confirm consequential changes rather than silently discarding requirements. Record what changes in the shared intake arrangement and unresolved disagreements without inferring agreement from silence.

Revise the working form, process map and handoff from that joint work, then rerun affected paths and output checks. A clearer screen alone is not restructuring shared work. The move may finish with a working prototype and teams jointly working through its new intake/routing practice; production replacement and a live rollout are not required. If the work remains only a solo prototype or team input is missing, identify that preparation as unfinished for this version.

6. Deliver the form and its verified scope

Invite me to try a representative path and wait for feedback before interpreting my experience. Revise observed problems. Deliver the working form or prototype, opening instructions, the field-to-output map, tested outputs and the intake/routing arrangement worked through by process owners and receiving teams. State the actual changes to flow or responsibilities and any remaining disagreement. Identify any missing production connection or unfinished real-user trial. Stop at the agreed reviewable result; production replacement and recruiting users for a study require their own authorization.

Done when

Process owners and receiving teams have worked through revised intake or routing responsibilities, and a working form or prototype produces the required checked sample outputs for that arrangement.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.