1. 从一次面试被问住说起我为什么开始认真收集原型几年前我去面一家做企业服务产品的公司聊到一半面试官突然问我你平时都去哪里看产品原型我脱口而出几个设计灵感社区的名字然后补了一句主要就是找漂亮界面。对方点点头紧接着问了一句让我当场卡壳的话那你看完这些原型之后形成了什么自己的判断标准吗我愣了好几秒确认自己从来没有认真想过这个问题。那次之后我开始反思。产品原型这件事绝大多数人把它当素材库用——要做界面了去翻一翻别人的设计找张好看的图照着改。但如果你跳出来看看产品原型其实是一个性价比极高的学习动作你不需要自己从零复盘几百个产品只需要站在别人已经跑过的路上拆解他们为什么这么做。它本质上解决三个问题一是有没有更好的交互方案二是我的判断有没有依据三是我能不能在动手前就避开别人踩过的坑。这也是我后来会把看产品原型的好地方从收藏夹里的三五个网站逐渐扩展成一套自己的信息收集系统的主要原因。适合来读这篇文章的人我觉得有两类。一类是刚入行的产品经理、交互设计师正在为不知道去哪里找参考发愁另一类是已经有几年经验、但发现自己看的原型越来越多、能留下的东西却越来越少的人。前者我帮你列一份可以直接收藏的资源清单后者我讲讲怎么把看变成拆让一次浏览真正沉淀成自己的东西。2. 按需求分层的原型资源清单别再用一个网站应付所有场景我把看原型的场景分成四层每一层解决的需求不一样对应去看的地方也不一样。如果你只想收藏一个综合社区当然可以但那样效率很低。真实工作中你需要的是要灵感的时候去哪里要研究真实产品交互的时候去哪里要理解一个设计系统底层逻辑的时候去哪里以及想看偏国内业务场景的时候去哪里。下面按这四层展开。2.1 第一层设计灵感聚合站这一层解决的是界面还能长什么样的问题适合在产品视觉方向还没定、需要快速找风格参考时使用。最常用的还是Dribbble和Behance。Dribbble上的作品普遍视觉完成度高很多是纯概念稿不会受真实业务逻辑束缚所以特别适合找感觉。Behance上的完整项目比较多能找到从调研到最终界面的连贯展示适合看一个方案是怎么从前期分析推导到落地视觉的。另外Awwwards和Land-book偏网页端做官网、落地页、营销活动页时会去翻。这类站点的问题也很明显好看不等于好用。很多作品会为了视觉效果牺牲信息密度和操作效率如果你直接照着抄很可能做出来一个看着惊艳但实际用起来处处别扭的界面。我的建议是把这类站点定位成审美补给站只看不做用来校准自己的品位而不是直接拿来做竞品分析。2.2 第二层真实产品交互流程库这一层才是看产品原型最硬核的部分。它解决的是真实产品完整交互流程是什么样的问题。这里要特别推荐Mobbin、Pageflows和UX Archive。Mobbin收录了大量真实App的分页面截图而且按功能场景做了分类比如引导流程、登录注册、支付流程、个人中心每个功能节点下都是一排排同类截图做竞品对比非常高效。Pageflows专注的是用户流程它把每个产品的关键路径按步骤串起来不是单张页面而是一条操作链适合研究用户从哪里进入、经过哪些步骤、最后完成什么目标。我举个例子。你在设计一个忘记密码的流程直接去Mobbin搜forgot password能看到几十个App的做法有的先验证手机号再重置有的先要求输入旧密码有的直接邮件重置。你会很快发现主流方案集中在两三种模式上这时候你的设计决策就不是拍脑袋而是有竞品依据的。这是单一页面素材给不了的东西。2.3 第三层设计系统与组件库很多人忽略这一层但它恰恰是提升原型规范性的关键。设计系统与组件库解决的是每种界面元素应该有几态、怎么组织语义的问题。常见的如Google的Material Design、Ant Design、Arco Design、Radix UI、shadcn/ui它们的文档站里不仅有组件长什么样的图还有完整的使用规则、交互状态、无障碍说明。你去看这些设计系统的对话框组件会发现它们的规范里会写清楚标题最长几个字、按钮主次怎么排、点击遮罩是否关闭、关闭后焦点去哪。这些细节恰恰是普通原型截图里看不出来的。所以我的习惯是当我在真实产品截图中看到一个细节想知道为什么这么设计时就去找对应组件库的说明文档。比如你看到一个复杂表格的行内编辑交互直接去Ant Design的表格组件文档里看它的交互规则说明可能比翻十张竞品截图更有收获。设计系统是原型背后那套看不见的逻辑。2.4 第四层国内社区与垂直媒体偏国内业务的场景我会去站酷、人人都是产品经理、少数派和即刻上的产品话题。站酷的强项是视觉表现适合看偏运营向、活动向的设计方案人人都是产品经理上会有大量产品拆解和复盘文章文字为主配合原型截图能帮你理解设计背后的业务思考少数派上有很多效率工具、App的深度使用分享经常附带作者自己梳理的交互截图和流程图即刻上的产品话题则更适合看正在发生的产品变化和行业讨论信息更新快能捕捉到一些平台背后的小功能迭代。这一层和前两层的区别是前两层看到的是界面长什么样这一层能看到为什么变成这样。比如一个小型协作工具改版后的复盘文章往往会讲清楚旧版哪里转化不好、新版为什么改成左侧栏加浮层、数据上有什么变化。这种前后对比的信息增量远远大于一张孤零零的界面图。3. 一个完整案例怎么用原型库反推SaaS邀请协作功能的方案看一百遍方法论不如完整走一遍拆解流程。下面我用一个最近做过的功能来演示为一个SaaS产品设计邀请成员协作功能。这个功能看着简单其实涉及权限、入口、反馈、付费边界等多个环节。我在动手之前专门花了一个下午泡原型库最后落地方案的速度比直接硬做快了不止一倍。3.1 先把要解决的问题拆成可收集的清单去翻原型库之前我习惯先把问题拆成一张收集清单。没有清单就去看很容易被漂亮的界面带跑。我当时列的问题是这样的邀请入口放在哪个位置是列表页右上角、空页面居中按钮还是设置页里的二级入口邀请方式有哪些支持邮箱、手机号、还是链接分享被邀请人未注册时怎么处理是跳转注册页还是允许先进入再用邀请链接激活权限怎么分配邀请人能否指定角色角色是预设还是自定义邀请链接的有效期多久有没有次数限制已邀请但未接受的状态怎么展示可不可以撤回邀请成功后反馈什么是弹窗、Toast还是直接跳转到成员列表拆出这些问题之后我的目标就非常具体了。带着这张清单去原型库找参考每一个案例都按这几个维度记录而不是看个大概。3.2 收集到六个参考案例后的对比表我最终从Mobbin、Pageflows和自己订阅的一些产品邮件里收集了六个相关案例Notion、Figma、飞书、Slack、Linear和一个比较垂直的项目管理工具。每个都按上面的清单记录了一遍。为了方便比较我整理成了一张类似下面的表格维度FigmaNotionLinear飞书Slack垂直工具入口位置成员列表右上角设置页成员区成员列表右上角工作台右上角成员管理页设置页邀请方式邮箱链接邮箱链接邮箱手机号邮箱邮箱链接邮箱未注册处理链接激活注册链接激活注册预创建账号手机验证码链接激活注册链接激活权限指定选角色选角色选角色选角色自定义选角色无角色有效期长期可撤销长期24小时自动过期长期长期可撤销7天待接受状态显示Pending显示Invited不显示显示已邀请显示Invited不显示成功反馈Toast列表直接更新侧边栏提示弹窗弹窗邮件Toast这张表做出来之后很多选择就变得很清晰。比如有效期这个维度Slack允许长期有效但可以随时撤销Notion也是长期可撤销而Linear直接做成24小时自动过期。为什么会有这种差异我复盘了一下Linear的定位更偏工程团队邀请链接应该短生命周期这个设计与其安全策略强相关而Notion更注重分享的便利性所以选择长期链接。这就给了我一个判断如果我们产品的用户是中小企业团队邀请便利性和管理可控性需要兼顾那比较合理的方案是默认7天有效可随时撤销而不是简单抄某一个产品。3.3 从案例中归纳出可落地的最小方案做完对比分析后我定的核心方案是这样的入口放在成员列表页右上角这是六七个参考案例中最主流的模式用户认知成本最低邀请方式同时支持邮箱和链接解决用户就在身边但不想输邮箱的场景支持指定角色但角色模板是预设好的不开放自定义第一期不需要增加配置复杂度邀请链接设7天有效期但列表里显示已邀请未接受的状态并允许管理员手动撤销成功反馈统一用Toast加列表状态刷新不弹大弹窗避免打断当前操作。这个方案里几乎没有纯靠想象的部分。每一步都能说清楚我参考了谁、为什么做了取舍。在内部评审时我直接放出对比表格告诉大家哪几个选项是行业主流、哪些功能第一版可以先不做理由是什么。评审几乎没有争议因为我们讨论的不再是我觉得应该这样而是多个成熟产品都是这样做我们在此基础上根据自身情况做了调整。这就是系统化看原型带来的直接价值。4. 看原型不等于抄原型我的四步拆解法收集资源只是第一步。真正能拉开差距的是拆解原型的深度。同样是看一个原型有人看完只记得界面挺好看有人能总结出这个产品的核心任务路径一共三步每步的退出率控制点在哪里。差别在于有没有一套自己的拆解方法。我目前比较常用的方法是四步拆解法介绍如下。4.1 四步拆解法目的、路径、反馈、边界第一步看目的。拿到一个原型页面先别急着看视觉而是问自己这个页面在整个产品里承担什么任务是促进转化、引导开通、还是帮助用户完成某个操作目的不同界面的很多决策就不一样。比如同样是登录页面向C端的产品会尽量简化输入环节面向B端的产品会把企业域名、SSO登录放到显眼位置成本较高但更安全。这一步能帮你判断这个原型设计得对不对。第二步看路径。把单张页面还原成一条操作链用户从哪里进来先看到什么第一次点击落在哪里之后往哪走完成目标要经过几个步骤。Pageflows这种工具就是专门干这个的。路径分析能让你看到这个原型设计真正花力气的地方可能不在页面本身而在于怎么让用户少走弯路。第三步看反馈。任何操作背后都有反馈。按钮点击之后是立即响应还是需要等待提交失败时给出什么提示数据加载时用什么骨架屏方案空状态有没有引导错误状态有没有解释原因和补救路径把反馈单独拎出来看你会注意到很多原型里容易被忽略的设计细节。尤其要重点看边界态键盘弹起遮挡、内容为空、网络异常、权限不足这些状态才见功力。第四步看边界。这个原型在哪里做了收敛和取舍。比如支付流程中为什么选择跳过确认页直接拉起支付可能因为产品发现多一步确认会带来更高的流失率也可能因为当时的合规要求还不完善。看到边界你就看到了一个产品的底线和它当前阶段的重心所在。4.2 记录工具与个人原型档案库搭建如果看完之后不做记录那前面的分析基本等于白做。我自己归档原型的做法分三层。第一层是即时收集层用的工具很简单就是浏览器的书签和系统自带的截图工具看到有意思的原型先截图存到本地临时文件夹或者收藏页面不追求第一时间整理。第二层是结构化归档层我每周抽半小时用Notion或FlowUs把这一周收集到的原型按场景归类比如详情页布局权限弹窗多步骤表单每张截图下备注一句话写清楚这个方案解决的是什么问题。第三层是主题复盘层当某个主题下攒了超过十个案例我会做一次对比输出一份类似上一节那种对比表格沉淀成可复用的决策文档。档案库不需要一上来就追求完美。我早期犯的错就是想把每个原型都整理得特别漂亮结果一周不到就坚持不下去。我自己的习惯是30秒原则截图加一句话备注的整理动作控制在30秒内完成超过30秒就先丢进暂存区。这样长期坚持的压力会小很多档案库自然越攒越厚。4.3 怎么把拆解结果转化成评审材料拆解结果如果只躺在自己的笔记里价值非常有限。它应该变成评审材料或者设计决策说明的一部分。我一般会做一个参考案例摘要格式是目标场景、参考产品清单、每个产品的关键做法、主流模式总结、我们的建议方案。一页纸以内能说清楚。做评审汇报的时候先讲主流模式再讲我们怎么选最后讲第一版边界在哪里。这种材料的说服力比单放一张竞品截图强得多。有一点要特别注意不要把竞品分析做成流水账。评审会不需要你把十个产品的做法逐一展开需要的是你归纳之后的方向判断。表格里的细节是支撑材料不是汇报主体。5. 踩坑记录与效率技巧长期坚持才能看到复利最后聊几个我在实际操作中踩过的坑和一些提升效率的小技巧。这些内容不太会出现在正式的方法论文章里但我觉得对实际工作帮助很大。5.1 常见误区不要掉进这五个坑第一个坑是只收藏不消化。收藏夹里存了两百个链接真正打开看过的不到十分之一。现在我的规则是收藏之前必须至少花一分钟浏览一下并写下一句为什么收藏它。写不出来的不收藏这能逼着你提高收藏门槛。第二个坑是过度追逐新案例。产品圈里每天都有人发新东西但真正值得研究的经典案例几年才会变一次。与其沉迷于追新不如把手头几个核心场景的经典原型研究透。我自己就有几个反复回看的旧案例每次看都能有新的收获。第三个坑是只关注头部产品。大厂产品的原型当然值得看但很多中小型产品在特定场景下的思考更接地气。比如一些垂直行业的SaaS工具它们的表单设计和权限处理往往比通用产品更值得借鉴因为这些团队资源有限、必须想清楚优先级。第四个坑是视觉导向过强。很多人看原型只看视觉风格好不好看忽略信息架构和交互逻辑。你要提醒自己产品原型的核心是结构和流程视觉只是外壳。信息架构乱的漂亮原型拿去借鉴只会害了自己。第五个坑是忘记差异化。参考案例看多了会产生锚定效应下意识觉得大家都这么做我也要这么做。这不对。同类方案确实代表主流认知但你的产品一定有自己的用户特征和业务约束需要在主流模式上做适配和差异。5.2 提高信息筛选效率的几条实操经验信息源的整理我推荐用RSS加邮件订阅的方式而不是每天盲目刷新各种社区。很多优秀团队和设计系统都有官方更新日志或博客直接订阅比偶尔刷到的效率高得多。比如一些组件库的GitHub release页面、设计博客的RSS都能稳定提供高质量信息。另一个经验是给自己设固定浏览时间。我每周一上午和周五下午各花三十分钟看原型资源时间一到就停。固定节奏比有空就看更容易养成习惯而且时间有限反而逼着你提高筛选效率不会陷进去浪费一两个小时。还有一个比较实用的小习惯用三句话笔记法记录看过的原型。看完一个案例用三句话写下——它解决的核心问题是什么它用什么方案解决的如果去掉其中一个设计细节会不会更简洁。三句话写下来说明你真的看懂了写不出来说明只是扫了一眼。5.3 最后落回做原型库是弹药库不是目的地看了再多原型最终还是要回到自己动手去画线框图、做交互稿。我看过不少同事陷入收集型学习的状态每天刷大量案例好像学了很多但真正打开设计工具时还是不知道怎么下手。我的建议是每看完一批原型就挑其中一个场景重新设计一遍。不需要做得很精细用线框图把信息架构、操作路径和关键反馈画出来然后把自己的方案和参考案例对比找差距在哪里。这个输入-输出的闭环才是看原型真正产生价值的地方。我也建议你在团队里顺手建一个共享的原型案例库大家把各自看到的好案例丢进去标注好应用场景和一句话点评。这件事的复利效应远比你一个人默默收藏要大。团队里每个人研究的领域不同看到的维度也不一样汇总在一起就是一套别人很难短期复制的团队知识资产。我现在的习惯是每季度回顾一次个人案例库把已经过时的方案挪走把新看到的案例补充进去。这个过程也会迫使我去反思最近一个季度的设计决策哪些是因为参考了足够多案例而变得更稳健的哪些还是拍脑袋做的想清楚这些问题下一个季度的成长路径就清晰了。看产品原型这件事从表面看是在看别人的东西本质上却是在为自己的每一个设计决策寻找更扎实的依据。把收藏夹当作起点而不是终点把每一次浏览转化为自己的判断力你慢慢会发现做方案的底气就是这样一点一点长出来的。