我前段时间负责一个在线课程平台的WebApp设计第一次交稿的时候拿过去一百二十多张高保真页面。开发同事看完之后只问了一句你这些页面之间用到的字段能保证是同一条数据吗我当场愣了一下——课程详情页里我写的“老师简介”列表页里写成“导师介绍”同一个实体三种叫法字段长度还不一样。这就是典型的掉进了“画页面”的坑而不是先“建模”。这篇文章我想把后来沉淀下来的一套方法完整讲透WebApp设计里最值得先做两件事——内容模型Content Model和数据树Data Tree在这个基础上再补一份交互模型Interaction Model。它们分别解决“数据怎么定义”“页面怎么组织”“用户操作怎么跑通”这三个不同层级的问题。做产品、UX、前端架构的人都可以直接套用尤其是那种业务逻辑稍复杂的WebApp建模先行能少走很多弯路。1. 先想清楚一件事建模到底在解决什么1.1 WebApp设计最大的坑从页面出发而不是从数据出发很多人做WebApp设计的第一步就是打开Figma拉画板开始画首页、列表页、详情页。画到几十张以后问题就来了同一个“课程”对象在首页、列表页、搜索页、详情页、个人中心里长得完全不一样但你很难判断它们是不是同一份数据一个按钮点了之后页面变成什么样完全靠猜。WebApp和传统官网最大的区别在于它本质上是一个“有状态的应用”。用户要登录、要下单、要收藏、要学习、要同步进度数据在多个页面之间流动而且很多数据还要写回服务器。单张页面稿能描述“长了什么样”但描述不了“从哪来”“到哪去”“什么时候变”。我在那个课程项目里就是先花了两周画页面结果三分之一要返工。真正把我拉回来的是一个特别朴素的思维转换先别管页面长什么样先讲清楚系统里有哪些对象、每个对象有哪些字段、对象之间什么关系、用户可以在哪些节点上做什么操作。这就是建模。1.2 内容模型、数据树、交互模型的分工与关系三个模型分头解决三个问题内容模型Content Model定义业务对象。比如课程、章节、订单、用户都有哪些字段类型是什么谁和谁是父子关系。数据树Data Tree定义内容在界面上的组织方式。它把内容模型里的实例按用户导航的视角排成一个树形目录对应路由、页面层级、入口。交互模型Interaction Model定义用户操作与系统响应。它描述每个动作的前提条件、成功路径、失败路径、反馈和状态迁移。我的经验是它们不是三个孤立文档而是同一个系统的三个视图。工程师拿到内容模型知道建哪些表、API返回哪些字段拿到数据树知道路由怎么挂、导航高亮怎么算拿到交互模型知道什么时候拉数据、什么时候按钮可点、请求失败怎么兜底。三个视图对得上页面自然就长得一致了。1.3 一个生活化类比盖房子要分开画好几张图纸我用盖房子来类比这三个模型你一下就懂了。内容模型是“材料清单”和“结构计算书”——你得知道有哪些材料、承重墙在哪、多粗的梁数据树是“户型图”——每个房间安排在哪、动线怎么走交互模型是“水电图”——哪里开关、哪里出水、电流怎么走。效果图呢那只是最后给人看的渲染图。很多团队的问题就是把效果图当成了全部设计产出。效果图当然重要但如果没有材料清单、户型和管线图施工队干到一半就会来问你这堵墙上面有没有电线这门是内开还是外开开发问你的就是这个列表传的是id还是整个对象字段叫什么所以我强烈建议正式画高保真之前先花半天到一天把内容模型、数据树、交互模型第一版理出来。下面两章先说内容模型和数据树这是WebApp设计中最关键的两套建模方法。2. 内容模型把每个业务对象拆成可执行的字段契约2.1 识别业务实体与服务关系建内容模型第一步不是设计字段而是找出系统里有哪些“实体”。实体就是在业务上需要长期记录、反复展示、跨页面引用的对象。拿课程平台来说至少要拆出这些实体用户User、课程Course、章节Chapter、课程订单CourseOrder、学习记录LearningRecord、评价Review、优惠券Coupon。拆完之后要给实体之间的关系定性。课程和章节是一对多用户和课程订单是一对多课程和用户通过订单形成多对多章节和学习记录又是一对多。这个关系定得对不对直接影响数据树怎么挂页面。比如“我的课程”页面本质上是“用户→课程订单→课程→章节”的链路上取数据而不是凭空造一个CourseList。关系理错页面之间的跳转参数就会乱开发到后期一定会找你吵架。我见过太多团队在这个环节偷懒直接跳过实体建模开始画页面结果后端同学来问你这边的“我学的课程”和“我买的课程”是什么关系是同一个接口还是两个接口这种问题在建模阶段就该有答案。2.2 字段设计六项原则实体定完就开始定字段字段是内容模型的最小单位。这里有一套我总结的六项检查原则每定一个字段都对一遍命名统一同一个字段全站同名同义不允许一会叫teacherName一会叫authorName。类型明确是字符串、数字、布尔、日期还是数组、对象引用必须唯一。可空性明确这个字段能不能为空空的时候界面怎么显示。有默认值比如课程的排序值、状态的初始态不给默认值后面所有页面都要判空。枚举要受限比如课程状态只能是草稿/已发布/下架不能自由填。派生字段慎重像“销量”“评分”这类可以通过其他数据算出来的字段尽量别直接冗余存储优先走接口计算。这里我特别强调一下命名统一。返工项目里最大的隐性成本就是命名漂移。页面稿上写“讲师”、代码里写teacher、接口里写lecturer三方对不上联调时全靠人肉翻译越到后期越痛苦。2.3 从内容模型到页面字段落位内容模型定完之后还有一个很容易被忽略的动作把字段映射到页面。每个字段最终在哪些页面出现、用什么级别的容器展示需要单独列一张映射表。以课程实体为例它的字段至少包括课程ID、标题、副标题、封面图、简介、价格、讲师、评分、状态、发布时间。这些字段并不是每个页面都要全量展示。课程列表页只需要标题、封面、价格、评分详情页需要全量字段再加章节列表支付确认页只需要订单号、课程名、价格、支付方式。这张映射表的真正作用不是给自己看而是给前端和后端定接口边界列表接口只返回列表页会用到的字段详情接口返回详情页的完整字段。如果你不建模就画页面开发就会把详情接口的所有字段拖到列表接口里一个接口变成一个巨型对象页面性能越来越差。2.4 进阶把“视觉内容上下文”也纳入建模范围最近我在团队里推一个新概念搜索热词里叫“视觉内容上下文模型”Visual Content Context Model。它回答的是这么一个问题同一条内容数据在卡片、列表、详情页、弹窗这些不同容器里应该露出哪些字段、截断多长、按什么比例显示。我举个例子你就明白了。课程简介列表页显示两行、40个字详情页显示完整五百字支付弹窗侧边又要显示一行、15个字。如果只在内容模型里定义一个intro字段开发拿到手根本不知道不同场景的截断规则。视觉内容上下文模型就是在内容模型之上给每个“字段-容器”组合定义渲染上下文包括文本长度、图片比例、是否加粗、空值占位符。实操时我通常以二维表格维护。左列是字段顶部是容器表格里填写该字段在对应容器的显示规格。这就是“视觉内容上下文”的落地形态。有了这张表前端不需要自己发挥后端也不会多传无用字段尤其适合团队里同时有多个业务方共用一套内容数据的场景。3. 数据树信息架构的骨架图3.1 什么是数据树内容模型实例化的目录结构如果把内容模型看成词典数据树就是目录。它用一个树形结构表达用户视角的内容组织逻辑树的每个节点对应一个真实的页面、分支或数据分组。核心节点之间通过“父-子”关系连接背后往往就是内容模型里的实体关系。数据树要做的是把所有内容模型里的对象按用户找内容的动线挂到一棵树上。比如课程平台的树可以是从首页出发分出“课程广场”“学习中心”“个人中心”再往下是“课程分类”“课程列表”“课程详情”这样的层级。数据树的作用在于它强制你回答一个问题用户在哪个入口通过哪条路径能找到他需要的内容和操作。这棵树的打磨过程其实就是信息架构的打磨过程。一个WebApp里页面再多数据树都应该是有限的、稳定的如果树上的节点越画越多、越来越乱那说明内容模型本身可能没建模好而不是页面不够多。3.2 三步搭建数据树顶层入口-业务分支-操作节点我在实操里搭数据树分三步。第一步理出核心用户任务。比如课程平台核心任务就有找课、看课、买课、学习、查订单。每个任务对应一个顶层入口或者一级分支不是核心任务先别放进来。第二步把每个任务拆成导航主链路。拿“买课”来说主链路是“课程广场→课程详情→订单确认→支付结果→我的课程”这条链路上的每个环节就是一个数据树节点节点之间顺序就是跳转关系。第三步给每个节点补上内容模型中的所属实体做校验。如果一个节点在设计时找不到对应实体那它不是还没建模就是状态页或中间页。校验通过后再把节点翻译成路由表、页面清单和导航高亮策略这些就是给开发的实际产出。3.3 数据树深度的经验阈值与反模式数据树的层数我建议控制在三层以内超过三层尽量用“Tab切换”或者“面包屑抽屉”来降级。树太深用户会迷路而且URL会变得又长又丑分享链接的体验也很差。更要警惕的是两类反模式。第一类是把权限当层级同一棵数据树根据用户的角色不同自动加减分支这不是数据树该干的事应该在路由层做权限控制而不是在每个层级上复制页面。第二类是把操作当节点比如“提交订单”是一个动作不是一个页面它不应该作为一个叶子节点挂在树上。数据树上的节点本质上是“有内容、有地址、能到达”的页面或数据分组不是按钮不是弹窗更不是状态。数据树还有一个直接产出是URL设计。每一条从根到叶的路径都对应一组URL路由参数。树结构理清了路由表、面包屑、404页跳转逻辑才能一次性定清楚否则后期会反复改导航高亮和回退逻辑。这也是我坚持先画数据树再画高保真的原因。数据树对完页面之间的跳转关系基本不会再有大的返工。4. 交互模型让WebApp从静态结构转向可运行系统4.1 交互模型的核心三要素状态、行为、反馈很多人以为交互模型就是画流程图把用户点几下、跳哪个页面画出来。这个理解太浅了。我理解的交互模型核心是三个东西的组合状态、行为和反馈。状态是系统在某个时刻可观察的事实比如“订单已支付”“课程学习中”行为是用户或系统产生的动作比如点击、提交、定时轮询反馈是这个动作之后系统给出的可见响应包括加载、成功提示、错误提示、按钮置灰、页面跳转。三者的关系可以这样概括交互模型就是在定义“给定某些状态哪些行为被允许每个行为触发后系统如何改变状态并给出什么反馈”。它不是页面流程图而是系统的行为契约。拿支付环节来说你光知道“用户点支付按钮跳转收银台”是不够的你还需要知道“订单已经在支付中再点一次支付怎么处理”“回调通知失败了怎么办”“支付结果页突然断网怎么展示”。4.2 用状态机描述关键业务对象交互模型最有效的落地方式是对核心业务对象画状态机。状态机描述的是一个对象在生命周期里可以在哪些状态之间迁移每个迁移需要什么前置和动作。课程平台里肯定要画的是CourseOrder的状态机状态至少包括待支付、已支付、学习中、已完成、已关闭。迁移规则是待支付→已支付支付成功回调已支付→学习中首次进入课程学习中→已完成全部课时学完待支付→已关闭超时未付已支付→已关闭申请退款成功。状态机的价值在于它能把异常分支逼出来。你画完状态图就会发现很多页面设计时必须处理的分支比如已关闭的订单对应的课程详情页应该是按钮置灰、显示“已下架”而不是还挂着“立即报名”。这就是状态视角对页面设计的约束。我建议在建模文档里用文本化状态机而不是画复杂图形因为文本可以在评审会上快速讨论修改也方便交接给工程师。工程师拿到状态机直接就能对应到接口状态字段和前端状态管理逻辑。4.3 输出交互规则表每个操作都写成可测试的用例状态机负责全局轮廓具体到页面上的每个操作我还会输出一份交互规则表。这是WebApp能不能稳定可测的关键也是交互模型最常被人忽略的部分。表格就是四列加一行操作、前置条件、成功路径、失败路径。比如课程详情页的“立即报名”按钮至少要有这几行规则操作点击“立即报名”前置条件已登录、课程状态为“已发布”、当前用户无有效订单成功路径弹起订单确认层确认后创建订单跳转收银台支付成功后跳转学习中心失败路径未登录则弹出登录框课程已下架则按钮置灰并提示“课程已下架”已有订单则提示“你已购买该课程去看看”每条规则配上成功和失败的反馈文案这一页才算真正设计完。我用这个方法倒逼自己把所有页面的交互都过了一遍发现至少20%的分支在初稿里是漏掉的都是在写交互规则表的时候才补上。所以交互模型不是“画完流程就行”它必须细到每个操作的可测试粒度。4.4 内容模型是怎样驱动交互模型的这里有个很容易犯迷糊的点内容模型和交互模型的边界。我经常被问到课程状态到底是内容模型的事还是交互模型的事答案是课程状态字段本身归内容模型管状态的变更规则和由此引发的界面反馈归交互模型管。也就是说内容模型提供交互所需的“状态数据源”交互模型消费这些数据驱动界面变化。还是拿课程状态举例子内容模型里定义了status字段的枚举值是草稿、已发布、下架交互模型里定义了“已发布的课程详情页显示立即报名按钮下架的课程显示暂停销售文案草稿状态的课程不出现在任何前台入口”。前者定义“有什么”后者定义“什么时候显示什么”。在团队协作里这种分工特别重要。后端问你数据库要不要存is_paying这种字段你说不用因为“是否正在支付”是前端交互状态不是业务数据状态。存了反而会制造脏数据。内容模型和交互模型分清之后很多这类争论直接消失。5. 完整案例课程平台的课程购买与学习闭环5.1 第一步内容模型产出为了让你看得更清楚我用前面那个课程平台做一次完整建模的演示。核心业务对象先定四个User、Course、CourseOrder、LearningRecord外加一个支撑性的Chapter。CourseOrder的字段可以这样设计字段名类型可空说明order_idstring否订单号业务主键user_refref(User)否下单用户course_refref(Course)否购买的课程order_statusenum否待支付/已支付/学习中/已完成/已关闭total_amountnumber否实付金额coupon_refref(Coupon)是使用的优惠券可空create_timedatetime否下单时间pay_timedatetime是支付时间未支付为空注意order_status这个字段它就是第4章里状态机的数据源。交互模型引用它来定义按钮和页面状态但改动它的规则只归交互模型管两者靠“同名同义”的约定对齐。5.2 第二步数据树产出搭建数据树之前先想用户任务找课、买课、学习、查订单。对应地数据树就长这样首页 ├─ 课程广场 │ ├─ 分类筛选 │ │ └─ 课程列表页 │ │ └─ 课程详情页 │ └─ 搜索 │ └─ 搜索结果页 │ └─ 课程详情页 ├─ 学习中心 │ ├─ 我的课程 │ │ └─ 课程学习页 │ │ └─ 章节内容页 │ └─ 我的收藏 └─ 个人中心 ├─ 我的订单 │ └─ 订单详情页 ├─ 优惠券 └─ 账户设置这棵树每一层基本都在三层以内并且每个叶子节点都能直接在内容模型里找到对应的实体和字段。课程详情页在两个分支下出现这没问题它是同一个数据树节点的复用而不是复制两份页面。导航高亮策略也由此确定在“课程广场”分支和“学习中心”分支进入同一个详情页时顶层Tab的高亮应该由上一级入口决定而不是详情页自己决定。5.3 第三步交互模型产出交互模型的重点是CourseOrder的状态机和关键操作路径。状态机我已经在4.2节里写过这里展开一个最核心的操作路径报名购买。操作前置条件成功路径失败路径点击“立即报名”已登录课程status已发布user无有效订单创建订单→跳转支付→支付成功→进入学习中心未登录弹登录框已下架置灰提示重复购买提示去学习进入“课程学习页”存在有效已支付订单展示章节列表记录首次学习时间无有效订单跳转课程详情页课时完成当前课时状态学习中写学习记录下一课时解锁全部完成则订单状态变已完成网络异常写失败提示重试这张表的每一行都可以直接转成前端组件的可测试用例。开发拿到它不需要反复问产品“这里失败了怎么办”自己就能把分支写全。我习惯在交互表里再补一列“失败反馈文案”因为差一个提示文案都会导致前端返工。6. 实际项目里的高频问题与避坑清单6.1 内容模型过度设计能共用的字段却在复制建模到中期很容易出现的一个问题是实体多到失控。最常见的原因是每个页面都想独占字段于是给Course复制出CourseCard和CourseDetail两个对象字段还不一样。这样内容模型就失去了“单一数据源”的意义。我建议每新增一个实体或字段前先问三个问题这个字段在全站其他页面有没有同名同类能否复用已有实体存储它是不是为了视觉上的方便如果只是为了展示方便应该交给视觉内容上下文模型去约束而不是再造一份数据。6.2 把交互状态误当成数据字段另一个高频坑是把瞬时交互状态塞进了后端数据模型。比如isPaying、isSubmitting、isValidating这类字段它们描述的是“界面此刻在干嘛”不是业务事实不应该作为后端字段持久化。判断标准是如果断网或刷新之后这个状态应该消失那它就不该进内容模型只该进交互模型的前端状态管理。我见过团队在数据库里存is_paying导致同一订单状态反复错乱最后花了两天清理脏数据。这个坑提前建模完全可以避免。6.3 空数据、异常状态和弱网条件的建模缺失内容模型和数据树往往只覆盖主体业务数据空数据、弱网、超时这些“边缘情况”在建模时不写开发阶段就会各种临时补丁。订单列表为空时的页面、搜索无结果时的页面、支付回调延迟时的中间态页面这些都应该在建模阶段就给一个显式的设计位置。我的经验是在数据树上用虚线挂“空状态页”在交互模型里给每个状态迁移补一个“超时/失败”分支。页面设计里宁可没有图也要有文案和兜底操作这是WebApp能不能撑住真实用户考验的分水岭。6.4 模型文档如何避免烂在文档库里建模最怕的是文档写完了没人看三个月后变废纸。我在团队里强制要求每次相关需求评审和接口联调都必须带上内容模型字段表和交互规则表的最新版本页面或者接口改了表必须同一次提交里更新。产出一开始放在在线文档里后来干脆把字段表和交互规则表挪到代码仓库的docs目录跟着每次迭代一起评审一起更新。这样一来模型文档就不是摆设而是活的契约。页面可以改一百遍只要模型文档跟着改项目就不会乱。最后整理一张排查速查表你建模的时候可以直接对着自查问题症状根因处理动作页面字段同名不同值内容模型未收敛统一命名用一份实体字典导航层级超过三层数据树过长用Tab或抽屉降级同一功能多处实现数据树复制节点收敛为共享节点按入口区分按钮状态说不清交互模型未写前置条件补交互规则表接口字段越来越多页面级临时加字段回到内容模型审查复用性空数据页面总漏建模没覆盖边界情况在数据树挂空态页面我在实际项目里最大的体会是建模做的不是一次性的大规模设计而是建立一套“数据如何定义、内容如何组织、交互如何反馈”的共识机制。页面会骗人模型不会。内容模型和数据树是WebApp设计的承重墙交互模型是让这栋楼能通电出水的水电图纸。开工之前花一天把三张图理出来后面省下的时间至少是画图的十倍。如果你现在手头正好有个WebApp要设计别的可以缓内容模型字段表和一张不超过三层的草图数据树请务必先画。