# AI Assistant Interface Copy Review Workflow in Figma > Audit prompts, generated-answer states, warnings, and recovery copy in Figma so an AI assistant communicates its limits clearly. - Canonical page: https://www.hypermatic.com/articles/copydoc-ai-assistant-interface-copy-review-workflow-in-figma/ - Published: 2026-08-14T00:00:00.000Z - Updated: 2026-08-14T00:00:00.000Z AI assistant interfaces multiply copy faster than most product teams expect. There is the empty composer, suggested prompts, model status, streaming response, citations, feedback controls, usage limits, safety refusals, tool approvals, connection failures, and the moment an answer is confidently wrong. Reviewing the happy-path chat screen is not enough. The product's trustworthiness often depends on the language around the answer. [CopyDoc](/copydoc/) can export, organize, update, and re-import text from Figma so content designers, product owners, safety reviewers, support, and legal can inspect the system as a whole. ## Inventory the conversation states Start with an interaction map rather than a list of polished screens: - first-use and returning empty states - prompt entry, attachment, and permission states - generating, paused, stopped, and completed responses - citations or source availability - clarification questions - partial success after a tool failure - rate, plan, or context limits - refusal and sensitive-topic handling - thumbs-up, thumbs-down, report, and correction flows - history deletion and data-use controls Export the strings with stable IDs and state labels. Similar phrases such as “Try again,” “Regenerate,” and “Continue” may perform very different actions; the inventory should keep that context visible. The nearby [error message and empty state workflow](/articles/copydoc-error-message-and-empty-state-review-workflow-in-figma/) provides general recovery principles. This workflow is narrower because conversational systems also need to represent uncertainty, sources, tool actions, and the boundary between generated content and confirmed system state. ## Separate capability from confidence Review every sentence that describes what the assistant can do. Replace vague promises with observable behavior. Weak: > I know everything about your workspace. Better: > I can search the files you select for this conversation. The exact wording depends on the product, but the test is consistent: can the interface substantiate the claim in the current state? Do the same for response certainty. A polished answer should not visually or verbally imply verification when it is generated from incomplete context. Define language for sourced answers, unsourced suggestions, estimates, and actions that have actually completed. ## Review verbs as product contracts Buttons and status labels around AI tools carry operational meaning. “Send,” “Run,” “Apply,” “Publish,” and “Approve” are not interchangeable. For each action, record: - what changes - whether the change is reversible - whether another person or external system is affected - when confirmation is required - what success and partial failure look like A status should not say “Done” when the assistant merely drafted content or queued an action. Copy needs to distinguish recommendation, preview, execution, and verified result. ## Design useful failure and refusal states Generic copy—“I can't help with that”—often leaves the user unsure whether the issue is safety, permissions, missing context, or a temporary error. Create distinct patterns for: - unsupported request - missing access - unavailable source - temporary generation failure - action requiring approval - sensitive or disallowed request - answer that needs professional or human review Explain what can be shared, changed, retried, or escalated without revealing security-sensitive rules. Support should review these states because they will see where users misinterpret them. ## Include long and adversarial content in layout QA AI output is not tidy placeholder copy. Test: - long URLs and filenames - nested lists and code blocks - multiple citations - mixed languages and right-to-left text - a one-word answer and a very long answer - unsafe or malformed user input displayed back in the UI - missing titles, avatars, or source metadata Text should wrap without hiding controls or blurring the boundary between user input, generated output, and quoted source material. Localized status labels must fit during streaming and error states, not only on the finished response. For large review batches, [CopyDoc](/copydoc/) can move the text into a spreadsheet where owners, risk level, status, and approved wording sit beside each stable string. Re-import only after decisions are resolved; do not let the spreadsheet become an untracked parallel product. ## Create a claims and actions review Before release, ask reviewers to inspect two focused lists. The claims list contains every statement about privacy, retention, model capability, source access, security, and accuracy. The actions list contains every label that implies something was changed, sent, saved, deleted, or published. These lists deserve stronger review than conversational flourishes. They shape consent and user expectations. For broader terminology consistency, pair this with the [Figma terminology audit workflow](/articles/copydoc-figma-terminology-audit-workflow/). ## Release checklist - Every conversation state has an identified string owner. - Capability claims match the assistant's actual access and behavior. - Sourced, generated, estimated, and verified information are distinguishable. - Action verbs accurately describe previews, approvals, execution, and completion. - Permission, safety, and technical failures have different recovery guidance. - Long, localized, mixed-direction, and malformed content has been tested in layouts. - Privacy, retention, and data-use language has appropriate review. - Support can identify each state from the wording a user will quote. The goal is not to make an assistant sound more human. It is to make the interface honest about what the system knows, what it is doing, and what the user can do next.