企业官网建设流程全解析

简介：智慧水务在线监测系统原型图是一套面向水务信息化产品设计的高保真原型资源，主要服务于智慧水务、水利信息化、城市排水监测等场景，适合产品经理、UI设计师、前端开发者及水务行业方案规划者参考，用于快速理解水务监测平台的页面结构与交互流程。压缩包共1353个文件，整体约3.35MB，主要包含732个png设计图、210个js脚本、183个html和181个css文件，另有少量svg图标与gif动效，并附一个crx扩展插件；其中png可用于设计评审与视觉参考，html/css/js组合可直接在浏览器中体验页面效果，svg和gif则补充了图标与动效细节。资源功能覆盖较完整，页面层级与监测模块划分清晰，几乎涵盖了从登录、总览到具体监测点详情的主要场景，能够直接作为新项目初稿或需求沟通底稿，减少从零搭建页面的时间。目前已有2917人学习下载，适合正在搭建智慧水务类看板、大屏或后台管理系统的团队快速起步。

1. 写在这一版原型之前：最初的需求拆解

做智慧水务在线监测系统，不是画几张看板、拉几条曲线就完事。很多时候甲方给的需求就一句话——“我要能看到实时数据，要有报警，要做大屏”。但这句话背后藏着一串问题：监测什么指标？数据从哪来？谁来用这套系统？调度中心看什么、水厂值班员看什么、管网巡检员又在手机上看什么？

这套原型图最初的定位很明确：覆盖从水源到水龙头的全链路监测场景，重点解决三件事——让水厂能实时掌握生产运行状态，让管网管理人员能快速定位异常片区，让决策层能看清供水趋势和风险。所以原型里不只有大屏，还包括Web管理端和移动端页面，三端联动，才是一套能落地的产品方案。

第一轮梳理下来的功能清单是这样的：

• 水源地监测：取水口水位、原水浊度、pH值、溶解氧等
• 水厂监控：进出厂流量、出厂压力、清水池水位、加药间状态
• 管网监测：主干管流量、压力、水质余氯/浊度、漏损估算
• 二次供水监测：小区泵房压力、水箱液位、设备运行状态
• 报警中心：多级别报警、派单、处置跟踪
• 数据报表与分析：历史曲线、日/月/年统计、趋势预测

当时团队内部有一个争议点：到底做不做巡检工单？做完分析后我们坚持做，不给钱的诉求太强烈——一旦压力异常报警，系统里得有一个闭环让线下人员去确认、上报、消警，否则报警永远只是屏幕上的一行红字。虽然工作量多了30%，但这正是甲方验收时最关注的“业务完整性”。

2. 页面结构与导航设计

2.1 角色权限决定页面层级

原型设计的第一刀，永远是角色。超级管理员、调度中心值班员、水厂运行工、管网巡检员，这四个角色看到的页面完全不一样。调度中心要的是全局态势和报警处理，水厂运行工要的是机组参数和工艺曲线，巡检员要的是任务列表和现场上报入口。

所以在原型左侧导航里，我按角色把功能做了分组。登录页下方预留了角色切换入口（原型阶段用动态面板模拟），方便演示时快速跳到不同类型用户的视角。首页默认展示调度中心视角，这也是Demo演示时最有视觉冲击力的一屏。

2.2 关键页面之一：综合态势大屏

大屏是整个系统的门面。12:7的1920分辨率看板，第一屏放四个核心指标卡：当日供水量、管网平均压力、水质达标率、当前报警数。这四个数字分别对应生产、调度、水质、安全四个维度，任何一项异常都值得管理者立刻关注。

中间区域是管网GIS地图，地图上做打点，点的颜色按压力状态区分——绿色正常、黄色预警、红色异常。点击任意监测点弹出详情浮窗，展示该点的实时数据、最近24小时曲线和关联报警记录。这里有一个小细节：弹窗不盖住地图的关键区域，位置做了偏移算法，虽然原型阶段只是静态效果，但交互评审时非常加分。

右侧是报警滚动列表，按时间倒序，显示报警级别、点位名称、报警类型、处理状态。下面接了一张近7天供水量趋势图，按小时聚合，让值班员一眼看出今天的供水高峰是不是按时段到来。

2.3 关键页面之二：实时监测列表

大屏解决“看全局”，列表页解决“查细节”。表格按监测点维度展示，列包括点位名称、所属水厂/泵站、监测指标值（流量、压力、余氯、浊度、pH）、更新时间、设备状态、操作按钮。

这一页有个设计上的取舍：指标太多，全铺在表格里会很挤。我们的做法是每个点位只展示最重要的三个数值，其余指标点击点位名称后进入详情页查看。同时行内增加“趋势”小图标，点击直接预览最近24小时的迷你曲线，不用跳转页面就能快速判断数据走向。

顶部筛选区支持按片区、监测类型、设备状态过滤，关键词搜索点名称和编号。所有筛选条件可以组合使用，最多支持五个条件的叠加，基本覆盖了日常查询的所有场景。

2.4 关键页面之三：报警处理闭环

报警页面我单独拿出来说，因为这是业务逻辑最重的模块。列表按四种状态划分：未处理、处理中、已处置、已关闭。报警级别用红橙黄三色标识，严重报警直接置顶，标注“超时未处理”标签。

点击报警记录进入详情，除了点位信息和实时数据，还有完整的处置时间线——谁接单了、什么时候到现场、现场情况如何、做了什么操作、什么时候恢复正常，每一步都有记录和留痕。页面上方预设了几条处置结论快速回复，线上人员可以少打字直接勾选，这是个很实用的小功能，被甲方夸了好几次。

3. 核心原型细节：从布局到交互

3.1 配色、字体与状态颜色规范

水务系统的配色不宜花哨，蓝色系是行业共识，但我们刻意避开了深蓝配亮蓝的“科技感模板”，改用偏青色的浅蓝作为主色调，搭配深灰文字和白色卡片背景。大屏端由于展示环境通常是昏暗的大厅，底色用深色系，地图区域亮度降低，保证数据文字的高对比度。

状态色是整个原型的隐性规范：绿色代表正常、黄色代表预警、红色代表异常/报警、灰色代表离线或停用。这套颜色规则在所有页面保持一致，包括地图打点、表格状态标签、曲线图图例、大屏指标卡，都在全局样式里统一维护。后面开发切图，前端拿到样式规范直接落地，基本没有返工。

3.2 图表选型与数据呈现逻辑

图表是这个项目的重头戏。折线图用于流量、压力、水位等趋势数据，柱状图用于日/月供水量对比，饼图或环形图用于报警类型分布，散点图用于压力与流量的相关性分析。地图直接用的百度地图底图，叠加自绘监测点图层。

这里有一个经验分享：折线图的纵轴标签必须带上单位，且在不同点位数据量级差异较大时，做成统一量纲显示会比自适应量纲更适合值班员快速横向对比。原型阶段我把“单位固定”直接写在交互说明里，开发实现时省了很多沟通成本。

3.3 动态面板模拟的交互效果

Axure原型里用动态面板做了几个关键的动态效果：大屏指标卡的数字每隔3秒自动刷新（模拟实时数据推送）；报警列表新报警出现时整行高亮闪烁两次；地图打点根据状态切换颜色；点击压力异常点位时，页面下方自动展示关联的最近报警记录。

这些交互虽然只是演示效果，但在需求评审会上非常有用。业务方看到“闪烁”这个动作，就会说“报警能不能同时弹声音”，看到“自动刷新”就会问“数据延迟多少秒”——需求就是在这样一问一答中被逼出来的。原型不只是展示给客户看的，更是双方对齐认知的工具。

4. 数据结构设计与多端适配

4.1 监测点位与指标编码规范

这是最容易被人忽略、但坑最深的地方。如果给每个监测点单独建立表结构，后面每加一个点就要改代码，数据表也会膨胀到不可维护。正确做法是抽象出点位表和指标表，点位表记录“在哪测”（位置信息、所属区域、设备型号），指标表记录“测什么”（指标编码、数值、单位、采集时间）。

指标编码必须全局唯一且有意义，比如FLOW_01代表流量、PRESS_02代表压力、CL_RES代表余氯。这套编码会贯穿从设备接入、数据库存储、前端展示、报表导出的全部链路，一旦发布再改就是大事故。

4.2 大屏、Web、移动端的信息降级

同一个监测点，在三端展示的信息量完全不同。大屏只需要一屏总览加关键报警；Web端要能层层钻取，从片区到具体点位再到底层设备的全部参数；移动端只有最核心的数据卡片、报警推送和现场上报功能，页面极简，按钮大，方便戴着手套操作。

移动端不做趋势分析，因为手机上看曲线既费流量又费眼睛，统一用“最近30分钟状态滑块”替代——绿黄红三色条表示当前状态，点击进入报警详情，5分钟内能完成一次现场处置操作。这套信息降级规则在UI设计稿定稿前就已确定，三端设计并行推进也没有出现风格和内容割裂的情况。

4.3 大屏端页面适配要点

做监控大屏原型还要考虑分辨率适配。大多数项目用1920x1080的横屏，但我们也遇到过拼接屏方案，实际分辨率是5760x1080（三块屏拼起来）。这种情况下最好不要把内容铺满整个宽度，而是把视觉中心集中在中间三分之一，两侧放辅助信息区域，或者做成焦点屏加扩展屏的分屏方案。

字体大小也有讲究：大屏上表格正文字号不得小于16px，关键指标数字不得小于28px，否则两三米外完全看不清。原型阶段虽然不需要真实切图，但这些标注一定要写清楚，不然前端默认按Web标准做，现场投上去就是一团糊。

5. 原型文件的组织与交付注意事项

5.1 目录结构、版本管理与文件说明

原型图以zip压缩包形式交付时，我见过太多随手塞几个rp文件就发出去的，收件人根本分不清哪个是最新版。我的做法是固定这套目录结构：

智慧水务在线监测系统原型图/ ├── 00_需求说明/ (PRD文档、评审纪要) ├── 01_Web端/ │ ├── 1.0_综合态势大屏.rp │ ├── 1.1_实时监测列表.rp │ ├── 1.2_报警中心.rp │ └── 1.3_数据报表.rp ├── 02_移动端/ │ ├── 2.0_移动端原型.rp │ └── 页面标注说明.md ├── 03_UI切图/ └── 04_版本更新记录.txt

版本更新记录是重灾区，但也是最值得写的文件，每次改了什么、谁改的、什么时候改的，一句话记录，两个人以上协作时能省掉无数撕扯。

5.2 文件命名、附件资源与启动检查

rp文件命名必须带版本号，例如“智慧水务Web端原型_v2.3_20240915.rp”，不需要加“最终版”“最最终版”这种谁看了都迷糊的字样。原型中引用到的外部图片、图标、地图示例数据，统一放在“资源包”文件夹里，在原型文件中用相对路径引用，不要用绝对路径，因为换电脑打开会导致资源丢失。

交付前最后一件事：用一台没有安装Axure的干净电脑验证浏览器输出的HTML文件能否独立运行。很多原型用到了外部字体、地图接口或者自定义组件，源文件打开一切正常，但生成HTML后丢资源或接口报错。这个坑我至少踩过三次，现在每次发版前都固定跑一遍无环境启动测试，确认双击.html文件能正常显示所有页面再压缩打包。

5.3 打开原型Zip常见的两个问题

压缩包发出去之后，收到最多的问题就是“低版本的Axure打不开”。比如源文件是用Axure RP 10画的，接收方用的还是RP 9，直接提示版本不兼容。解决方法是交付时同时导出两种格式：高版本rp源文件加一份兼容版rp，再加一份HTML预览文件。HTML在任何浏览器都能打开，不装任何软件也能先看效果，一般业务方用这个就够了。

另一个常见问题是解压后路径带中文且层级过深，导致浏览器加载资源失败。建议压缩包内第一级目录就用短名称，比如“sw_hj_web”，所有文件路径总长度控制在100个字符以内。Windows系统常见的zip解压报错基本都是路径过长引起的。

6. 实操经验：三端设计中最容易翻车的地方

第一处想提醒的是地图过大拖慢原型。大屏页面的地图渲染在Axure里一般用图片代替，但高清截图加上点位标注之后，整个页面文件可能超过50MB，打开一次要转半天。我的做法是地图只截取核心区域，在“交互说明”里写清楚真实系统需要接入的地图服务和点位数据结构，给开发看文档而不是看图片，双方都轻松。

第二处是导航层级不要超过三层。水务系统功能很多，但原型阶段一旦菜单层级超过三层，业务方就会迷失在页面里，问题往往集中在“我刚才看的那个页面去哪了”而不是功能本身。这次设计我们强制规定所有页面最多三次点击到达，超过的规划一律打回重新设计，这个规则在原型评审中帮了大忙。

第三处是关于报警规则的逻辑，一定要在原型里画一遍。什么时候触发预警、什么时候升级为严重报警、持续时间超过多少分钟算告警、同一点位重复报警的合并策略是什么，这些逻辑如果不画出来，开发实现时就会自由发挥。原型里用页面流程图配合文字说明把规则列清楚，比后期上线再改要便宜一百倍。

根据我个人的体会，原型图对水务这类行业软件项目的价值，80%不在视觉还原度上，而是把一个模糊的“智慧水务”概念拆成了大家都能指手画脚的页面和逻辑。你让业务方看一张架构图，人家大概率没有感觉；你让业务方点一遍报警处理的交互流程，他们立刻能告诉你这个按钮该放在左上角还是右下角。另外有一点值得多说一句：这套原型的页面结构，后面只要做适度裁剪，也能迁移到其他行业可视化监管项目上，设计思路本身是通用的，这也是用原型驱动需求分析这件事最划算的地方。

本文还有配套的精品资源，点击获取