1. Demo 的三个角色

2016 年，我在做一加海外社区 App。

线框图确认之后，我做的第一件事不是画高保真——是用墨刀做了一个完整的可点击 Demo。看起来很像成品，点起来也能跑通所有流程。

然后我找了五个用户来测试。其中一个任务是这样的：发一篇帖子，引用别人的回复。

在线框图上看，这个流程很简单：点 Quote→选内容→点发布。但用户在实际操作 Demo 的时候，有个步骤的完成率只有 30%——十个人里，有七个人卡在那个步骤，不知道怎么继续。

如果没有这个 Demo，这个设计就会带着这个问题上线。等到开发完了才发现，改的成本，是设计阶段的几十倍。

交互稿是「死的」。Demo 是「活的」。在活的东西上测试，你才会发现死的东西上看不到的问题。

很多人觉得，Demo 就是「把设计稿做成可以点的东西，给老板看」。这是 Demo 最不重要的用法。Demo 真正的价值，在三个地方：

角色一：用户测试的载体。静态设计稿没法测试——用户在静态图上「假装点击」，和真正操作一个可交互的东西，完全是两种体验。只有 Demo 才能暴露真实的可用性问题：哪里卡住了、哪里用户困惑了、哪里流程绕了。

角色二：干系人对齐的工具。给老板看 PPT，他说「不错」。给老板看 Demo，他会点来点去，然后说「这里为什么这样？」——这就是对齐。Demo 把抽象的讨论，变成了具体的体验。越早对齐，后面返工越少。

角色三：开发沟通的语言。PRD 文档写一百页，不如一个 Demo 让开发自己点一遍。他们点完就知道：哦，这里有个过渡动画、这个按钮点了会展开、这里的数据要请求这个接口。Demo 就是活的需求文档。

2. 怎么做 Demo 才不浪费时间？

很多设计师不爱做 Demo——觉得费时间。确实费时间，但费的是值得的时间。关键是怎么做效率最高：

第一步，做低保真。不需要精美的视觉。墨刀、Axure、Figma 都行，线框图级别的 Demo 就够了。目标是验证流程，不是展示设计。用户不会因为你的 Demo 不好看而说流程好——他们只会关注「能不能完成任务」。

第二步，做关键路径。不要试图把整个产品都做成 Demo。只做核心任务的路径。用户最常做的三五件事，把这些路径打通。其他边缘功能，不需要 Demo。

第三步，测试→改→再测试。找五个人，让他们完成关键任务。看他们哪里犹豫、哪里点错、哪里抱怨。五个人能发现 85% 的可用性问题。改完再找五个人测。直到核心任务的完成率达到 80% 以上。

工具选择

墨刀、Axure：适合早期低保真 Demo。画得快、改得快。

Principle、Protopie：适合需要精细动效展示的场景。比如一加产品站的产品展示动画。

Figma 原型模式：适合已经有设计系统、组件库的团队。直接用已有组件搭 Demo，效率最高。

有一次，一个项目赶进度。PM 说：「别做 Demo 了，交互稿评审过了就直接给开发吧。」

我当时觉得风险不大——流程很简单，逻辑也清楚。结果开发完了，第一个用户测试，就发现了三个核心流程的问题。其中一个问题，需要动到数据库结构——改的成本，是设计阶段的百倍都不止。

后来我给自己定了一条铁律：

任何用户会用的东西，上线之前，必须经过至少一轮 Demo 测试。没有例外。

这不是流程洁癖。是血泪教训。

Demo 就是设计的「路试」。没有经过路试的车，你可能侥幸开到目的地。但更可能——在半路抛锚。

下一章，我们进入设计的视觉面——从情绪版开始，讲如何把商业目标，翻译成色彩、字体和设计语言。