原型设计工具怎么选？以「港城青隅」校园社交项目为例

原型设计工具怎么选？以「港城青隅」校园社交项目为例

做课程项目的时候，原型设计很容易被理解成“画几个 App 页面”。

我一开始也是这么想的：登录页、首页、消息页、我的页面，画出来就差不多了。但在整理「港城青隅」这个校园社交项目时，我发现问题没有这么简单。这个项目不是一个单页面 Demo，它里面有注册登录、校园邮箱认证、用户画像、匹配推荐、即时聊天、线下搭子邀约、举报审核、安全保障等模块。只画几张好看的界面，最多只能说明“它长什么样”，并不能说明“它怎么跑”。

所以这篇文章不想单纯罗列 Figma、Axure、墨刀、即时设计这些工具哪个好用，而是想结合一个具体项目，聊一下原型设计工具到底应该怎么选、怎么用，以及它们在项目里的分工。

1. 先说结论：原型工具不是单选题

很多工具对比文章会直接问：“Figma 好，还是 Axure 好？”

这个问法其实有点问题。因为不同阶段需要验证的问题不一样，工具自然也不一样。

项目早期，最重要的是把业务流程讲清楚；中期要快速确定页面结构；后期才需要做高保真视觉、组件复用和开发交付。如果一开始连用户流程都没想明白，就直接打开高保真工具调颜色和圆角，最后很容易得到一套“看起来不错，但逻辑不完整”的页面。

更合理的选择方式应该是：

当前阶段我要解决什么问题？这个工具能不能把这个问题讲清楚？

对于「港城青隅」这种校园社交项目，我更倾向于把原型设计拆成几层：

• 流程图原型：先说明用户怎么走；
• 低保真原型：再确定页面信息结构；
• 高保真原型：统一视觉和组件；
• 复杂交互原型：补充状态、弹窗、后台审核；
• 代码原型：验证真实设备上的交互细节；
• 开发交付说明：把页面、字段、状态和接口说明清楚。

也就是说，原型设计工具不是一个软件包打天下，而是不同工具在不同阶段各自发挥作用。

2. 为什么这个项目不能只画页面？

先简单说一下项目背景。

「港城青隅」是一个面向高校学生的校园社交与搭子匹配系统。它的核心目标不是让用户随便聊天，而是在校园身份相对可信的前提下，让学生找到兴趣相近的人，一起聊天、学习、吃饭、运动或者参加线下活动。

从目前的设计材料看，这个项目已经不只是 UI 层面的东西。它有系统技术架构图，有 E-R 图，有用例图，还有线下见面和安全保障流程图。

这就说明一个问题：项目真正复杂的地方不在“页面多不多”，而在“流程和状态多不多”。

比如注册登录这个模块，看起来只是一个登录页，但实际上后面会牵涉到：

• 用户是否已有账号；
• 是否完成校园邮箱认证；
• 是否需要补充资料；
• 是否允许进入推荐页；
• 认证失败后能不能重新认证；
• 未认证时能不能聊天或发起邀约。

再比如线下搭子邀约，也不是简单填一个时间地点。它至少还涉及：

• 发起人填写活动类型、地点、时间、人数；
• 系统做安全检查；
• 对方接受或拒绝；
• 双方确认；
• 活动取消；
• 见后反馈；
• 出现问题后举报或拉黑。

这些内容如果没有在原型阶段画清楚，开发时就会不断补逻辑、补弹窗、补状态，最后很容易出现“页面做完了，但业务不顺”的情况。

所以在这个项目里，原型设计工具的作用不是单纯美化页面，而是把复杂业务翻译成可讨论、可点击、可交付的设计产物。

3. 各类原型工具适合做什么？

下面不是做软件排名，而是按项目阶段来拆。

3.1 流程图工具：先把业务链路跑通

在项目刚开始时，我不建议马上做高保真页面。第一步应该先画流程图。

比如用户主路径可以先写成这样：

打开 App
↓
注册 / 登录
↓
校园邮箱认证
↓
完善个人资料
↓
进入推荐页
↓
喜欢 / 跳过 / 聊天
↓
发起搭子邀约
↓
安全确认
↓
见后反馈 / 举报

这个阶段用什么工具其实没那么重要。draw.io、ProcessOn、Visio，甚至 PPT 都可以。重点不是画得多高级，而是先把下面几个问题讲清楚：

• 用户从哪里进入系统？
• 哪些步骤是必选的？
• 哪些地方需要判断？
• 哪些操作失败后要回退？
• 哪些流程和安全有关？

对于「港城青隅」，至少应该先画这些流程：

• 注册登录流程；
• 校园认证流程；
• 用户匹配流程；
• 聊天与邀约流程；
• 举报审核流程；
• 安全保障流程。

流程图的好处是可以先把系统“跑一遍”。如果流程都走不通，页面画得再好也没有意义。

3.2 低保真工具：先定页面骨架

业务流程确定以后，才适合进入页面原型。

低保真阶段不要急着调主色、阴影、图标、动效。这个阶段更像是在搭页面骨架，重点是确定信息结构和操作入口。

以推荐首页为例，低保真原型要先回答这些问题：

• 推荐对象的头像、昵称、学校、专业放在哪里？
• 兴趣标签和匹配理由要不要展示？
• “喜欢”“跳过”“聊天”三个按钮怎么排列？
• 用户未认证时是否拦截？
• 推荐为空时页面怎么显示？
• 点进详情页后展示哪些信息？

这个阶段可以用墨刀、摹客、即时设计、Figma、Pixso 等工具。对于课程项目来说，低保真工具最大的优势就是快。页面结构不合理时，可以马上改，不会因为视觉细节投入太多而舍不得推翻。

下面这张图就是围绕五个底部导航页做的低保真示意：

这里的目标不是让页面“漂亮”，而是先让功能入口完整：

• 首页：匹配推荐；
• 发现：校园动态或兴趣内容；
• 搭子：线下邀约；
• 消息：聊天与通知；
• 我的：资料、认证、隐私和安全设置。

如果低保真阶段做得扎实，后面高保真和开发都会轻松很多。

3.3 高保真工具：统一视觉和组件

当页面结构基本确定后，才需要进入高保真阶段。

高保真原型要解决的不是“这个按钮放哪里”，而是“整个产品看起来是否统一”。它需要处理：

• 主色调；
• 字体层级；
• 卡片样式；
• 按钮状态；
• 标签样式；
• 表单样式；
• 图标风格；
• 页面间距；
• 组件复用。

对于「港城青隅」这种校园社交项目，高保真风格不应该太花。因为它涉及认证、举报、线下见面和安全提示，整体视觉最好偏清爽、可信、轻社交，而不是过度娱乐化。

这类工作适合用 Figma、Pixso、即时设计等工具完成。它们比较适合沉淀组件，比如：

• 用户推荐卡片；
• 兴趣标签；
• 聊天气泡；
• 搭子活动卡片；
• 举报弹窗；
• 认证状态标识；
• 底部导航栏。

组件化的意义在于，后面改样式不需要每个页面都重新调整。比如兴趣标签的圆角、边框、字号确定以后，推荐页、资料页、搭子页都可以复用。

3.4 Axure：适合复杂状态和后台交互

如果只是移动端页面展示，Axure 不一定是最轻便的选择。但遇到复杂状态和后台管理时，Axure 的优势会比较明显。

例如「港城青隅」里的管理员后台，需要处理：

• 举报列表；
• 举报详情；
• 聊天证据查看；
• AI 审核结果；
• 管理员处理意见；
• 警告、禁言、封禁；
• 用户申诉；
• 处理状态切换。

这些内容靠静态图很难讲清楚。因为它不是一个页面，而是一串状态变化：

待处理 → 人工复核 → 处理完成 → 用户申诉 → 重新审核

这种时候，用 Axure 的动态面板、条件判断、弹窗和状态切换，会比单纯画几张 UI 图更清楚。

所以我的理解是：

移动端展示页可以用 Figma / Pixso / 即时设计，复杂后台和状态切换可以用 Axure。

这不是工具高低之分，而是适用场景不同。

3.5 代码原型：验证真实交互

有些问题在设计工具里看不出来，只有真正跑起来才知道。

比如：

• 聊天列表消息很多时滚动是否自然；
• 标签过多时是否自动换行；
• 推荐卡片在小屏手机上是否拥挤；
• 网络失败时页面怎么回退；
• 表单输入和键盘弹出是否冲突；
• 加载中、空状态、失败状态是否自然。

这时就可以做一点代码原型。如果是 Android 项目，可以用 Jetpack Compose 写一个推荐卡片或搭子发布页；如果是 Web 项目，可以用 Vue 或 React 写一个页面切片。

代码原型不是要替代设计稿，而是用最小成本验证真实交互。

下面是一个非常简化的 Compose 推荐卡片示意：

@Composable
fun MatchCard(user: MatchUser) {
    Card(
        modifier = Modifier.padding(16.dp),
        shape = RoundedCornerShape(20.dp)
    ) {
        Column(Modifier.padding(18.dp)) {
            Text(user.nickname, fontWeight = FontWeight.Bold)
            Text("${user.school} · ${user.major}")

            FlowRow {
                user.tags.forEach { TagChip(it) }
            }

            Text("推荐理由：${user.reason}")

            Row(horizontalArrangement = Arrangement.spacedBy(12.dp)) {
                OutlinedButton(onClick = { skip() }) { Text("跳过") }
                Button(onClick = { chat() }) { Text("聊天") }
            }
        }
    }
}

代码原型的好处是接近真实实现。比如标签换行、按钮宽度、滚动区域、输入框和键盘这些问题，在静态设计图里经常被忽略，但在代码里很快就会暴露出来。

4. 一张表整理工具分工

把上面的内容压缩成一张表，大概是这样：

文字版也可以这样理解：

场景	推荐工具	主要作用
业务流程	draw.io / ProcessOn / Visio / PPT	把用户路径和业务判断画清楚
低保真页面	墨刀 / 摹客 / 即时设计 / Figma	快速确定页面结构和信息层级
高保真 UI	Figma / Pixso / 即时设计	做视觉统一、组件复用和展示
复杂交互	Axure	处理动态面板、弹窗、状态切换和后台逻辑
代码原型	Compose / Vue / React / HTML	验证真实交互、设备适配和数据边界
AI 绘图	图像生成工具	做封面、氛围图、插画，不建议做核心流程图

这里顺便说一下 AI 绘图。

我觉得 AI 绘图适合做封面图、氛围图、概念图，但不太适合直接生成核心原型图。因为原型图最重要的是准确：按钮文字、字段名称、流程箭头、状态关系都不能乱。而 AI 图在中文文字、布局细节和后续修改上并不稳定。

所以更稳妥的做法是：

核心原型图自己画，AI 图只做辅助展示。

技术博客里的配图也一样。图不一定要很炫，但一定要能解释问题。

5. 原型里必须补状态和异常

很多课程项目的原型只画正常路径：注册成功、推荐成功、聊天成功、邀约成功。这样看起来流程很顺，但真实系统里更多问题出现在异常状态。

比如下面这些情况，如果原型里不画，开发时一定会临时补：

• 邮箱验证码错误；
• 校园邮箱认证失败；
• 用户资料未完善；
• 推荐结果为空；
• 聊天内容被审核拦截；
• 对方拒绝搭子邀约；
• 活动临时取消；
• 举报证据不足；
• 管理员需要人工复核；
• 被举报用户发起申诉。

这些状态并不是可有可无的细节。它们会直接影响页面怎么展示、按钮是否可点、接口怎么返回、用户下一步去哪里。

比如“未认证用户能不能聊天”这个问题，如果原型阶段没有明确，开发时可能会出现三种不同实现：

• 首页能点聊天，但进入后提示认证；
• 首页按钮直接置灰；
• 点聊天后跳转到认证页。

这三种方式都能实现，但用户体验完全不同。如果不在原型阶段定下来，后面就会反复改。

所以一个成熟一点的原型，不应该只画“成功时”的页面，还应该画“失败时、等待时、没有数据时、权限不足时”的页面。

6. 从原型到开发，交付的不是一张图

原型最后要交给开发。这个时候如果只给一张 UI 图，开发还是会有很多疑问。

比如推荐首页，开发需要知道的不只是卡片长什么样，还包括：

• 这个页面需要哪些字段；
• 字段为空时怎么显示；
• 页面是否需要登录；
• 页面是否要求校园认证；
• 加载中怎么展示；
• 推荐为空怎么展示；
• 点“喜欢”之后状态怎么变；
• 点“聊天”时如果未认证怎么办；
• 是否需要记录用户反馈；
• 是否触发推荐模型更新。

这些都属于原型交付的一部分。

我觉得一个比较完整的原型交付，至少应该包括：

1. 页面说明：每个页面的作用和入口；
2. 跳转关系：按钮点击后的路径；
3. 字段清单：页面需要展示哪些数据；
4. 状态说明：加载、空数据、失败、禁用、审核中；
5. 权限规则：未登录、未认证、被拉黑时怎么处理；
6. 异常处理：失败提示、重试、回退；
7. 组件规范：按钮、标签、卡片、弹窗样式；
8. 开发备注：接口、埋点、缓存、审核等特殊要求。

这样开发拿到原型时，才不是只知道“页面长什么样”，而是知道“这个页面怎么做”。

7. 结合项目的推荐原型流程

如果重新为「港城青隅」做一遍原型，我会按下面这个顺序来：

第一步：画业务流程

先用流程图工具画出主链路：

注册登录 → 校园认证 → 完善资料 → 匹配推荐 → 聊天 → 搭子邀约 → 安全确认 → 见后反馈

同时补上几条支线：认证失败、推荐为空、内容审核、举报处理、管理员复核。

第二步：做低保真页面

先画这些核心页面：

• 登录页；
• 注册页；
• 校园邮箱认证页；
• 资料完善页；
• 推荐首页；
• 用户详情页；
• 聊天页；
• 搭子发布页；
• 搭子详情页；
• 举报弹窗；
• 我的页面；
• 管理员举报处理页。

这一步主要看结构，不看美观。

第三步：补状态页面

给关键模块补异常状态：

• 注册失败；
• 认证失败；
• 推荐为空；
• 聊天拦截；
• 邀约拒绝；
• 活动取消；
• 举报处理中；
• 申诉中。

这一步很容易被忽略，但它决定项目是否完整。

第四步：做高保真和组件

页面结构稳定以后，再统一视觉和组件：

• 主色；
• 字号；
• 卡片；
• 标签；
• 按钮；
• 弹窗；
• 聊天气泡；
• 底部导航；
• 安全提示样式。

第五步：挑一个页面做代码原型

不需要一开始把所有页面都写出来。可以先选一个最能代表项目特点的页面，比如“推荐首页”或“搭子发布页”，做一个可运行的代码原型。

这样能提前验证：

• 页面在真机上是否拥挤；
• 标签数量多时是否换行；
• 按钮是否方便点击；
• 空状态和错误状态是否自然；
• UI 结构是否适合后续开发。

第六步：整理交付说明

最后把页面、跳转、字段、状态和异常整理成开发交付文档。这个文档可以不用很长，但一定要具体。

8. 总结

原型设计工具不是为了把项目包装得更好看，而是为了让项目更早变得具体。

在「港城青隅」这个项目里，如果只做几张 UI 图，很难讲清楚校园认证、用户画像、匹配推荐、聊天、搭子邀约、安全保障和后台审核之间的关系。原型工具真正要做的，是把这些流程拆开、画出来、连起来，再交给开发实现。

所以我对原型设计工具的理解可以总结成三句话：

流程图解决“用户怎么走”；
页面原型解决“界面怎么变”；
交付说明解决“开发怎么做”。

工具本身不是重点，阶段和问题才是重点。只要能帮助我们更早发现需求漏洞、交互漏洞和实现风险，它就是合适的原型工具。

对于课程项目来说，原型不一定要做得非常复杂，但必须能让别人看懂：这个系统为什么这样设计，用户怎么使用，异常怎么处理，开发怎么落地。

这才是原型设计工具真正的价值。