要想做好智慧园区的体验设计，我们需要从多个维度出发去做考量，因为其业态内容是十分复杂的。这篇文章里，作者就从产品业务模式、需求层次、应用构成、典型需求四个方面展开论述，一起来看一下。

智慧城市的概念与前景已遍及生产生活的各个方面，园区作为智慧城市最具典型的生产代表，它的运作模式与发展探索中所面临的问题，可反哺我们对于智慧化空间的顶层设计研究及思考，以便我们更加全面地进行园区的数字化产业升级。

在园区这类空间表现形式中，因其丰富且庞杂的业态内容，蕴含了大量不同场景下空间与人、人与人、人与物、物与空间等的复杂交互。无论从园区管理、运维还是经营的角度出发，均需我们站在各个不同维度去洞察体验环节中的各类痛点，从而辐射至各类不同形态的空间体验设计及智慧城市的建设中。

下面从智慧园区的产品业务模式、需求层次、应用构成、典型需求四个方面展开论述。

一、智慧园区的产品业务模式

抛开过多的复杂定义与部分行业垂直特殊性，目前智慧园区的产品业务模式大致可分为两类。

1. 企业自研产品

此类为较大规模的企业为达到降本增效之目的，也为了企业所涉及到的各类空间在自动化的基础上更加智能化、可持续的发展，企业根据自身的实际需求，对已有的例如楼宇管理、消防、安保、办公、通信等自动化系统进行重新整合，最大程度地规避信息孤岛问题，形成一个综合、互通的平台级应用产品。

较大规模企业一般都拥有经验丰富且专业的产研团队，以伊飒尔服务过的京东方为例，他们便是在完成企业自身的园区数字化升级后，也将同样的服务提供于采购他们硬件产品的客户，加强促进园区内的软硬件结合，进一步形成产品服务的生态闭环。

此类因定制化程度较高，属于企业的基础服务建设。它以需求为导向，更加适用于企业自身的切实需要。体验设计师的侧重点应聚焦于深入了解各类用户需求、了解产品应用间的耦合关系、对不同系统与功能进行融合等工作。

2. 解决方案服务产品

此类为看中智慧园区行业的潜能与前景，以提供综合的数字化解决方案为核心业务的企业。他们可以为不同属性、不同需求的园区提供定制化的产品服务。这要依托于其持续性地对不同形态园区的痛点进行洞察分析，深入了解底层基础需求，经过专业的设计与验证，从而形成自己的产品体系。

此类企业对于智慧园区的服务形式、内容都具有较为垂直且深入的研究，是以产品内容与服务为导向的。这类产品对于体验设计的要求较高，既要保证产品应用层面的普适性，同时也要确保不同的产品功能顺利组成新的应用产品。体验设计师的侧重点应聚焦于产品系统中基础需求的拆解与重组、模块功能架构与任务路径等设计工作。

二、智慧园区的需求层次

若将智慧园区的建设与发展拟作有阶段性需求的个体，参照马斯洛需求层次理论（Maslow’s Hierarchy of Needs）可大致分为三层，即基层的安全、第二阶层的运维以及第三阶层的经营。

无论园区以何种形态发展，又发展至何种阶段，以较高维度出发，它将帮助我们了解无论在何种业务模式或商业模式中挖掘业务及产品重点。从基础层面思考，可在我们进行产品设计时，辅助我们进行需求排期、确定问题处理的优先级等工作，这些均与园区的需求层次密切相关。

三、智慧园区的应用构成

园区在日常的运维经营中会产生各类不同的数据资源，这些源数据大致包括园区信息、经营信息、商业信息、产业资源、人才库、项目库、产品库、资产信息等。如何对这些数据进行串联与分类，也就代表着在应用层我们应如何设计能承载这些数据内容呈现的平台产品。

1. 应用分类

一般来说，应用种类的设置需根据园区或企业自身的实际需求进行，但通常情况下基本均包含了如下几个大类。

2. 应用切换体验探索

如何进行园区内应用（或平台）间的切换，我们在服务京东方的项目实践中总结了如下的体验设计要点。

功能描述：

从园区为度对数据进行分层，拥有多园区权限的角色可以在园区之间进行切换。

设计思路：

园区数据与园区主体拥有强绑定关系，园区A的数据之和园区A相关，意味着在查看园区A的数据时可以完全屏蔽园区B的数据，因此园区切换的操作层级非常高；与权限系统相关联，对于单园区的角色，不展示园区切换的操作；对于多园区的角色，需要一个「概览页」，用户汇总多个园区的数据，提供全局视角。

设计方案：单园区的角色，账密输入后进入后台首页，无园区切换操作；

多园区的角色， 账密输入后进入概览页，横向对比各园区的数据，并提供园区的入口；

多园区的角色， 在页面头部提供切换园区的入口；

四、智慧园区中的典型需求

园区在现实物理世界与抽象维度都有其相对应的一些内容。从具体层面出发，以园区为中心，空间、任务及人之间产生了现实之间的联系，映射在抽象层面就有了场景、目标与角色等维度的诞生。

如何基于两个不同层面的相似与差异需求进行体验层面的设计，本章节会进行几个典型需求来进行举例说明。

1. 典型需求——楼宇监控需求说明

以园区内的GIS为例，将园区内的数据信息以可视化的形态呈现于地图上，更加清晰直观地描述空间与数据等之间的关系。

设计思路：

此处的使用场景为应用层，可适当简化地图系统的路径，保留「园区-建筑-楼层」路径。载入页面后提供简化后的俯视图，结合地图信息框架，标注出每栋建筑的位置，并在顶部图层展示业务组件。每栋建筑均可点击进入查看详情：将建筑平面抽象化，通过副栏进入不同楼层，在每个楼层分别完成增删改查等工作。

设计方案：

在此模块的页面结构中，从下导航分别为「底层地图 – 业务组件 – 浮层窗体」；

进入查看某栋建筑或房间时，保留路径用于回退；切换路径或更换楼层时，面板数据源相应变化；查看建筑时，增加楼层指示器。

2. 典型需求——排班管理需求说明

查看员工的排班情况，并提前为其制定工作计划。

设计思路：

分配任务的流程中，至少需要三个要素「任务、员工、时间」。任务实体通常包含任务id、任务名称、任务描述、审核标准等。员工实体通常包含员工id、员工姓名、所属部门、岗位等，但此处为了表达排班管理的功能，可暂时省去部分字段以简化模型；时间将任务与员工连接起来，限制员工在限定时间内完成任务。

对于一些日常性的、周期性的任务，为了避免每次分配都要编辑名称和描述，因此为其建立一套「日常任务库」，分配任务时直接从库中调用，只需要单独维护这套任务库即可。

分配任务时，有三种思路：

第一种：员工任务甘特图

检视员工的排班情况，并为员工指派任务；

为了更方便地展示未来多天的排班情况，将时间轴嵌入员工表：

第二种：日历面板

第二种思路，选择某个时间区段，编辑任务后添加员工；

在组件表达上，最终选择「日历」作为方案；

第三种：任务表

第三种思路，预先配置好任务（仅针对周期性的任务），为其设定时间并添加员工；

任务库使用常规的列表页即可；

整体方案：

在一个界面中通过 tab 进行切换，不需要跳出界面即可满足三种场景的排班管理需求。

3. 典型需求——视频监控需求说明

选择若干摄像机，将画面展示在页面中；

A. 画面

每个画面包含多种状态；待播放、播放中、录屏中；

鼠标移入后，在画面中展示额外信息和操作；

双击正在播放的画面，可快捷地全屏化；

支持 1、4、6、9 宫格的画面布局，用于不同颗粒度的监控场景；

B. 摄像机

按照功能类型，可分为「枪机」和「球机」，球机支持更多的操作，如转向、巡航路线配置等；

按照是否联网 / 开机，可分为「在线」和「离线」；

按照是否播放，可分为「未播放」和「播放中」，其中只有在线的摄像机才会有「播放中」的状态；

按照鼠标交互，可分为「默认」和「鼠标移入」；

当摄像机数量逐渐增加时，为了在摄像机列表中快速定位某一台摄像机，为列表添加搜索功能；

当需要在多个摄像机之间频繁切换时，搜索成本仍然较大，因此为摄像机增加分组功能。分组命名通常为场景或任务，将需要的摄像机添加进组，之后便可以在某个分组下快速定位摄像机；

分组之外的另一个思路，为摄像机添加标签，通过标签来定位摄像机，因此需要建立专属于摄像机的标签库。标签系统需要考虑另一个因素，即筛选的结果满足所有标，还是只需满足任一标签，综合考虑标签分类的方式学习成本较大，因此只简单展示一下。

C. 摄像机面板

实际的业务需求中，除了提供「摄像机名称与状态」，还需要提供一些辅助信息与入口，如摄像机详情入口、告警策略配置、待处理的告警事件、录像回放、球机的转向与巡航路线配置等。

设计思路为：选中某台摄像机后，在一块面板中展示相关信息与入口，这块面板不能影响画面区域，因为在调整球机的转向与焦距时，需要画面的实时反馈，因此考虑将这块面板覆盖在设备列表上；

将所有的辅助信息与入口进行盘并筛选后，元素内容仍然过多，更何况会涉及到转向功能，因此将面板进行分类；其中，「基础信息」面板为枪机与球机的共有面板，「预置位置、巡航列表、视频设置」为球机独有的面板；

为了避免面板内容过多地占据摄像机列表的纵向空间，所有面板支持手风琴折；

D. 轮巡模式

当用户需要在多台摄像机之间（超过9台）频繁切换时，为了简化用户操作，考虑增加一种轮播模式，使一批摄像机按照某个间隔循环播放。复用上方提到的分组方案，为这个分组添加轮播属性为「是」，并设置轮播间隔后，即可让该分组按照既定的规则进行轮播。

此外还有另一个问题，当分组中摄像机的数量无法被画面数量整除时，可能会导致某台设备的画面在轮播时无法出现在某个固定位置，但在用研阶没有关于该问题的结论，因此将「是否固定画面数量」作为分组中的一个属性，交由用户配置；

选择某个分组后，若该分组支持轮巡，可快捷开启轮巡模式；

4. 典型需求——视频监控需求说明

让用户在特定范围内访问资源、让管理者更方便地管控每个用户可访问的资源。

A. 权限模型

常见的技术模型，如 ACL、RBAC、ABAC、DAC、MAC 等，不同的模型有不同的使用场景，此处以 RBAC 为例，因为此模型在实际工作中应用得更频繁，且对于权限可以有一个基础的理解；

B. 梳理角色

首先需要穷举角色，保证系统运作的闭环，盘点角色需要以下两种方式：

按照任务流程（职责）划分：

我们在设计系统或产品时，通常是需要去梳理用户的任务流程的。当时是如何设计这个系统的，我们现在就如何去划分角色，匹配度也会更高。为此，我们需要罗列所有的功能，以及每个功能中涉及到的所有任务流程。通过这种方式，我们得到的角色列表通常包含录入人员、审核人员、应用人员；

按照岗位划分：

工作职责与岗位通常存在对应关系，需要将上方的职责与岗位进行一一关联，确保所有的职责都被分配无遗漏，并且避免存在职责划分不明确的情况，最后的角色列表可能包含管理员、客服、运维、工程师、设计师等。

C. 梳理权限

权限通常分为以下三种：

1. 页面权限：某个页面是否可见，这会直接体现在导航菜单中，只有用户拥有某个页面的访问权限时，才会在导航中展示该菜单；
2. 操作权限：某个操作是否可用，包括增删改查审核；
3. 数据权限：某个数据是否可见。

一个角色在系统中会涉及到哪些任务，这决定了该角色将拥有哪些页面权限；一个角色在某个任务中需要产生哪些行为，这决定了该角色拥有的操作权限；为了完成这个任务，一个角色需要查看哪些信息，这决定了该角色拥有的数据权限。结合之前每个角色的任务流程图，将会得到一份角色权限表；

进一步地，为角色配置权限；

D. 配置权限

第一种逻辑，为角色添加用户；

第二种逻辑，为用户添加角色；

结语

智慧园区之于智慧城市以小见大，我们生活的便捷与智能，离不开商业对于行业整体的发展推动。在园区的数字化改革浪潮中，无论哪类企业与其产品的业务模式，处处都埋藏着发挥体验设计价值的机会点，我们也都在为更加智能化的城市空间建设做出专业贡献。