这件事是这么发生的
v4 那一版，画的时候觉得"一个项目页，这些都该有"——别的平台有，看着也完整。到了 v5，整理的人一看，说不清这几块到底是给谁用的、解决什么问题的，就删了。
删了以后也没人正式宣布"这几块不做了"。结果就是：现在文档里这几块还留着，谁翻到都会以为"这是已经定好的"。
反过来你再看"连接状态清单"（就是显示哪个数据源连了、哪个没连的那块）。这个东西从 v2 一直活到 v5，五个版本没人想砍它。为什么？因为它一句话就能说清：让买家一眼看出这个项目的数据是真的。
先说清楚我们现在的处境，不然看什么都会飘。
这个产品你已经想了一年多：让认真做产品的团队能发币拿钱，让买家不用再赌空气币。想法很清楚了，界面也画了五个版本，流程图画了一套，元素登记了 501 条。
但我上次问你"功能做完没有"，你说不知道。这个"不知道"不是你的问题，是我们东西的放法有问题。 我们把所有信息按"文件"堆着：需求在一份、界面在一份、数据在一份、流程图在另一份。谁也没法从这堆文件里看出"整件事做完没有"。
接下来我按真正做产品的顺序，一步步过一遍。每一步我都会告诉你三件事：这一步实际在干什么、我们在这件事上做到哪了、以及现在缺的是哪一块。你不用记，看完你就知道该拍哪几个板。
做软件最常见的死法，不是技术做不到，是做了一堆没人要的东西。而"没人要"这个事，在做的过程里是看不出来的 —— 每一块单看都挺合理。
怎么才能看出来？只有一个办法：回到"我们本来想让谁得到什么"。
举个我们自己的例子。你之前问过：为什么线框图里有"项目状态总览""时间线""关于和 FAQ""相似项目"这些东西，后来又没了？
v4 那一版，画的时候觉得"一个项目页，这些都该有"——别的平台有，看着也完整。到了 v5，整理的人一看，说不清这几块到底是给谁用的、解决什么问题的，就删了。
删了以后也没人正式宣布"这几块不做了"。结果就是：现在文档里这几块还留着，谁翻到都会以为"这是已经定好的"。
反过来你再看"连接状态清单"（就是显示哪个数据源连了、哪个没连的那块）。这个东西从 v2 一直活到 v5，五个版本没人想砍它。为什么？因为它一句话就能说清：让买家一眼看出这个项目的数据是真的。
这就是区别。说不清给谁用的，做的时候靠感觉、砍的时候也靠感觉；说得清的，从来到走都很稳。
所以我们第一步做的事，是把"目标"写下来。一条目标必须能念成：谁，在什么情况下，得到什么结果。三个缺一个都不算。
我按你的产品归纳了九条。你逐条看，不同意的直接说。
| 编号 | 目标 | 它管着产品里的哪些地方 |
|---|---|---|
| G-01 | 任何人打开网站，不用连钱包就能看懂这是个什么项目，并且能找到他想看的 | 首页、项目页、落地页、顶部导航 |
| G-02 | 买家看项目时，能一眼看出这项目的数据是真的，不用只信项目方自己说 | 连接状态、验证徽章、验证页、季度报告 |
| G-03 | 买家投钱之后能确信，钱不是一次性给项目方的，是按里程碑一段段放，没做到就拿不到 | 发币向导第⑤步、项目页里程碑区、持仓页放款 |
| G-04 | 项目方愿意把项目页当自己的官网发出去 | 项目头、主视觉图、团队与社交链接 |
| G-05 | 买家能用最少的步骤把钱换成币，并且随时知道现在什么价 | 买入面板、价格、K 线、成交表 |
| G-06 | 买家能发现值得看的项目，而不是被塞一屏垃圾 | 首页热门条、验证榜、筛选、落地页精选 |
| G-07 | 项目方从"想发币"到"发出去"不会中途放弃 | 发币向导七步、右侧的"还差什么"清单 |
| G-08 | 买家和项目方随时能查自己的钱和身份 | 持仓页、验证页、钱包连接 |
| G-09 | 第一次来的人能立刻明白我们和别的发币平台不一样在哪 | 落地页 |
这里面我要单独提一下 G-09。这条是我最没把握的：它现在只落在"落地页"上，而落地页你到底做不做，还没定。如果落地页不做，这条目标就没地方落了 —— 那要么换个地方承载它，要么承认这条不重要。这个得你来定，我替不了。
另外还有两件事，我一直当成"事实"在用，但其实只是我的猜测，也一并交给你判断：
你说"串不起来"，根子在这里。
你脑子里装的是页面：首页、项目页、发币页、持仓页、验证页。但页面不是产品本身，页面只是东西露面的地方。
打个比方。一个超市的"页面"是入口、货架、收银台、仓库。可超市真正在管的东西是：商品、库存、订单、会员、优惠券。一件商品会在货架、收银台、仓库三个地方出现。如果你只按页面管，早晚会出现"货架上的数跟仓库里的数对不上"。
我们这儿一模一样：页面只有六个，但真正的东西只有十样，它们会在页面之间来回跑。
押金这东西同时出现在两个地方 —— 发币向导第⑦步（项目方交押金）和持仓页（项目方看押金退到哪了）。
如果按页面想，你会先在向导里做一个押金输入框，再在持仓页做一个押金进度条，两处各想各的。然后两边的规则、数字、文案就会不一样。这不是假设，我们真的已经出现了：押金比例在一处写 5%，另一处写 10%，没人知道哪个对。
如果按"东西"想，押金只有一份定义：金额等于募资额乘比例，状态就四个（待缴、已缴、分批退还、罚没）。两个页面只是展示它的不同侧面。那就根本不会有两个版本。
把十样东西都列出来是这样：项目、代币、验证凭证、发售、里程碑、季度报告、押金、持仓、经营指标、放款批次。
完整的十样东西是这样（左边是它有哪些信息，中间是一生经历哪些状态，右边是谁把它创建出来的）：
| 东西 | 它身上有哪些信息 | 一生经历哪些状态 | 谁创建的 |
|---|---|---|---|
| 项目 | 名称、代币代号、封面图、logo、一句话简介、社交链接、画廊、品类标签 | 草稿 → 验证中 → 发售中 → 已毕业或失败 → 进入财报季 | 项目方，在发币向导第①步填 |
| 代币 | 固定 10 亿枚、18 位小数、发售量百分比、建池预留百分比、合约地址 | 未发 → 已发 → 建池 → 流动性销毁 | 项目方，用他自己的钱包发 |
| 验证凭证 | 层级、数据源、证明时间、证明哈希、覆盖月数 | 待接入 → 已验证 → 复核中 → 降级 → 过期 | 项目方发起，系统出证 |
| 发售 | 模式、时长、清算价下限、毕业线、单人限额、已募金额 | 创建 → 进行中 → 达标或未达标 → 毕业或失败 | 项目方设定，系统计算 |
| 里程碑 | 名称、衡量什么指标、数据从哪来、目标值、解锁比例、时间窗口 | 未达成 → 进行中 → 已达成并放款 → 窗口过期 → 锁死 | 项目方填，系统判定 |
| 季度报告 | 季度、营收、走势、报告期、复验结果 | 未开始 → 已出证 → 已复验 → 断连 | 项目方提交，系统核验 |
| 押金 | 金额、构成、已退比例、达标条件、罚没去向 | 待缴 → 已缴 → 分批退还 → 罚没 | 系统计算 |
| 持仓 | 数量、成本、现值、能否领取 | 拍卖中 → 已毕业 → 可领取 → 已领取 | 系统从链上读 |
| 经营指标 | 月活、日活、留存、下载量、代码提交数、收入 | 未验证 → 已验证 → 复核中 | zkTLS 出证 |
| 放款批次 | 比例、前置条件、时间窗、提现费 | 冻结 → 可提 → 已提 | 系统 |
其中"验证凭证"和"里程碑"这两样，是我们跟别家最不一样的地方，值得说细一点。
验证凭证：它有层级（L1/L2/L3）、数据源（Stripe？GitHub？App Store？）、证明时间、证明哈希、覆盖的月数。它会经历"待接入 → 已验证 → 复核中 → 降级 → 过期"。
注意最后两个状态：它会降级，也会过期。这一点直接决定了界面长什么样 —— 因为数据是会变老的，所以徽章不能只有"有/没有"两种，必须有第三种"以前验证过但现在不算数了"。这就是为什么我们的徽章是三个（◆已验证、◇流量已验证、○未验证），而不是两个。
里程碑：属性是名称、衡量什么指标、数据从哪来、目标值多少、达成后能放多少比例的钱、时间窗口多长。
它的状态是"未达成 → 进行中 → 已达成（放款）→ 窗口过期 → 锁死"。这里有个大坑："窗口过期"之后该怎么办，我们问了四个版本都没定。是钱不给了（锁死）？还是再给一个窗口（顺延）？还是退给买家？
这个问题不定，下面这些东西全都动不了：项目页里程碑那块怎么显示、合约里的放款逻辑怎么写、押金退不退。如果你只从这份东西里拍一个板，我建议先拍这个。
想清楚东西之后，就该写"系统要提供哪些能力"了。写这个只有一条要求：这句话得能被验收。
什么叫能被验收？做完之后，我能指着屏幕说"对，做到了"或者"没做到"。
对比一下你就明白：
"要做一个验证功能。" —— 做到什么程度算做到？连没连？显示什么？谁去点？全不知道。这种话给开发，他只能猜。
"项目方能把 X、GitHub、App Store、Stripe 这些账号连上并把数据出证；买家在项目页能看到每个数据源是已连接还是没连；没连的那一行给项目方一个『连接』按钮。" —— 这句话一写出来，做完了没有、谁看得见、看得见什么，全清楚了。
写的时候有个窍门：从"东西"的状态变化倒推。每样东西从一个状态变到下一个状态，中间必然需要有人操作或者系统判断，那个操作就是一条需求。押金从"待缴"到"已缴"，就需要一条"交押金"的需求；从"已缴"到"分批退还"，就需要一条"按季度达标情况退还"的需求。
我们最后写出来 47 条，每条都编了号（R-01 到 R-47），并且挂在前面九条目标下面。编号不是形式主义 —— 有了编号，以后讨论就是"R-03 怎么改"，而不是"那个红框里的东西"，一屋子人各说各的。
R-03，数据源连接与可信度信号（挂在 G-02 下面）
给项目方用，也给买家看。项目方能连上 X、GitHub、App Store、Stripe 这些数据源并出证；买家在项目页能看到每个数据源是已连接、待接入还是未连接；没连的那一行给项目方一个"连接"按钮。
做完的标准是：三种状态都显示；每一行都写明"这个数据源供什么指标"，不能只写个名字；买家看不到"连接"按钮；一个都没连的时候整块变灰并给引导；连接成功后项目页顶部的徽章跟着点亮。
还没定的地方：数据源到底几个。现在字典里写 8 个、项目页线稿画 6 行、发币向导画 5 行，三处对不上。我的建议是首期就做 5 个（GitHub、App Store、X、GA4、Stripe），其余标"即将支持"。理由是每多一个数据源，接入和出证的成本都要加一份，首期没必要摊这么大。
R-06，里程碑与放款（挂在 G-03 下面）
项目方在发币向导第⑤步能设置最多五条里程碑，每条写清衡量什么指标、数据从哪来、目标值多少、达成后放多少比例的钱、时间窗口多长。买家在项目页能看到每条里程碑的实时进度。
做完的标准是：每条里程碑都写明"衡量什么加数据从哪来"，而不是只给一个百分比（这是 Michael 的意见里明确点出来的）；有实时进度数值，不只是一根进度条；有时间窗口；比例加起来必须等于 100% 才能进下一步。
还没定的：就是上面说的"没达标怎么办"，卡了四个版本那个。
R-11，买入和卖出（挂在 G-05 下面）
买家连上钱包之后，能在项目页右侧那个常驻面板里买入或卖出，看到折算后的数量和手续费；没连钱包的时候，主按钮显示"连接钱包"而不是"买入"。
做完的标准是：三种情况下面板形态不同（拍卖中是出价面板、曲线阶段有单人限额提示、已上线才是普通的买卖）；展示 0.3% 交易费怎么拆的（平台、项目方、回购）；金额为零或者超过余额的时候按钮变灰，并且说明为什么。
还没定的：滑点默认值是多少，以及"未验证项目每人限 500 美元"这个数到底算不算数 —— 字典里是这么写的，但没人正式拍过。
界面是一块一块的，但人是按顺序用的。这一步就是把顺序写下来：他先看到什么，点一下之后看到什么，出错的时候看到什么。
写的时候用一个固定句式，出自 About Face 那本书（你下载的第 1 章就是讲这个的）：某某人，在什么情况下，想干什么，希望怎么完成。 用这个句式，你会自然地把"情况"和"期望"都写出来，而不是只写"点了按钮"。
这里最容易犯的错，是只写顺利的那条路。用户来了、填完、成功 —— 完美的剧本。真实的用户会：填一半跑了、余额不够、超时了、项目没达标要退款。这些岔路不写出来，界面上就会出现"卡住没反应"的死角。
拍卖没达到毕业线怎么办 —— 这件事流程图里只写了"达标 → 毕业"，没写"没达标"。结果三件事全乱了：买家不知道自己的钱退不退（这是最影响他敢不敢出价的事）；界面上没对应的文案；开发不知道要不要写退款这段逻辑。
其实文档里写了处理方式（全额退款、代币销毁、不开池）。但它没被放进"人怎么走"这条线里，所以界面上就没人为它负责。岔路没画，等于功能漏做。
他一开始只是好奇"我这产品能不能发币"，所以首页那个 Launch 按钮不该一上来就逼他连钱包，先让他看。点进去以后是七步向导，右边一直挂着一张"还差什么"的清单，他随时知道自己在哪。
第①步填资料（名称、代号、logo、封面、简介、社交链接）。第②步连数据源，可以整步跳过 —— 这一步一定要能跳，不能逼人当场做完验证。第③步选怎么卖（拍卖还是绑定曲线）和参数。第④步填版税的收款人，最多八个。第⑤步设置里程碑，最多五条，也可以直接选"毕业全额释放"。第⑥步验证，也能跳。第⑦步把所有信息核一遍、交押金、签名发币。
这条路上有三个岔口必须处理：
他先是不带钱包地翻项目页：连接状态、业务指标、里程碑、团队，这些都不需要连钱包就能看。看完觉得行，去右侧价格卡下面输金额，系统给他折算数量、滑点、手续费。确认，签名，成交，提示，去持仓页看。
这条路里最要命的一句文案，是拍卖没达标时候的说明："未达标将全额退款，代币销毁，不开池"。这句话写不写，直接决定他敢不敢出价。现在这句话不在界面上，只在文档里。
还有一个容易漏的：他买的是未验证的项目。界面要提前告诉他"此项目未验证，单人限额 500 美元"。等买完了才发现有限额，人会觉得自己被坑了。
| 哪里打架 | 两个数字 | 我建议怎么定，为什么 |
|---|---|---|
| 拍卖毕业线 | 产品定稿里是 20 万美元，但老线稿里还写着 10 万 | 按 20 万。定稿是最后拍过的，老线稿只是没来得及改 |
| 押金比例 | 一处 5%，一处 10% | 按 5%。募资额本来就小，抽 10% 会把项目方吓走 |
| 里程碑放款比例 | 30/30/40 和 10/30/60 两个版本 | 按 30/30/40。前两笔等额，项目方的进度压力比较均匀；10/30/60 会让最后一笔太重，反而拖 |
| 曲线单人限额 | 字典里写 500 美元，但没人拍过 | 建议按募资规模的 2% 动态算，而不是一个固定数字。固定数字在大小项目上都不合适 |
| 平台币 | 三种说法（VFY / 0928 方案 / 双角色） | 这个得你先定"到底有没有平台币"，别的都是它的下游 |
前面四步都是"想"，从这一步开始才是"画"。但画之前有个问题要先解决：你怎么知道自己把一块界面说清楚了？
我们踩过这个坑，所以你抱怨"对按钮很模糊"我完全理解。后来我总结出：一块界面要回答十二件事才算说清楚。少答一件，开发就会自己编一件。
这十二件事是：这块叫什么、给谁看、替他解决什么、服务哪条需求、要显示哪些数据、什么条件下看得见、空的时候什么样、主按钮点了发生什么、成功失败给什么提示、数字的单位和精度、怎么埋点、怎么算做完。
光看这个清单你可能会觉得"这不是废话吗"。所以我直接拿一块给你看，你就知道答全和答不全的区别在哪。
它长在项目页左边，一直是常驻的。
给谁看：买家看，只读；项目方也能看，但那上面有"连接"按钮，只有他自己看得到。
它解决什么：让买家判断这家项目的数据是不是真的。就这一句，再没有别的目的。
要显示的数据（这是你最想要的那张表，我一项一项列）：
| 编号 | 显示什么 | 数据从哪来 | 谁来写 | 没有数据的时候显示什么 |
|---|---|---|---|---|
| P153 | 数据源名字（GitHub、App Store…） | 平台设计 | 设计 | 不需要，是固定文案 |
| P154/155/156 | 已连接 / 未连接 / 待接入三个状态 | zkTLS 出的证明 | 系统 | 不需要，它本身就是状态 |
| P157 | "连接"按钮 | 平台设计 | 设计 | 不需要；只有项目方本人能看到这个按钮 |
| P158 | 这个数据源供什么指标 | 平台设计 | 设计 | 不需要，固定文案 |
| P159 | 证明时间（比如"证于 10-01"） | zkTLS 出的证明 | 系统 | 没连的时候显示一个短横 |
什么条件下看得见：项目页永远显示。一个数据源都没连的时候整块变灰，并给一个"去验证"的引导。
四种不正常的情况：一个都没连 → 整块灰掉加引导；正在加载 → 每行一条骨架；出错 → 那一行标红并给重试；访客进来 → 看不到连接按钮。
按钮点了会怎样：点"连接"跳去验证流程，出证之后回来，那一行变成"已连接"并显示时间。
成功和失败提示：成功就是那行变已连接、显示时间、项目页头部徽章跟着亮；失败就在那一行里报错，写清原因，给重试。
边界和精度：数据源统一成五个；TLS 1.2 不兼容的时候走代理模式；证明时间的格式统一成"证于 月-日"。
怎么算做完：三种状态都齐；每行写明供什么指标；访客看不到连接按钮；未连接的行有引导；连上以后徽章同步点亮。
你对比一下：如果当初只写"做个连接状态显示"，上面这些一条都不会有。开发会自己猜几种状态、自己定文案、自己决定没连的时候显示什么 —— 然后你看到成品再说"不是这样"，返工。
项目页那十九块是完整的，可以直接开工。另外五个页面（首页、发币向导、持仓页、验证页、落地页）一共三十四块，只答了八件事，少了"给谁看""什么时候看得见""埋点"这三条。这三十四块现在还不能直接交给开发。要补齐我随时能做，大概两三天。
界面说清楚了，还得把上面每个数字的脾气摸清楚。只写"价格"三个字是不够的，得写四件事：长什么样、谁来填、能不能空着、空着显示什么。
前三件大家一般会写，第四件最容易出事。举个真的：价格没有数据的时候，如果显示"0"，买家会以为这币归零了；正确做法是显示一个短横并说明"还没建池"。同样一件事，两种显示方式，用户的理解完全相反。
看两个例子你就懂我在说什么。
价格。长什么样：美元，千分位，两位小数。谁来填：系统从链上读，没人填。能不能空：不能，没建池的时候走空态。空着显示什么：一个短横，加一句"还没建池"。最后一个选择是故意的 —— 绝不能显示 0。
里程碑的实时进度。长什么样：一根进度条加一个分数，比如"8,400 / 10,000 月活"。为什么要有数字：只有进度条的话，买家看不出还差多少。谁来填：系统在数据源出证之后自动算，不能让项目方自己填，否则这东西就没意义了。空着显示什么：如果数据源断了，显示"最后已知的数值加更新时间"，不要显示 0 —— 断连的时候显示 0，看的人会以为进度归零了。
我们 501 条界面元素全都登记了，"长什么样、谁填、能不能空"已经定了。"空着显示什么"这一列里还有一批是按规则推断出来的，需要你和开发过一遍。这份表在《元素台账 v2》那个 Excel 里。
顺便说一个我们已经在犯的错：表格的列名（比如"币种""持有数量"）曾经被当成"项目方要填的输入项"。它们其实是表头，不需要任何人填。这种错如果流到开发那里，他会去做一堆没人填的表单。
前面六步都是往前做，这一步是回头对账。对两件事：登记了的东西，界面上有没有地方放？界面上画了的东西，有没有数据定义？
这个动作看着笨，但它是唯一能机械地发现"漏了什么"的办法 —— 靠脑子想是想不出来的。
我们两头对完，查出 59 处问题。挑两个说。
第一处：六边形成就徽章。这个东西在我们的设计规范里写着"已定稿"，我们还专门为它写了三条动效规则，讨论了很久。但是翻遍五个版本的线框图 —— 一个都没画过。也就是说，我们花了不少功夫设计它，但它在界面上从来没有位置。
为什么会这样？因为它是在"讨论设计规范"的时候定下来的（当时在参考别的产品怎么做徽章），定完之后没人把它安排到具体页面上。补法就是把它安排到该在的地方：项目页头部的成就区、卡片角上。这个我已经做了，你在演示站上能看到。
第二处更严重：拍卖出价面板。v1 版本里明明画过它，四个输入框加一个计算器（最多花多少钱、最高接受单价、能买到多少）。但登记表里搜"出价"，只搜到一句"出价面板替换买入面板"。
这意味着什么？拍卖是我们两种卖币方式之一，买家实际掏钱就是在这个面板上操作的。画了但没定义，等于主力功能没有规格，开发根本下不了手。
怎么补：把 v1 画的那几个输入框一个个登记成元素，再给每个写清楚四件事。但这之前得先回答一个问题 —— 拍卖这块到底做不做？如果做，我就补；如果不做，这些就都能删掉。
很多人以为开发就是"按模块一个个做"，从第一个做到最后一个。专业做法不是这样，是按"一条完整的路"做：先把一条最细、但能从头走到尾的路做通，再做下一条。
为什么？因为"能走通"才叫完成。你把首页做得再漂亮，用户点了买入发现没反应，这个产品还是不能用。反过来，你把"项目方能发币、买家能看到、买家能买到"这条最细的路做通了，产品就已经能用了，剩下的都是加厚。
这个做法出自 User Story Mapping（那本书的作者原文你下载了）。说白了就是：把所有功能排成一张地图，横着切一刀，那一刀就是你的第一个版本。
如果让我切，我会这么切：
| 这一段要做什么 | 做到什么程度 |
|---|---|
| 顶部导航 | 能连钱包，能进发币流程 |
| 发币向导七步 | 能填完、能签名、能把币发出去。验证和里程碑这两步可以先跳过 |
| 首页和项目卡片 | 刚发出来的项目能出现在列表里 |
| 项目页（精简版） | 能看到项目头、价格、买入面板 |
| 买入面板 | 能真的买成功，成交出现在活动表里 |
| 持仓页（精简版） | 买完能在这里看到自己的持仓 |
这一段故意不做的东西：验证和出证、里程碑和放款、押金、拍卖模式、季度报告、行情模式、大户榜、落地页。
为什么先不做？它们都是"加厚"，不是"能不能用"。而且验证和里程碑恰好正是还没拍板的部分 —— 先做能做的，把不能做的留到决定之后再动手。
什么算这一段做通了？找一个没用过这产品的人，给他网址，十分钟内他能自己完成：连上钱包、发一个测试币、在首页看到它、换另一个账号把它买下来、在持仓页看到持仓。全程你不在旁边说话。
最后说一件我们已经在吃亏的事：改东西的时候没有固定顺序。
我们现在文档里有五处数字打架，根子都在这里 —— 有人改了产品定稿，有人改了线稿，有人改了流程图，三份各改各的，最后谁也不知道哪个是准的。比如毕业线，定稿已经改成 20 万了，但老线稿还写着 10 万。
正确顺序应该是这样，一步都不能跳：先改需求编号那条，再改对应界面的说明，再改数据定义，最后改验收标准。改完跑一次对账（第七章那个），看有没有产生新的漏项。而且所有文档必须同一时间一起改，不许"先改线稿、文档下次再说"。
拿一个真实例子走一遍。假设你现在决定"拍卖毕业线改成 20 万美元"：
这就是"改一次、全对齐"的动作。如果只改一处，就一定留下打架的数字。这正是我们现在那五处冲突的由来。
你这次放进来的资料我一份份读完了：官方的免费章节、还有二十一篇网友的读书笔记。读完以后我拿它们对着我们的东西逐条比，找出十三件我们压根没想到或者想到了没做的事。这一节就是这十三件。
我按"这事有多要紧"排的序，不是按书排的。
《点石成金》整本书有一章讲这个，NN/g 那篇《可用性测试 101》（你下载了）也是讲这个。它的说法很朴素：想知道一个东西好不好用，就找几个人来用，你在旁边看，记下他们在哪卡住。
关键在"几个人"—— 书里说三到五个人就够，不用多。因为同一个问题，第三个人就会再犯一次。而且这事儿要早做、反复做，一周一次都行，比攒三个月做一次大测试有用得多。
我们在这件事上是零。五次线稿评审、四轮文档审计，全是我们自己在看自己。这不是一回事 —— 我们看的是"画得对不对"，用户看的是"我能不能用"。
书里还有一句我必须抄给你：不要用焦点小组代替可用性测试。 焦点小组是问人"你觉得这个怎么样"，人会客气、会猜、会替你想；可用性测试是给人一个任务、看他做，做不出来就是做不出来。
我们分了四种角色：访客、买家、项目方、平台运营。这是"身份"，不是"人"。
About Face 那本书里，这一步叫"人物模型"（persona）—— 它要求你把角色写成一个个具体的人：他叫什么、干这行几年、用什么设备、最怕什么、他会怎么读我们这页。为什么非要具体到人？因为抽象的"买家"没法让你做取舍，具体的"老王"可以。
举个例子。如果我们的买家画像是"做了三年合约的老手，只看数据和链接"，那界面上所有解释性文案都可以删掉，徽章就只留图标。如果画像是"被空气币坑过两次的普通人，看不懂 zkTLS"，那每个徽章都必须配一句人话，验证页要写得像说明书。这两种设计完全不一样，而我们现在的界面是两者混着做的。
About Face 还列了一张十三条的问题清单，我看了下，正好可以当我们项目页的体检表。挑几条你感受一下：用户是谁？他想达成什么目标？产品该如何处理用户遇到的问题？产品如何为老手提供足够的深度？
《用户体验要素》整本书就是一个模型：做产品分五层，从下往上，下面那层没定下来，就别急着做上面那层。书里那句话挺狠："大多数产品失败的原因，就是在错误的层面争论问题 —— 比如还没定战略就开始争按钮颜色。"
我拿它的五层，把我们现有的东西对了一遍。这张表你留着，以后每隔一阵拿出来看一次：
| 层 | 这一层该有的产出 | 我们有吗 |
|---|---|---|
| 战略层 | 产品目标 + 用户需求（含人物画像） | 目标有九条（还等你确认）；人物画像没有 |
| 范围层 | 功能清单 + 内容需求，并标出哪些做、哪些不做 | 四十七条需求有；但没分"必须有"和"有了更好"，所以不知道先做谁 |
| 结构层 | 用户怎么走（流程图）+ 信息怎么摆（分类、命名、导航、搜索） | 流程图有；信息架构从来没系统做过 —— 用户看到的词是不是他自己的话、手机上导航怎么变，都没定 |
| 框架层 | 线框图：每个页面有什么、放在哪 | 五个版本的线稿有；但五十三块界面里三十四块只有简化说明 |
| 表现层 | 视觉：配色、排版、栅格、一致性 | 设计 token 有；视觉打磨没做过，而且没有写下来的设计原则 |
这张表挺好用的地方在于：它把"我们到底缺什么"变成了五个格子，每个格子要么有产出、要么没有。你下次觉得"哪里不对但说不上来"的时候，就从上往下看一遍。
Atomic Design（这本你下载了全书，免费）把界面拆成五级：原子（按钮、输入框这种不能再拆的）、分子（几个原子组成的一小撮）、有机体（一块完整的功能区）、模板（骨架，还没有真实内容）、页面（模板加上真实内容）。
这里面有一句特别值得记住：页面 = 模板 + 真实内容。 我们现在那个演示站，严格说只是"模板"—— 因为里面全是假数据（假的项目名、假的 MAU、假的成交）。模板做得再像，也不等于页面做完了。这句话能解释你之前的一个疑问："我看了演示站，为什么还是不知道做完没有。"因为你看的是模板。
网友那篇笔记里还讲了一个实操方法，叫界面清单：把团队所有人叫到一个房间，把现有界面上每一种样式截图、摊在墙上、分类、找出"同一个东西有五种长相"的地方、合并、然后给每个样式起名。我们做过元素登记（501 条），但那数是出来查定义的，不是出来看"我们的按钮到底有几种长法"。这两件事不一样。
《设计体系》这本书（官方免费第 2 章你下载了）里有一句话点得很准：组件库和设计语言说了产品"是什么样、怎么做"，但没说"为什么是这样"。 而没有"为什么"，下一个人改的时候就会按自己的理解改，三个月后体系就散了。
我们的 tokens 文档（颜色、字号、间距、组件规格）就是"是什么样"。我们缺的是写在最前面的那几句话：我们为什么选暗色、为什么只用五条渐变、为什么发光只给一个按钮、为什么不能给容器上渐变。
别小看这几句话。你以后招人、外包、或者找我改东西，全靠它 —— 没有它，每个人都会按自己的喜好来。
《点石成金》里最出名的一条：人们不是阅读，而是扫描；不做最佳选择，而是满意即可；不追根究底，而是勉强应付。
这个我拿我们的界面自查了一下，有直接可改的地方。比如"连接状态清单"那块，我给每一行都写了"这个数据源供什么指标"（为了满足 Michael 的意见）。但如果是给用户看的，那一行小字他根本不会读 —— 更可能是三个大图标加一句"GitHub 已连上"就够了，详细的放悬停。
书里还有一条标准，叫"广告牌设计 101 法则"：一个页面要能让人在五秒内看懂"这是什么、我该点哪"。我们自己试一下：把项目页缩到手机大小、只看五秒，你能说出这页是干什么的吗？如果说不出来，就是字太多、重点太多。
《信息架构》那本书（网友笔记里那篇讲导航的）把这件事拆成四套系统：怎么分类、怎么命名、导航怎么做、搜索怎么做。
我们现在有两处明显没想过：
一是命名。 我们界面上的词是不是用户自己的话？"持仓"是不是应该叫"我的币"？"连接状态"是不是应该叫"这个项目没有在吹牛的证据"？"里程碑放款"是不是应该叫"钱什么时候给"？这些词一旦定了，用户就只用记一遍；没定，同一个东西在不同页面就会有好几个叫法。
二是手机上的导航。 网友笔记里列了六种移动端的信息架构模式（分层、轴辐式、套娃、标签视图、便当盒、筛选视图）。我们那个"左侧锚点导航"在手机上该怎么变，现在完全没定 —— 而线稿里只写了一句"窄屏收起为顶部下拉"。这一句话背后其实是一个没做的决定。
Web Form Design 那本书（作者资源页你下载了）里有一条被反复引用的研究：标签放顶部，视线移动只要 50 毫秒；放右边要 240 毫秒；放左边要 500 毫秒。 差了十倍。
还有几条同样实用：必填项多的时候，只标"选填"就够（反过来也一样）；校验要在填的时候做，不要等提交；错误消息要写"怎么改"而不是"错了"。
我们的发币向导是七步、几十个输入框，是这个平台上用户投入最多的地方。这几条规则可以一条条对着改。而且第⑦步那个"押金金额"的显示问题（是预估还是锁定），书里也正好有对应的做法。
《设计体系》和 Atomic Design 都讲了同一件事：把现有界面盘一遍（interface inventory），看到底有多少种样式。它的目的不是数数，是发现"同一个东西被做成了好几种样子"—— 然后合并、命名、写进规范。
我们做过元素登记，但没做过这个。我可以预判会查出东西来：四十七块界面分布在五个版本里，按钮、标签、卡片的样子肯定不止一套。
Lean UX（官方画布你下载了）整本书就一个立场：产品是由一组有待验证的假设组成的。 不要假装我们知道用户要什么，先写下假设，再想办法验证，每次验证都让产品更准一点。
我之前给你列了两条猜测（用户看不看得懂 zkTLS、愿不愿意等两三天）。按这个书的要求，猜测不能只写下来，还要配一句"怎么验证"：谁、什么时候、用什么办法、看到什么算验证通过。 现在这两条只有前半句，没有后半句。
这本书还教了一件事：把功能分成"必须有的"和"有了更好的"。我们的四十七条需求现在是平铺的，没分这两类 —— 所以真要砍的时候，砍谁都是拍脑袋。
《用户故事地图》那句精髓，网友笔记写得很清楚：卡片用动词短语，从左到右讲一个故事，从上到下拆细节；先整体后细节。
我们的四十七条需求，现在是按模块排的（R-01 到 R-47 基本对应 M1、C1、C2 这个顺序）。按这个顺序开发，就会出现"前面十几个模块做完了，产品还是不能发币也不能买"。
应该改成横着排：第一行是用户走的路（进来 → 看项目 → 发币 → 买 → 拿走），每一列下面再挂细节。这样"先做哪一段"就一眼看得出来，而不是每次都要我帮你算。
OOUX 那套方法（官方说明你下载了）是四个字母：对象、关系、动作、属性。 我们做了对象（十样东西）和属性，动作也写了（四十七条需求里），但"关系"没做。
关系就是：里程碑属于哪个项目？放款批次属于哪个里程碑？押金挂在项目上还是挂在发售上？验证凭证是项目的还是季度报告的？
这件事看着抽象，其实很实：它能告诉你"删掉一个东西时，还有哪些东西会受影响"，也能告诉你"换一个项目时，哪些数据要跟着变"。我们现在有几处模糊（比如押金到底挂哪），就是关系没画造成的。
Refactoring UI（官方免费两章）的立场是：不用天生的审美，用规则也能把界面做干净。 网友那份笔记（Nolebase 的，很详细）里记了几条，我看完觉得正对我们的问题：
你之前说徽章"丑"，我把上面这几条对着看了一遍：徽章本身其实还行，问题是它周围的界面没有层级 —— 到处是框、到处是线、间距都一样，所以再好的徽章也显不出来。
这十三件我没有停在"列出来"。其中四件最要紧的，我已经用别人的方法真的动手做了：照《设计体系》四步法写出了我们的五条设计原则、照 Lean UX 官方画布把我们在赌什么填成八格和三条假设句、照《用户故事地图》把 47 条需求按"人走的路"重排、照《点石成金》把"找人试"写成明天就能做的动作。
结果都在这份里：01-看得懂的效果/用别人的方法补我们的窟窿.html（同一文件夹，双击就能开）
说了这么多，落到你身上其实只有几件。我怕你看着累，直接列出来。
| 这件事 | 谁做 | 你现在要做的动作 |
|---|---|---|
| 想清楚给谁做 | 你 | 看那九条目标，不同意的改掉；对那两条"我的猜测"表个态 |
| 列出产品里的东西 | 已完成 | 定两件事：实体类型标签做不做、平台币到底有没有 |
| 写成能验收的需求 | 已完成 | 把 22 条还带着待定的拍掉 |
| 画人怎么走 | 做了但有冲突 | 拍那五个数字 |
| 界面拆块写清楚 | 我做你审 | 说一句"把剩下三十四块补齐"，我就做 |
| 把每个数字定死 | 我列你定 | 过一遍 Excel 里"空着显示什么"那一列 |
| 回头对账 | 我查你定 | 对那 59 处逐条说"补"还是"砍" |
| 动手做 | 开发 | 先回答：拍卖这块到底做不做 |
| 验收和维护 | 一起 | 暂时不用你管 |
如果只让你回我几句话，我最想要这五句：
这份东西里关于我们项目的每一条，都出自这些文件：需求台账、模块说明书、模块台账、元素台账 v2、产品需求定稿、流程图。关于"该怎么做"的方法，来自你下载的那几份官方免费资料：About Face 4 第 1 章、Atomic Design 全书、Design Systems 第 2 章、Lean UX 画布、User Story Mapping 作者原文、OOUX 官方说明。
哪一节我写得还是绕，你就说"第几节没看懂"，我重写那一节。