Back to Details

to-questionnaire

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Turn something the user can't answer alone into a questionnaire — a Markdown document they hand to one person to fill in async, or fill out together over a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
Grill the send, not the subject. Interview the user only about the send, which they can always answer: who it goes to, and what they need back. The questions in the document then target the gap between what the recipient knows and what the user needs.
  1. Who is it going to? Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
  2. What do you need back? Ask, in one exchange, the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
  3. Write the questionnaire. Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to 
    to-questionnaire-<slug>.md
    in the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
将用户无法独自解决的问题转化为一份问卷——这是一份Markdown文档，用户可以交给某个人异步填写，或者在会议中共同填写。接收者掌握着用户所欠缺的知识，而问卷的作用就是将这些知识提取出来。
聚焦发送方，而非问题本身。 只针对「发送」相关的问题询问用户，这些问题他们总能回答：问卷发给谁，以及他们需要得到什么反馈。文档中的问题则要瞄准接收者所知信息与用户需求之间的差距。
  1. 问卷发给谁？ 通过一次沟通，询问接收者的角色、专业能力以及与用户的关系。这将确定问卷的语气以及需要包含的背景信息。当你明确接收者是谁，以及他们拥有哪些用户不具备的知识时，这一步完成。
  2. 你需要得到什么反馈？ 通过一次沟通，询问用户无法独自解决、需要从对方获取的具体决策事项或事实信息。当你得到一份明确的列表，清楚用户最终需要能够完成哪些事或做出哪些决策时，这一步完成。
  3. 撰写问卷。 根据步骤1-2中确定的信息差距草拟问题，遵循下方的文档结构。将问卷写入当前目录下的
    to-questionnaire-<slug>.md
    文件（slug由主题生成），并报告文件路径。当文件存在且步骤2中用户列出的每一项需求都有对应的问题覆盖时，这一步完成。

Document structure

文档结构

Frame the document as a discovery questionnaire: the user lacks context, the recipient holds it. Order questions most-important-first — async means you may only get one pass — and group them under 
##
headings by theme once there are more than a handful. Write it using the template below.
<questionnaire-template>
将文档定位为一份探索性问卷：用户缺乏相关背景，而接收者掌握这些信息。按重要性从高到低排列问题——异步场景下你可能只有一次获取答案的机会——当问题数量较多时，按主题用
##
标题进行分组。请使用下方模板撰写问卷。
<questionnaire-template>

<Questionnaire title>

<问卷标题>

Purpose: why this questionnaire exists and the decision riding on it.
From: <the user> — To: <the recipient> — How your answers will be used: <where they go>
目的： 说明这份问卷的存在原因以及依赖它的决策事项。
发起方： <用户> —— 接收方： <接收者> —— 你的回答用途： <回答去向>

Context

背景信息

One paragraph orienting a recipient who wasn't in the user's head. Enough to answer well, not a page.
用一段文字帮助接收者了解用户的处境，无需长篇大论，足够让对方给出准确回答即可。

How to answer

作答说明

Deadline and rough effort. Partial answers and "I don't know" are useful — flag anything you're unsure of rather than skipping it.
说明截止时间和大致所需精力。部分回答和“我不知道”同样有用——若有不确定的内容，请标注出来，不要跳过。

<Theme heading>

<主题标题>

One 
##
section per theme. Under each, its questions, most-important-first. Every question is one idea — never compound — with an answer stub directly beneath, and a one-line why this matters only where the question could be misread or invite a throwaway answer.
<question-example>
每个主题对应一个
##
章节。在每个章节下，按重要性从高到低列出问题。每个问题只包含一个核心观点——切勿设置复合问题——问题下方直接预留回答区域；仅当问题可能被误解或可能得到敷衍回答时，添加一行“问题的重要性”说明。
<question-example>

What load is the system expected to handle at launch?

系统预计在上线时需要承载多大负载？

Why this matters: it decides whether we provision for burst traffic now or defer it.
</question-example>
问题的重要性：这将决定我们是现在就为突发流量做好准备，还是推迟该工作。
</question-example>

Anything else?

其他补充？

A closing catch-all: anything we didn't ask that we should know?
</questionnaire-template>
最后设置一个兜底问题：有没有我们没问到但应该了解的信息？
</questionnaire-template>