Let customers prototype what they want from you.
A customer can ask for a better dashboard. Let them build one, and you can see what “better” means: the number they put first, the button they remove, the decision they want to make. This can be a handful of people building in front of you, an invitation on your website, or a useful extra service for important clients.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Find customer frustrations and build an experience in which real customers can describe, make and revise what they wish you offered.
- Collect their prototypes, explanations and observed use, then compare what those contributions reveal.
What to have ready
- A product, service or customer problem to explore; a rough starting point is enough.
- Access to existing customer evidence and an approved way to involve actual customers.
Where you come in
- Choose the setting: a small live focus group, a website anyone can use, or an added service for high-value clients.
- Review the experience before customers enter, observe or host participation where useful, and choose which discoveries deserve a next test.
What you'll get
A working customer-prototyping experience, the participating customers’ creations and a source-linked comparison of what they wanted and why. If participation has not happened, you receive the tested experience ready to use, with that stage still open.
You're done when
You have a working, tested way for customers to make and revise prototypes. After actual participation, you also have their creations, explanations and a comparison that distinguishes observed evidence from your team’s interpretations. If participation or deployment remains unavailable, that unfinished stage is explicit.
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. Help me give real customers an AI-assisted way to prototype what they want from us. Build the agreed experience, support actual participation and turn their contributions into useful product or service learning. ### 1. Find the problem and the people Read what I supplied and identify the product, service or business area. Inspect and try access to customer support tickets, sales and renewal calls, interviews, account correspondence, relevant email, chat and WhatsApp messages, product feedback, usage records and existing prototypes. Search by product, account and recurring complaint to find concrete jobs people struggle to do, workarounds they use and ideas they have already suggested. Use meeting invitations, interview rosters and account roles to distinguish buyers, daily users and people implementing the service. Cite the evidence behind those distinctions; do not turn our team's assumptions into customer views. Summarize a promising area for customers to explore without prescribing their preferred solution. Ask one focused question at a time to settle consequential gaps. If records are inaccessible, inspect available connection or export options first, then help me supply permitted examples or use a clearly limited starting hypothesis. Access to a smaller record narrows what we know; it does not prevent real customers from creating something new. ### 2. Choose how customers will create Explain these three concrete settings and recommend one for the question and participants: - A small live focus group, in person or remote: customers build while we observe, explain their choices and revise in the session. - An experience on our website: anyone in the intended audience can create something and submit it with an explanation. Participation is self-selected; preserve that fact when interpreting patterns. - An added service for high-value clients: help an individual client prototype a workflow, service or tool that fits their situation, capturing both the useful deliverable and what we learn. Let me choose or refine the setting. Establish what participants can make, the intended time commitment and the information they need, keeping room for surprises. A prototype might be a screen, a workflow, a service interaction, a sample report or a clickable miniature of an idea. Clarify what is illustrative and what will actually work. A free-text suggestion form alone is not the promised prototyping experience. Inspect the current AI, coding, hosting, file-generation and collaboration capabilities. Use available tools to build the chosen route. If a website cannot be deployed here, prepare and test the deployable version and investigate the precise supported handoff; offer a working session-based version if we agree that scope. Do not silently replace a public participation experience with a document of instructions. ### 3. Build the whole participant journey Create a welcoming opening that asks about a concrete occasion when the participant needed something better. Let them describe it in ordinary language or supply a rough sketch or example. Have the participant-facing AI ask the next useful question, produce a visible prototype, invite the participant to change it and keep iterating until they say it represents what they want. Do not lead everyone toward our preferred feature. Build a way to preserve the prototype, its important revisions, the participant's explanation and the task it is meant to solve. Ask what matters most, what they removed or changed, how they solve the problem today and what they would try with the result. Let participants inspect what they are submitting and understand whether it is private to us or visible to others. Collect only the account or role context needed for the agreed learning question. State that contributing an idea does not promise that we will deliver it. For a live group, prepare the facilitator's opening and observation sheet and a reliable way for each person to save their own work. For a website, build the creation, preview, revision and submission path, plus a usable way for us to retrieve contributions. For a premium service, make each client's output usable in its agreed form and keep separate clients' work separate. Where useful, give one bounded agent the build specification and another the participant journey to test, using the actual prototype and relevant audience evidence. Keep the reviewer free of the builder's explanation of how the interface is supposed to work. Check that a new participant can start, create, revise and retrieve the result. Repair failures and repeat affected checks. If separate agents are unavailable, use separate passes and state that review shared context. Show me the actual experience and incorporate my corrections before customer use. Prepare any invitations or website changes; obtain explicit authorization before sending invitations or publishing. A build check is not customer participation. ### 4. Support real participation Use the approved channel and help run the experience. In a live session, let customers do the choosing and building; record their actual actions, words and revisions rather than narrating what they must have meant. On a website, inspect completed and abandoned journeys where that observation is available and permitted. For a client service, capture what the client accepted, rejected or changed alongside the resulting prototype. If customers have not yet participated, deliver the working experience and a precise ready-to-run handoff, then pause the learning claims. Do not invent submissions, simulate customers as replacements, or label internal test data customer evidence. Continue the analysis when actual contributions arrive. ### 5. Compare creations without flattening them Review each submission with its explanation, revisions and participant context. For a large collection, divide bounded groups among analysis agents with source references, a common extraction brief and a coverage record; reconcile only after the passes finish. Extract the job, proposed solution, priority choices, current workaround and any observed use. Link findings back to the actual contribution. Preserve unusual but consequential needs alongside recurring ones. Separate what customers built or said, behavior actually observed and our interpretation. A frequently requested feature in this group does not establish prevalence or willingness to pay. Compare needs across roles and settings; do not rank all submissions by visual polish or count several employees of one account as independent accounts. Deliver the working experience and its use instructions, accessible customer prototypes, a concise comparison and a few specific hypotheses for further testing. Recommend the next real task or behavior that would test each promising hypothesis. Let me choose what deserves follow-up, and revise the findings to reflect my corrections without changing the original customer contributions. 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.
View full AI instructions
Let customers prototype what they want from you.
What the AI will do
- Find customer frustrations and build an experience in which real customers can describe, make and revise what they wish you offered.
- Collect their prototypes, explanations and observed use, then compare what those contributions reveal.
What you can provide
- A product, service or customer problem to explore; a rough starting point is enough.
- Access to existing customer evidence and an approved way to involve actual customers.
Where you'll take part
- Choose the setting: a small live focus group, a website anyone can use, or an added service for high-value clients.
- Review the experience before customers enter, observe or host participation where useful, and choose which discoveries deserve a next test.
What you'll get
A working customer-prototyping experience, the participating customers’ creations and a source-linked comparison of what they wanted and why. If participation has not happened, you receive the tested experience ready to use, with that stage still open.
Activity context
A customer can ask for a better dashboard. Let them build one, and you can see what “better” means: the number they put first, the button they remove, the decision they want to make. This can be a handful of people building in front of you, an invitation on your website, or a useful extra service for important clients.
For the user
Bring the product or problem you want customers to rethink. The AI will investigate existing feedback, help you choose how people will participate and build the agreed experience. You will review it before use and make the few decisions that need your judgment; customers supply the actual ideas and reactions.
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
Help me give real customers an AI-assisted way to prototype what they want from us. Build the agreed experience, support actual participation and turn their contributions into useful product or service learning.
1. Find the problem and the people
Read what I supplied and identify the product, service or business area. Inspect and try access to customer support tickets, sales and renewal calls, interviews, account correspondence, relevant email, chat and WhatsApp messages, product feedback, usage records and existing prototypes. Search by product, account and recurring complaint to find concrete jobs people struggle to do, workarounds they use and ideas they have already suggested. Use meeting invitations, interview rosters and account roles to distinguish buyers, daily users and people implementing the service. Cite the evidence behind those distinctions; do not turn our team's assumptions into customer views.
Summarize a promising area for customers to explore without prescribing their preferred solution. Ask one focused question at a time to settle consequential gaps. If records are inaccessible, inspect available connection or export options first, then help me supply permitted examples or use a clearly limited starting hypothesis. Access to a smaller record narrows what we know; it does not prevent real customers from creating something new.
2. Choose how customers will create
Explain these three concrete settings and recommend one for the question and participants:
- A small live focus group, in person or remote: customers build while we observe, explain their choices and revise in the session.
- An experience on our website: anyone in the intended audience can create something and submit it with an explanation. Participation is self-selected; preserve that fact when interpreting patterns.
- An added service for high-value clients: help an individual client prototype a workflow, service or tool that fits their situation, capturing both the useful deliverable and what we learn.
Let me choose or refine the setting. Establish what participants can make, the intended time commitment and the information they need, keeping room for surprises. A prototype might be a screen, a workflow, a service interaction, a sample report or a clickable miniature of an idea. Clarify what is illustrative and what will actually work. A free-text suggestion form alone is not the promised prototyping experience.
Inspect the current AI, coding, hosting, file-generation and collaboration capabilities. Use available tools to build the chosen route. If a website cannot be deployed here, prepare and test the deployable version and investigate the precise supported handoff; offer a working session-based version if we agree that scope. Do not silently replace a public participation experience with a document of instructions.
3. Build the whole participant journey
Create a welcoming opening that asks about a concrete occasion when the participant needed something better. Let them describe it in ordinary language or supply a rough sketch or example. Have the participant-facing AI ask the next useful question, produce a visible prototype, invite the participant to change it and keep iterating until they say it represents what they want. Do not lead everyone toward our preferred feature.
Build a way to preserve the prototype, its important revisions, the participant's explanation and the task it is meant to solve. Ask what matters most, what they removed or changed, how they solve the problem today and what they would try with the result. Let participants inspect what they are submitting and understand whether it is private to us or visible to others. Collect only the account or role context needed for the agreed learning question. State that contributing an idea does not promise that we will deliver it.
For a live group, prepare the facilitator's opening and observation sheet and a reliable way for each person to save their own work. For a website, build the creation, preview, revision and submission path, plus a usable way for us to retrieve contributions. For a premium service, make each client's output usable in its agreed form and keep separate clients' work separate.
Where useful, give one bounded agent the build specification and another the participant journey to test, using the actual prototype and relevant audience evidence. Keep the reviewer free of the builder's explanation of how the interface is supposed to work. Check that a new participant can start, create, revise and retrieve the result. Repair failures and repeat affected checks. If separate agents are unavailable, use separate passes and state that review shared context.
Show me the actual experience and incorporate my corrections before customer use. Prepare any invitations or website changes; obtain explicit authorization before sending invitations or publishing. A build check is not customer participation.
4. Support real participation
Use the approved channel and help run the experience. In a live session, let customers do the choosing and building; record their actual actions, words and revisions rather than narrating what they must have meant. On a website, inspect completed and abandoned journeys where that observation is available and permitted. For a client service, capture what the client accepted, rejected or changed alongside the resulting prototype.
If customers have not yet participated, deliver the working experience and a precise ready-to-run handoff, then pause the learning claims. Do not invent submissions, simulate customers as replacements, or label internal test data customer evidence. Continue the analysis when actual contributions arrive.
5. Compare creations without flattening them
Review each submission with its explanation, revisions and participant context. For a large collection, divide bounded groups among analysis agents with source references, a common extraction brief and a coverage record; reconcile only after the passes finish. Extract the job, proposed solution, priority choices, current workaround and any observed use. Link findings back to the actual contribution. Preserve unusual but consequential needs alongside recurring ones.
Separate what customers built or said, behavior actually observed and our interpretation. A frequently requested feature in this group does not establish prevalence or willingness to pay. Compare needs across roles and settings; do not rank all submissions by visual polish or count several employees of one account as independent accounts.
Deliver the working experience and its use instructions, accessible customer prototypes, a concise comparison and a few specific hypotheses for further testing. Recommend the next real task or behavior that would test each promising hypothesis. Let me choose what deserves follow-up, and revise the findings to reflect my corrections without changing the original customer contributions.
Done when
You have a working, tested way for customers to make and revise prototypes. After actual participation, you also have their creations, explanations and a comparison that distinguishes observed evidence from your team’s interpretations. If participation or deployment remains unavailable, that unfinished stage is explicit.
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.
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.