做产品这些年我见过太多原型图翻车现场评审会上需求方看得津津有味开发一开口就噎住了——“这个页面从哪进来”“我从消息列表点进去返回该回哪”“断网了显示什么”你会发现画原型图的人脑子里只有一张静态图根本没有流程。真正靠谱的路径是先画页面流程图再画页面原型图。从流程图里把页面逻辑理清楚落到原型图上的每一帧才有根有据。这篇文章我用抖音这个大家都在用的产品当例子把页面流程图和页面原型图从零拆一遍希望你画完不仅能过评审还能让开发少问两句。适合刚入门的产品经理、转岗做产品的同学也适合被原型图折磨到想改行的朋友。1. 页面流程图和页面原型图先搞清楚两件事1.1 页面流程图画的是“用户怎么走”很多人一上来就打开Axure或者Figma开始拖控件这是第一步就走错了。页面流程图简单说就是把“用户从入口进来一步一步走到完成任务的出口”这个过程用方框和箭头画出来。方框代表页面或者关键界面状态箭头代表跳转关系箭头上标注跳转条件。它不关心这个页面长什么样、按钮好不好看只关心用户在这个产品里“怎么走”走到哪一步会遇到什么选择选错了能不能回得来。和业务流程图不一样业务流程图画的是角色、系统、状态之间的流转关系比如“用户提交订单→系统校验库存→生成订单→通知仓库”。而页面流程图只画用户能看见的、能点击的界面切换。业务流程图回答“这件事怎么被完成”页面流程图回答“用户在这套界面里怎么操作才能完成这件事”。我以前带过一个新人让他画一个登录注册模块的原型他直接画了三个页面登录页、注册页、忘记密码页然后发给开发。开发问“我从设置页点退出登录再点登录登录成功之后去哪是回首页还是留在设置页”他答不上来。这就是典型的没有先画页面流程图。登录这个任务涉及的页面跳转完全不只有三个页面得考虑登录前从哪进来、登录成功后回哪去、如果已经登录再点登录入口该怎么办、要不要自动跳转、切换账号之后数据怎么刷新。这些逻辑全部画在页面流程图里原型图才有灵魂。1.2 为什么非得先画页面流程图我承认直接画原型图确实更快看起来也更直观但这条捷径十次有九次会让你在评审或者开发阶段返工。先画流程图本质上是把“想清楚”这件事前置了。第一流程图逼你把分支补齐。原型图上画一个“个人主页”很容易但到了流程图里你自然就会追问个人主页从哪里可以进视频播放页能进、关注列表能进、私信列表能进、搜索页能进。进入路径不同返回逻辑就不同有的返回到视频播放页有的返回到搜索结果。这些问题画原型的时候很容易漏但画流程图时因为要画箭头、标条件漏了就画不下去。第二页面流程图直接决定开发工作量。每多一个页面开发就要多写一套布局、多处理一套数据、多测一套交互。流程图一摊开整个产品的页面数量、功能边界、逻辑复杂度一目了然。有个经验法则页面流程图上的节点数量基本等于这次迭代的页面数量也约等于开发估工时的主要依据。所以流程图画完你和开发聊排期都会更有底气。第三评审的时候逻辑比审美更容易对齐。原型图画得再精美如果跳转逻辑有硬伤评审会上照样被挑战。而流程图能让人快速把焦点聚在“用户路径顺不顺”“异常情况怎么处理”上。我习惯在评审会议上先把流程图投出来讲一遍再翻原型图百分之八十的争议都能在第一轮就消掉剩下那百分之二十才是真正的需求和业务问题。2. 拆一个实例抖音核心播放链路的页面流程图2.1 画流程图之前先把页面清单列出来你可能会说页面流程图听起来不复杂但拿到需求还是不知道从哪下笔。我自己的方法是先别急着画方框连箭头先把用户要完成的任务拆解成步骤再根据步骤列出涉及的页面清单最后才上流程图。拿抖音举例子。假设我们这次的产品迭代目标是优化“用户从打开App到看完一个视频并进入作者主页关注他”的完整路径。先把用户任务拆成步骤打开App、看到推荐视频、点击视频、看视频、想看看作者是谁、进入作者主页、决定关注不关注、关注成功。然后根据这些步骤列出可能出现的页面或界面状态启动页、首页推荐流、视频播放页、作者个人主页、关注弹窗、登录页。这个是主干路径的清单。但光有主干不够你得问问自己用户不点视频划走了怎么办用户点了评论区怎么办用户没有登录直接点关注怎么办于是清单里再加评论半屏页、登录引导弹窗、登录页。把这些列完页面流程图的基本元素就齐了。画页面流程图这东西最怕脑子一热直接在画布上乱连。页面清单就是你的“菜谱”照着清单去画才不会漏页。我可以告诉你一个检查办法你列出的页面清单最后每个页面都应该在流程图里出现过至少一次如果某个页面画到最后没用到那就说明要么这个页面多余要么你的流程图画漏了路径。2.2 页面流程图绘制规则页面流程图没有国家标准但既然要给别人看就得用大家都能读懂的规则。我自己习惯的约定是这样的矩形框代表页面或弹窗框内写页面名称尽量用名词比如“视频播放页”“个人主页”不要用动词短语。菱形代表判断条件比如“是否已登录”“是否有网络”从菱形引出的每条线上必须写着对应的条件不能只画两根光秃秃的箭头。箭头代表页面跳转方向箭头上标注触发动作比如“点击关注按钮”“左滑”“下拉刷新”。这样别人一看就知道这次跳转是因为什么操作。页面状态用括号或斜体标注在页面名字下面比如“个人主页访客态”“个人主页本人态”因为同一个页面在不同状态下展示的内容可能完全不一样。另外我强烈建议所有页面框统一宽度字体统一大小箭头尽量横平竖直少画斜线。流程图是给人看的逻辑图不是艺术创作画得规整比画得好看重要一百倍。你想想一个页面框忽大忽小、箭头歪歪扭扭的流程图评审会上连老板都看得皱眉还怎么安心讨论逻辑。还有一个细节画完主干之后一定要用另一种颜色或者虚线把异常路径和兜底路径标出来。异常路径包括断网、接口报错、没有数据、权限不足等等。兜底路径包括用户点返回、点取消、超时退出。这些路径虽然看起来边缘但开发写代码的时候百分之六十的时间都在处理它们。你不在流程图里标清楚开发就只能自己猜猜出来的结果必然和产品预期不一样。2.3 抖音核心播放链路的页面流程图实例接下来是实操。我以抖音最典型的一条链路为例用文字把页面流程图的关键节点还原出来。你画的时候把这些节点摆在画布上按顺序连起来就行。启动App → 首页推荐流默认Tab推荐 → 点击视频卡片 → 视频播放页 → 这里有两种主流情况情况一用户直接在播放页上下滑刷到下一条视频继续停留在视频播放页只是播放内容切换。情况二用户右滑进入作者个人主页 → 点击关注按钮 → 判断是否登录 → 已登录则关注成功关注按钮变成“已关注” → 点击返回回到视频播放页 → 未登录则弹出登录引导弹窗 → 点击“登录”进入登录页 → 登录成功后回到作者个人主页并且自动完成关注动作。这只是主干。如果用户在看视频的时候点开了评论区从视频播放页会滑出“评论半屏页”点评论区右上角关闭按钮回到视频播放页点某条评论的点赞按钮如果是未登录状态同样要弹出登录引导弹窗。如果用户点开视频时网络断开视频播放页要显示“网络异常”提示并提供“重新加载”按钮点击后回到视频播放页重新请求数据。我把这张流程图读一遍你会发现它根本不关心某个按钮长什么样、播放页放的是评论还是分享它只关心一个用户会在哪些界面之间跳来跳去以及什么条件下允许跳、跳到哪里。这就是页面流程图最大的价值页面和路径全部可视化任何逻辑漏洞在它面前都藏不住。实际画的时候你可以用Axure画流程图也可以用ProcessOn、draw.io这些在线工具。我不建议为了画流程图去专门买什么高级工具能用浏览器打开就行重点是逻辑不是工具。如果团队有统一的协作平台就用团队统一的那一个因为流程图后续还要和原型图放在一起评审统一平台可以省掉很多文件传来传去的麻烦。3. 把流程图变成页面原型图抖音视频播放页实操3.1 先定原型粒度低保真、中保真、高保真怎么选流程图理清楚了页面清单也定了终于可以开始画页面原型图了。但别急着一步到位画那种连阴影渐变都还原的高保真图你得先想清楚这次原型要拿给谁看、用在什么阶段。低保真原型一般是黑白线框图用矩形和文字占位重点表达页面信息结构和布局逻辑。它适合产品内部讨论画得快、改起来也快完全不会在视觉上跑偏。中保真原型会加入基本的图标、字体层级、间距有时会套上真实文案但还不会精细到像素级还原视觉。高保真原型几乎没有视觉上的替代感颜色、图标、布局接近甚至等于最终界面适合给老板汇报或者做用户测试。这里有个特别多新人踩的坑一上来就画高保真结果做一页花了三个小时画完发现整体信息架构不对改一版又花三个小时最后加班到凌晨评审会上被说“页面太丑”。其实高保真和低保真的画法在信息架构层面是一样的区别只是视觉细节。所以我一般建议第一轮全部用低保真把页面布局和信息层级定下来大家确认逻辑没问题了再挑选几个核心页面升级到高保真专门用来展示视觉方向。工具选择上我一直觉得工具是次要的逻辑才是主要的。团队用Figma就跟着用Figma团队用Axure就用Axure如果你一个人单打独斗现在更推荐Figma或者国内的即时设计、万兴科技那类在线协作工具。它们支持多人实时编辑评审时可以直接在原型上打点评论对提高协作效率帮助非常大。3.2 页面布局抖音视频播放页为什么这样排布局是所有原型图最基础的一层。我拿抖音视频播放页来拆为什么它的界面是今天这个样子以及你画原型时该画什么。先看整体视频播放页几乎是全屏视频展示的这是它的第一优先级。画面内容最大所有其他元素都叠在视频之上。为什么这样设计因为抖音的产品目标是让用户沉浸在短视频内容里尽量少受干扰所以主内容占满整个屏幕其他所有操作按钮都悬浮在画面边缘不抢占注意力。再看右侧操作区从上到下分别是头像、点赞、评论、收藏、转发、分享。为什么放在右侧而不是底部因为用户单手拿手机的时候拇指最活跃的区域就是屏幕中下部和右侧把这些高频操作放在右侧用户哪怕单手也能轻松点按。点赞、评论、转发是短视频互动最重要的三个动作所以它们不仅在右侧纵向排列还占据了视觉权重最高的位置——从上往下数的第二、三、四位。然后是底部信息区包括作者的昵称、视频文案、音乐标签、话题标签。这些信息属于“沉浸式浏览时补充给用户的内容”所以放在视频画面下方位置比较低只有用户想看作者信息、看文案的时候才会扫过来。抖音把“关注按钮”放在了作者昵称旁边而不是像很多传统视频产品那样放在视频下方这其实暗含了产品逻辑用户在抖音里关注作者是在对这个人感兴趣的前提下发生的动作所以把“关注”和“作者信息”绑定在同一个区域。画这个页面的原型图时你要做的第一件事不是把每个图标都画得跟真的一样而是用矩形块把画面分成几个区域视频区域、右侧操作栏、底部信息栏、顶部状态栏和搜索入口。先用线框把结构搭出来再往每个区域里填充图标和文字。这个过程看起来简单但这正是很多产品新人最着急跳过去的一步。结构不对后面全白搭。3.3 交互说明与标注原型图的核心增量静态原型图只能表达“每个页面长什么样”表达不了“用户在这里做了什么会发生什么”所以必须配交互说明。我见过很多产品新人画原型只是在页面上放几个图标然后口头跟你讲“这里点赞、这里评论、这里分享”。你问多了他还会不耐烦。其实开发根本不会记住你口头说了什么他们只认图上的注释。交互说明写不清楚开发就会按自己的理解来做做完就是一场事故。还是拿抖音播放页举例。我在画原型图时会在每个可交互元素旁边拉一条注释线写明交互规则。这里我给你列一个最典型的部分交互说明你在画原型时可以直接参考这个颗粒度交互元素触发动作交互反馈补充说明右侧点赞按钮单击图标变红数字加1按钮轻微放大回弹再次点击取消点赞数字减1视频画面双击出现点赞特效动画同时完成点赞动作双击空白区域有效双击已有文字区域无效视频画面单击暂停/继续播放同时显示/隐藏顶部和底部操作栏暂停时操作栏淡入显示视频画面上下滑动切换到上一条/下一条视频滑动距离超过阈值才切换未超过回弹视频画面长按进入倍速播放状态松手恢复原速长按期间显示“倍速播放中”提示评论区入口上滑拉出评论半屏页评论页遮住视频画面下半部作者头像单击跳转到作者个人主页保留视频播放页可从主页返回关注按钮单击未登录弹出登录引导弹窗登录成功后自动完成关注并返回当前页写交互说明的时候有一个原则一定要记住每个交互都要回答三个问题——触发动作是什么、反馈结果是什么、有没有例外情况。比如“点击关注按钮”触发动作清楚反馈是“变成已关注”那例外情况就是“未登录”。把这三个问题填满开发基本就不用再来问你第二遍。另一个高价值操作是标注页面状态。同一个页面首次进入和返回进入、有数据和没数据、有网络和断网界面表现完全不一样。你需要在原型图里把这些不同状态都画出来或者用文字明确标注。比如视频播放页至少要有正常态有视频有数据、加载态转圈、空态没有视频内容、异常态断网或接口失败。这些状态不画出来开发上线后就会出现“有网络没事断网就白屏”这种最低级的问题。3.4 不同状态的原型分支别让开发来猜上面说到了状态我再展开讲一讲因为这是检验一个产品经理基本功最直接的标尺。很多人画原型图只画“正常路径”下每个页面的样子比如登录页就是输入框加登录按钮播放页就是画面加互动按钮。但用户的使用场景绝不只是正常路径。用户可能在弱网隧道里打开App也可能在今天凌晨失眠时突然点开一个根本没有评论的视频。我在团队里带新人时会要求他们在原型图交付时额外附带一份“页面状态自查表”列清楚每个页面的加载态、空态、异常态分别是什么样。拿抖音首页推荐流举例正常态是视频卡片瀑布流加载态是骨架屏加转圈空态是“暂无推荐点击重试”异常态是网络错误提示加“重新加载”按钮。这些状态不一定要全部用原型图单独画出来但必须写清楚哪怕只是注释一行字开发也有据可依。我见过最离谱的一次是新人在原型里只画了正常态开发按图开发完结果线上用户断网时页面一片空白连个提示都没有。用户骂产品经理产品经理一脸无辜说“我没想到这个”。这是最典型的偷懒式画原型你当时漏掉的那一个小时后面要花一周甚至一个月去还。4. 原型图实操中的常见问题和排查技巧4.1 流程图和原型图对不上评审被问懵这是最让产品经理尴尬的场景流程图里画了五个页面原型图只出了四个或者原型图里多了一个流程图里根本没有的弹窗。评审会上开发拿着激光笔一页一页对着看看得你汗流浃背。这个问题发生的根源往往是你先改了一个页面但忘了回流程图里同步对应的节点。页面流程和原型图之间的关系就像目录对应正文正文改了目录没更新整本书就乱了。我自己的做法是每次修改原型图之前先回到流程图里找到这次改动的页面节点确认这个改动是否影响了跳转关系和条件判断。如果影响就先改流程图再改原型图。流程图画起来成本低、改起来也快用它来兜底是最稳妥的。另外我建议你把流程图和原型图的版本号绑定。每一版交付物流程图文件名和原型图文件名用同一个版本号比如“抖音播放链路流程图_v1.3”配“抖音播放链路原型图_v1.3”。这样评审时不管是开发还是测试拿到的都是同一套逻辑不会出现图是新的、流程是旧的笑话。4.2 只画主流程分支和异常态全丢这个问题我前面反复提过但因为它太常见、太致命我必须再单独列一节出来。产品新人画流程图最顺手的就是画一条快乐路径进入页面、点击按钮、成功完成、退出页面。但真实用户的行为路径完全没有这么听话。他们可能在第二页就退出了可能在填写表单时切出去回了个微信可能连点三次保存按钮导致重复提交。排查清单如下你可以在画完流程图后逐项检查每个判断节点是否引出了条件不满足时的路径比如“是否登录”不止要有“是”还要有“否”的走向。每个页面是否至少有两个出口一个继续前进的一个返回或取消的。涉及外部跳转的有没有“从外部回到本App”的路径网络异常、接口超时、无数据的场景是否有对应页面或提示输入型页面有没有校验失败时的提示位置和返回逻辑我每次画完流程图都会花十分钟做这个自查节省下来的评审扯皮时间远超十分钟。一个做到位的流程图不该是一根没有分叉的直线而是一棵有主干、有分支、还有根部异常兜底的树。4.3 版本管理混乱开发拿着旧图开发原型图版本混乱的问题很多人觉得不值得一提但有一次我们组上线前联调开发说“按你最新一版做的呀”结果发现他手里的版本还是三天前评审时那版期间你已经改了十几个交互细节。那一次的事故让我下决心把版本管理流程化。先说文件名规范。推荐格式项目名页面模块版本号修改日期。例如“抖音播放链路原型图_v1.3_20250610.rp”不要用“最终版”“绝对不改版”“打死也不改版”这种命名十个人里有十一个最后会被打脸。再说更新记录。每一版原型图首页我习惯放一个版本更新表列出修改时间、修改人、修改内容摘要、当前版本号。评审时只要打开首页所有人就能一目了然这一版改了什么。这比评审到一半有人忽然问“上一版不是这样啊”要省心得多。如果你用Figma或即时设计这种在线协作工具版本控制会更方便有自动的历史版本记录。但即使有自动版本我依然建议你手动维护首页那页更新表因为自动历史记录不会告诉你“这次改动的动机是什么”而更新表会写清楚。4.4 团队协作中的小技巧最后分享几个我在实际协作中摸索出来的小习惯可能不写在任何教程里但真的很管用。评审前发完链接后我会给开发额外发一份“改版说明”。这份说明不需要太长就是列出“这次改了哪些页面、动了哪些交互、影响到了哪些旧逻辑”。这样做的好处非常明显开发拿到原型后不用自己处处探索你改了哪里能直接针对改动点去研究和提问效率和准确率都提升不少。另一个习惯是给每个可点击元素打上编号编号和交互说明表格里的编号一一对应。比如视频播放页的点赞按钮编号为“P01”交互说明表格里就有一行“P01 点赞按钮”。评审的时候只要说“P01取消点赞后数字是否需要马上减一”大家都能立刻定位到具体元素不用在原型上瞎猜你指的是哪个控件。这个方法特别适合交互密密麻麻的页面比如视频播放页、电商商品详情页。还有一个我一直在用的原则先做减法再做加法。原型图第一版只画核心功能和路径确定核心逻辑没问题后再往里面补次要功能和情感化细节。很多新人一上来就什么都想画进去结果主次不分评审时大家都在研究一个不重要的动画反而忽略了一个严重的逻辑漏洞。产品经理画原型不是为了炫技是为了让对的人在对的时间讨论对的问题。最后再分享一个我自己的画图习惯写了这么多最后聊一个画原型图这么多年我一直坚持的习惯无论多简单的需求我都先画页面流程图而且先用纸笔画草稿不用任何工具。纸笔的粗糙反而是一种优势。它不会让你沉迷在拉线对齐这些细节里逼你只思考一件事——这个流程通不通。等纸上的流程草稿跑通了再一口气把流程图和原型图画进工具里效率比直接在工具里改半天高很多。你也可以试试先从自己手机里最常用的那个App开始比如抖音随便找一个功能把它倒推成流程图和原型图练上一两个你再看需求文档的思路都会不一样。