aioff.
中文
Product design
PRODUCT DESIGN·5 min

Figma Specs: keep the design and the reason behind it together

Figma Specs is a collaborative document on the design canvas. Teams can bring requirements, screens and discussion together, then pass that context to developers or AI.

Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.

01
DESIGN QUESTIONIntermediate

How should a document distinguish open questions from agreed requirements?

Scenario: You are designing a requirements document on a canvas. Three comments sit beside a registration screen: “Could we add a waiting list?”, “Make the button green” and “Block submission when full.” Only the last one has been agreed by the team.

  1. Your task: Design how readers distinguish suggestions, open questions and current decisions. Do not rely on color alone.
  2. Cases to consider: A decision changes; the design is updated but the text is not; an AI comment summary turns a suggestion into a firm rule.
  3. Deliver: A short information layout, interactions for two state changes, and a check before handing work to a developer.
  4. Validation example: Ask a new colleague what happens when capacity is reached. Explain how you would discover that they read outdated or unconfirmed information. This is a proposed design, not a claim that Figma provides dedicated approval states.
Explore the reasoning
  1. Separate what each piece of content is for. Keep ideas available, but distinguish them from decisions that can be implemented. An owner and update time are more reliable than color alone.
  2. Show changes as differences that need a decision. If the screen and text disagree, identify the conflict and ask the owner which to keep. A later timestamp does not automatically mean correct.
  3. Keep uncertainty in AI summaries. Unresolved questions should remain questions. Have a person confirm them before they enter an implementation checklist. Less copying should not remove judgment.
  4. Check whether readers can act on the document. Give a colleague mixed old and new material. Observe whether they find the current decision and screen, and record whether confusion comes from status, placement or wording.
02
DESIGN QUESTIONIntermediate

How can an AI handoff include enough context without mixing in discarded plans?

Scenario: A file contains three registration proposals, two rounds of discussion and an old flow diagram. The current task is to implement only proposal B’s full-capacity message.

  1. Problem: Let a user choose the handoff material without missing a required rule or treating an abandoned proposal as a requirement.
  2. Example materials: Proposal B’s screen, the capacity rule, an API-error list, proposal A’s old wording and an undecided waiting-list idea.
  3. Design: Choose materials, check missing items and confirm the scope being sent. Explain what happens if the user cannot open a linked item.
  4. Deliver: A handoff preview with explanatory text. Explain how to check that the recipient knows what to do and what is outside the current task.
Explore the reasoning
  1. Start with the task’s necessary material. This task needs the full-capacity screen, trigger and message. Exclude waiting-list exploration explicitly; nearby content is not automatically relevant.
  2. Preview what can actually be read. Show each item’s name, purpose and version information. A broken or inaccessible link is a missing item, not a successful read merely because it was selected.
  3. Ask the user to confirm the scope. State both the included behavior and what is currently excluded, so the recipient does not expand the task.
  4. Validate by asking for a restatement. Have the recipient list the trigger, expected interface and remaining questions, then compare these with the confirmed checklist. The goal is complete relevant information, not the largest amount of information.