简介智慧水务在线监测系统原型图是一套面向水务信息化产品设计的高保真原型资源主要服务于智慧水务、水利信息化、城市排水监测等场景适合产品经理、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%不在视觉还原度上而是把一个模糊的“智慧水务”概念拆成了大家都能指手画脚的页面和逻辑。你让业务方看一张架构图人家大概率没有感觉你让业务方点一遍报警处理的交互流程他们立刻能告诉你这个按钮该放在左上角还是右下角。另外有一点值得多说一句这套原型的页面结构后面只要做适度裁剪也能迁移到其他行业可视化监管项目上设计思路本身是通用的这也是用原型驱动需求分析这件事最划算的地方。本文还有配套的精品资源点击获取